TPAC 2022 Internationalization WG

13 September 2022


Addison, Atsushi (virtual), Bert, David-Clarke, David-Clarke_, Ding Wei (guest, Fantasai, Florian (physical), Fuqiao (virtual), Manuel (Igalia), physical), Ralph (guest, Richard (virtual), virtual)
Addison Phillips
addison, atsushi, Bert

Meeting minutes

<addison-mobile> Reagent, draft minutes

<addison-mobile> Running late: will start at 705 pacific

<r12a> addison, what's today's zoom link ?

Passcode: 259641

addison: conversation continued yesterday, see note. MathML, CSS issues

addison: longest conversation was on generic fonts
… asked us to come back to say on different generics via gap analysis
… we are asked to guide addisions, and guidelines for adding new generics
… associating new generics to existing ones
… goal is to collect generic classes in different area
… second part is how those map to five generics
… like Nastaliq is not sans-serif, or so

r12a: you are talking about long discussions, we held

addison: different sized bar among CSS participants
… we spent long time with stating the same thing

<r12a> https://github.com/w3c/csswg-drafts/issues/6770

<r12a> https://github.com/w3c/csswg-drafts/issues/4605

<r12a> https://github.com/w3c/csswg-drafts/issues/4910

addison: other thing, mostly other CSS issues, like spacing in punctuations

<r12a> https://github.com/w3c/csswg-drafts/issues/4566

<r12a> https://github.com/w3c/csswg-drafts/issues/4442

<r12a> https://github.com/w3c/csswg-drafts/issues/4397

addison: also language tag, with blank or asterisk
… also blank vs. und

<r12a> https://www.w3.org/International/questions/qa-no-language.en.html

addison: is xml:lang not allow blank?
… from definition, it cannot be empty
… guess schema has a bug?

addison: for topic, we can spend some time for our remaining open issues

<Bert> according to the XML spec, xml:lang is allowed to be empty

addison: one is talk about specdev, one editing in flight with more time than usual
… PR open again string-meta, is mustard for specdev also

r12a: for sure, if we make changes to string-meta, should also be lunched to specdev
… don't need is to copy words


r12a: we have lots of items in both

addison: original concept was checklist and pointers

r12a: discussed some monthes ago, summary text and pointing out are included
… you could basically read specdev like a document and to get idea, and get more detail via sources pointed

[moving physical room to correct one]

Info Share

r12a: unicode edcom released version 15 today
… also in review edition will be released soon

Ding_Wei: from Huawei


addison: 28th of this month, unicode consortium will have virtual event for introduction of unicode and internationalization
… series of records from groups, one tutorial of internationalization
… series of records and live conversations


xfq: received email for white space, but haven't got time to work in

addison: picking personal name's one


addison: we list personal names' examples in block
… discussed that making sortable table, completing notes, and language tags
… question to ask people to contribute or not

r12a: thinking, we are picking names from various regions, but not sure whether to indicate as region but as country
… we need to establish this table with all of regions

addison: that's one I haven't finished

<xfq> There is a famous actress with the name An: https://ja.wikipedia.org/wiki/%E6%9D%8F_(%E5%A5%B3%E5%84%AA)

[conversation for names listed in the table]

addison: should we back to original f/m separated list?

r12a: don't think so


addison: richard you wanted to add some text for TBDs
… do we have some plan to build text for those?

r12a: got a detailed plan, step 1 someone write text, step 2 we review, step 3 we publish!

r12a: remember this is for spec developers
… also if you click links, you will see several review comments and what things to do or taken

addison: should we build backlog for people can check, or?

r12a: we could, but in sense of spec-dev, people can take from contents. there are already pipelines

addison: when we read as a block, you will notice the gaps
… sometimes we do on mustard, but sometimes don't

r12a: we have somewhere, in some cases but not all. we should have here and also links
… brief description is necessity, for reading these
… we need to go through, and check whether text is complete


addison: issues here

r12a: when you do reviews from spec, you should tag



addison: review comment for secure-payment-confirmation here, I don't think spec-dev doesn't say anything relates to this

r12a: not everything we need to create text for specdev

addison: on review, we have new action to tag each issue
… on some level, I would expect to have a policy what to write

xfq: I can look into some text, after finishing the whitespace stuff

r12a: better to have more people than you and me
… if you review something, and there is nothing in specdev, one should propose something to specdev

addison: one proposal, if one review and found nothing within label, one propose some text?

r12a: there are TBC label

r12a: if you choose t: label, you will see section number and title
… TBC is not sure which section is related, x is not in specdev
… like bidi_x

r12a: i: is index
… those labels relate to index, t: labels are for specdev. there should be some documentation.

<xfq> Language enablement index

<r12a> https://github.com/w3c/i18n-editors/

ACTION: richard: find instructions for doing reviews and add to i18n-editors page

<trackbot> Created ACTION-1198 - Find instructions for doing reviews and add to i18n-editors page [on Richard Ishida - due 2022-09-20].

<r12a> https://www.w3.org/International/i18n-activity/guidelines/review-instructions.html

ACTION: richard: add instructions for t: labels to the github review instructions

<trackbot> Created ACTION-1199 - Add instructions for t: labels to the github review instructions [on Richard Ishida - due 2022-09-20].

Uniview v15.0

Infoshare 2

<r12a> https://r12a.github.io/uniview/

r12a: two item



addison: string-search is a part of charmod, specific to string search
… basically, this document syas, considerations need to be taken when spec wants search



addison: not the highest priority, but at some point touch on this. there are bunch of examples
… set of examples and links to issues
… like issue #10

addison: my statement here is about writing allow languages @@@1
… like, here is some variations, looks similar, but don't know spelling variations

[on specific example in detail, incl. Marathi]

<r12a> wait !

<r12a> wrong one



Writing परसवणर is optionally allowed only forततसम words and not for non-ततसम words. Also, for meaning change as inवेदांत which means- ‘in the Veda’ as against, वेदानत which means- end of the

you can write the word with anuswara or a half-form of the nasal, although in some cases a particular word is preferred to have one or the other
… but in general you can switch between the two depending on how you like to write it
… this is just one example of how you can type differently

r12a: section south asian language should be titled as multiple ways of spelling

addison: will call as variations of user inputs/spelling

r12a: as mentioned before, variations are common among there
… that is choice of person's writting

addison: I should break this section, one for Arabic specific, and spelling slightly different

<r12a> https://r12a.github.io/scripts/arabic/arb.html#ijam_tashkil

r12a: above link is for alternative encoding of Kashimiri

richard's link is better, use that

addison: import these documents?

r12a: go ahead

ACTION: addison: import ijam/tashkil into glossary

<trackbot> Created ACTION-1200 - Import ijam/tashkil into glossary [on Addison Phillips - due 2022-09-20].


ACTION: richard: read the ILs-text-variations-final doc and make sense of it for addison

<trackbot> Created ACTION-1201 - Read the ils-text-variations-final doc and make sense of it for addison [on Richard Ishida - due 2022-09-20].

r12a: could read through the document, and can put some text for Indian scripts

<Bert> (Typo in French example 6: s/côtè/côté/ )

addison: want to get this document updated, and bring into /TR/
… a lot of work to do, to provide a guidance for writting 'find' spec

r12a: want to recommend, to have specdev to /TR/ also, although empty section

specdev publish to TR

r12a: links to labels, needs to be updated

ACTION: richard: publish current specdev to TR

<trackbot> Created ACTION-1202 - Publish current specdev to tr [on Richard Ishida - due 2022-09-20].

addison: no additional item, break until 10am

~* Break *~

timezone, ltli


addison: I started a revision of ‘Working with Time and Timezones’
… Could be useful for ECMA, who want to add temporal support to JavaScript.


addison: LTLI, we discussed it a while ago.
… Decided to not incorporate some text, because of diff. in audience.

<r12a> i believe so

addison: But we still have a pull request waiting.
… OK, so I will undo the pull request.

<r12a> https://www.w3.org/International/questions/qa-text-processing-vs-metadata

addison: That does not belong in specdev, because it is not for spec authors.
… Do we have defs in the glossary?

r12a: I think it does belong in specdev.

addison: And we do have defs in the glossary.

<r12a> https://w3c.github.io/bp-i18n-specdev/#lang_misc


addison: And specdev also has ^^


<r12a> metadata to associated with the

r12a: Can we put the mustard in that section before the text? We always do that, mustard and then explanation.

addison: OK
… Done.
… I will look up the RFC it mentions [in the Webtransport example] and link to it.

<r12a> yes

addison: Does the mustard capture the essence?

r12a: [on IRC:] yes

addison: Those were editorial things on the top of my mind? Any others?
… Only outstanding is an action on formatted text. Did not have time yet.
… Volunteers to help welcome!
… May get to it in a month or two.

CSS #775


florian: Issue CSS#775 waiting for an answer

fantasai: The comment in the issue is a good summary.

addison: So it is trying to shrink bopo, but nut pinyin?

florian: Shrinking 50% OK for kana. For pinyin, may also depend on the font.

addison: So the language tag is a proxy for determining if it is bopo or pinyin?

fantasai: Yes, we have no other information.

florian: May make for verbose markup with all the lang tags, but it is the right thing to do.
… Question is not if this captures everything, but if it is the right default.

r12a: I was concerned about applying the sizing to the bopomofo. The bopomofo can be in the same position as kana or pinyin, but usually it is along the side.
… You can set CSS properties to do that.
… So is the 30% right in that case?

florian: You cannot have a CSS property depend on the value of another property.

addison: What if you remove the 30% rule?

florian: Then the bopomofo size would be wrong.

r12a: You need something different for bopomofo to get the position correct.

florian: You can have three characters bopomofo ruby, and then 50% won't fit.
… We are trying to say ruby in general sizes to 50%, but when it is bopomofo size to 30%.
… For the default; author can always change it.
… Size works, no matter what side of the base the ruby is displayed on.

r12a: Inter-character layout is very specific.
… And is the 30% instead of 33% to leave room for tone?

<fantasai> https://language.moe.gov.tw/001/Upload/files/SITE_CONTENT/M0001/deploy/html_en/index.html

fantasai: Comes from ministerial recommendations for size ratios.
… See document from Taiwan ^^

florian: clreq has the same.

addison: OK, so the size is right. Now how do know a text is bopomofo?

florian: Hong-Kong vs Taiwan.

r12a: This is about the size. Isn't the centering also an issue?
… Because bopomofo isn't vertically centered, according to the Taiwan document. At least in inter-character. But bopomofo is rarely in other positions.

fantasai: Language tag matching is according to RFC. Subtag order does not matter.

addison: But if you do prefix matching...

fantasai: Browsers are supposed to apply the RFC 4347 algo.

addison: So if tw is not in the subtags, the pinyin may end up small.

florian: We might specify ‘not hk’.
… Smaller size may be harder to read.

David-Clarke: So, accessibility issues.

florian: So better to miss some cases than apply too much.

fantasai: Require language tags: Is there a way to express that a document is in a mix of scripts?

addison: There is ‘hanb’


addison: For Han with Bopomofo.

florian: That's perfect.

addison: ‘Perfect’ not the word I was thinking of....

florian: But perfect for this situation.
… So I think we add zh-hanb.

r12a: Looking at the Taiwan document, the pictures are different. Figuring out the sizing...

florian: There are some 9's and some 8's, while clreq only has 9's in the ratios.
… 9/30 in clreq, and 8/30 in the Taiwan document some of the time.

r12a: About half of the time.

fantasai: zh-hanb is now added in the CSS Ruby spec.

florian: I think the 8 or 9 is fine, it is always 9, but some fonts may have non-square, 8x9 characters.
… So size is correct, though positioning may be a problem.

fantasai: So OK for square and portrait characters. Landscape characters a problem.

addison: OK, sounds reasonable. As a default.

addison: OK, so shall we turn to the centering issue?

florian and fantasai discuss the process for the CSS WG to approve the issue.

fantasai: issue #771


fantasai: Issue was focused on latin text, should we have a separate issue for Chinese?


florian: Issue #779

florian: Bopomofo is not exactly centered, but close.

<fantasai> https://github.com/w3c/csswg-drafts/issues/771#issuecomment-1182339573

fantasai: in #771, the proposal is to have a separate justification algo for ruby.
… It says spaces are not a justification opportunity.
… We can say Bopomofo doesn't have justification opportunities.

florian: The removal of justification opportunity effectively results in centering, which for bopomofo is almost right.

fantasai: The 'auto' value can do this.
… Without justification opportinuties, it falls back to centering.

addison: Seems reasonable...

r12a: Yes, reasonable. But:
… Need to be clear that is an approximate kludge.

florian: If we would specify 'center', it would also be wrong in the same way.
… For the difference between centering and actual bopomofo layout, you would need dedicated engines in any case.

fantasai: So we are adding a justification mode, which removes justification opportunities from bopomofo. As it is an 'auto' value, implementers can do better, but that may take a while to happen.
… We need to bring this to the CSS WG.

florian: I have added a corresponding tag to the issue.

fantasai: And I will add the conclusion in the issue.

addison: Do you want us to review?

florian: We can ping you when it is ready for review.

addison: Tracking in issue #779, rather than #771.


<florian> https://www.w3.org/TR/css-text-4/#text-spacing-property

florian: The diff between allow-end and trim-end is whether you trim the white part of punctuation if it appears at the end of the line.
… allow-end may lead to ragged right appearance.

r12a: It doesn't depend on justification..

addison: So the issue is about the default behavior.

florian: Yes, and the argument in the issue to use trim-end seems reasonable.
… So, the i18n wg recommends to accept the proposal?

addison: I don't see any harm in making it the default.

r12a: Yes, I already agreed in a comment in the issue.

(notes that we discussed this: https://www.w3.org/2022/03/04-clreq-minutes.html#t07)

fantasai: Can you add the i18n recommendation to the issue?


fantasai: So seems the conclusion is to close the issue ^^ with no change?

florian: That seems to be the conclusion in the corresponding clreq issue.

fantasai: OK will do.

<fantasai> https://github.com/w3c/csswg-drafts/issues/6950

<fantasai> https://github.com/w3c/csswg-drafts/issues/6950#issuecomment-1025401290

<fantasai> CLREQ response https://github.com/w3c/csswg-drafts/issues/6950#issuecomment-1103480275

<fantasai> Japanese-perspective response https://github.com/w3c/csswg-drafts/issues/6950#issuecomment-1164087402

fantasai: Seems there is a preference for turning on auto-spacing by default. Separate question is compatibility with browsers.
… Chinese suggestion is 1/8 em, Japanese suggestion is 1/4 to 1/6 em.

florian: Precise size can be an issue in layout of a button or menu. So my suspicion is that there are pages that break when auto spacing is on by default.

fantasai: So spacing is preferable, if it is compatible. Other question is what the default size is, 1/8? 1/6? Or depending on language?

atsushi: From jlreq perspective, 1/6 em comes from traditional spacing. Research exists that sizeof spacing between ideographic and alphanum
… in jlreq consensus that some spacing is better than nothing.

fantasai: So 1/8 is probably the least intrusive change then.

florian: Is is user-selectable?

<r12a> https://github.com/w3c/csswg-drafts/issues/7183

fantasai: Not currently, but we should make it so.

florian: As it is not implemented yet, seems better to keep it simple for now.

r12a: It is implemented in IE, and MS Word does it.

florian: Yes, and other programs, but question is about CSS and browsers.

fantasai: MS Word also has to be compatible with practice in the 90s. Need research of current practice.

florian: Would be good to have a conclusion from i18n that some spacing is desirable, and exact size is to be researched.

addison: That seems not controversial. If compatible.
… And you would do research what sophisticated layout engines do today.

florian: I think the Japanese 1/4 comes from when that was simple to do in typesetting.

addison: What at boundary between ideographs and, say arabic?

r12a: Or Thai?

florian: Latin is by far the most common.

fantasai: I suspect it is for everything that is not ideographs. That is what the spec says now.

addison: emojis?

florian: They are neither letters nor numerals.

fantasai: So conclusion: spacing between 1/8 and 1/6 em, depending on further research.
… Other question is what to do if there is already space in the source.
… Throw it away and put in the 1/8em?
… And would it be web-compatible if we *only* did that?

<r12a> https://github.com/w3c/csswg-drafts/issues/7183

r12a: That would only shrink the text somewhat, so not as dangerous for buttons and menus, as Florian mentioned.

r12a: That is also a part of my issue ^^

r12a: Auto-spacing is bound to get a lot more complicated, when we get to other languages.
… E.g., the vertical bar that ends a sentence.
… Some people put a space before it, size can differ.
… And some traditions have a lot more space after than before the symbol.

florian: For French, practice differs. There are rules, but some authors ignore it, some put a normal space because it is hard to get the right one...

<fantasai> https://www.w3.org/TR/css-text-4/#valdef-text-spacing-punctuation

fantasai: But if you turn the property on explicitly, you get what you want.

(btw. Danda: https://www.unicode.org/notes/tn33/)

ACTION: richard: file an issue on the danda and SEAsian punctuation

<trackbot> Created ACTION-1203 - File an issue on the danda and seasian punctuation [on Richard Ishida - due 2022-09-20].


<r12a> https://github.com/w3c/csswg-drafts/issues/5478

CSS 5478

About which quote characters to select when a quote is in a different language from the surrounding text.

fantasai: I already have an action for that. Can try to work on it on...

r12a: It is part of the gap analysis documents.

fantasai: Seems it was checked in for Gecko already.

r12a: And the issue talks about Chromium. Is webkit doing it?

fantasai: Seems Chrome was updated also.

r12a: OK, I need to run my tests again.
… That will change the color of a large percentage of my language-enablement matrix.

addison: So it will be the tipping point and we can say the web is now internationalized :-)



<r12a> https://github.com/whatwg/html/issues/2404

<r12a> https://github.com/w3c/alreq/issues/217


Discussion about whether this was already discussed.

<fantasai> https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-952428897

fantasai: This needs to come up in the CSS WG now.

<fantasai> https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-1105613943

fantasai: There was a proposal to use 'margin' as shorthand for physical, and 'marginS' as shorthand property for logical.

addison: There could be a switch in the style sheet to switch between physical and logical. Is that a good summary of what we said?
… In other words, once all physical properties have a logical equivalent, there could be a switch to turn all shorthands into logical shorthands.

fantasai: A switch at syntax level, but only for the shorthands. 'Margin-left' would still be left, but 'margin' would affect the logical properties.

r12a: I believe Chrome has a flag.
… I'll send you the article I've written, which talks about ':dir(rtl)'

fantasai: Send me an email, otherwise I'll forget to look at it.

addison: Next meeting is Thursday. I'll have a meeting with Ian [on Web Payments] and I'll report on that.

atsushi: What is the zoom for Thursday?

addison: The one we use for the regular telcons.
… I'll send the agenda tonight, probably.

[Lunch. Back in 1 hour]


<trackbot> action-1193: Addison Phillips to Ping css for their list of hot issues -- due 2022-09-15 -- OPEN

close action-1193

<trackbot> Closed action-1193.


<trackbot> action-1194: Elika Etemad to Summarize into issue, for discussion in csswg -- due 2022-09-19 -- OPEN

close action-1194

<trackbot> Closed action-1194.


<trackbot> action-1181: Addison Phillips to Send xfq comments on pattern_white_space, etc. -- due 2022-08-18 -- OPEN

close action-1181

<trackbot> Closed action-1181.

~* Lunch *~

addison: I talked with some a11y people over lunch, among other things about tagging old languages.

David-Clarke_: Like Shakespearian English?
… And they do teach Latin on Duolingo.
… I studied some old Japanese, and the professor explained how they knew the pronunciation has changed.
… E.g., Japanese ‘oh’ which once was ‘woh’.

tonight's discussion with payments

addison: I'll talk tonight to Ian about Web Payments. Things related to string-meta.
… And I'll need to get TC39's attention.


Discussion with Payments

addison + ian + stephen

just chicken scratch here in case we need it


<Ian> https://github.com/w3c/secure-payment-confirmation/issues/202

<Ian> https://github.com/w3c/secure-payment-confirmation/issues/202

Summary of action items

  1. richard: find instructions for doing reviews and add to i18n-editors page
  2. richard: add instructions for t: labels to the github review instructions
  3. addison: import ijam/tashkil into glossary
  4. richard: read the ILs-text-variations-final doc and make sense of it for addison
  5. richard: publish current specdev to TR
  6. richard: file an issue on the danda and SEAsian punctuation
Minutes manually created (not a transcript), formatted by scribe.perl version 192 (Tue Jun 28 16:55:30 2022 UTC).


Succeeded: s/XML lang/xml:lang/

Succeeded: s/poiting/pointing/

Succeeded: s/ad-com/edcom/

Succeeded: s/Huawai/Huawei/

Succeeded: s/nmaes/names/

Succeeded: s/you will be noticed as gap/you will notice the gaps

Succeeded: s/sence/sense

Succeeded: s/in white space stuff/after finishing the whitespace stuff/

Succeeded: s/choise/choice/

Succeeded: s/fine spec/'find' spec/

Succeeded: s/Chinese./Chinese?/

Succeeded: s/It also depends on justification setting/It doesn't depend on justification./

Succeeded: s/clreq/corresponding clreq

Succeeded: s/clreq perspective/jlreq perspective/

Succeeded: s/in clreq consensus/in jlreq consensus/

Succeeded: s/thatis/that is/

Maybe present: atsushi, Ding_Wei, florian, Passcode, r12a, xfq