W3C home > Mailing lists > Public > www-international@w3.org > July to September 2022

[minutes] Internationalization WG TPAC 2022 F2F Part II: 2022-09-13

From: Fuqiao Xue <xfq@w3.org>
Date: Wed, 21 Sep 2022 09:11:22 +0800
Message-Id: <7CE4115D-5574-420D-B01F-EC6960D5D6A2@w3.org>
To: www-international@w3.org
[Corrected the subject line]


                            – DRAFT –
                  TPAC 2022 Internationalization WG

13 September 2022


     [2] https://www.w3.org/events/meetings/6e9d6b4f-04c3-4941-a56e-3664d103f504#joining


         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


   1. [3]specdev
   2. [4]Info Share
   3. [5]specdev
   4. [6]Infoshare 2
   5. [7]String-Search
   6. [8]specdev publish to TR
   7. [9]~* Break *~
   8. [10]timezone, ltli
   9. [11]CSS #775
  10. [12]Intros
  11. [13]CSS 5478
  12. [14]whatwg#2404
  13. [15]ALReq#217
  14. [16]~* Lunch *~
  15. [17]tonight's discussion with payments
  16. [18]AOB?
  17. [19]Discussion with Payments
  18. [20]Summary of action items

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
  … 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> [21]https://github.com/w3c/csswg-drafts/issues/6770

    [21] https://github.com/w3c/csswg-drafts/issues/6770

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

    [22] https://github.com/w3c/csswg-drafts/issues/4605

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

    [23] https://github.com/w3c/csswg-drafts/issues/4910

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

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

    [24] https://github.com/w3c/csswg-drafts/issues/4566

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

    [25] https://github.com/w3c/csswg-drafts/issues/4442

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

    [26] https://github.com/w3c/csswg-drafts/issues/4397

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

  <r12a> [27]https://www.w3.org/International/questions/

    [27] 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, [28]xml:lang is allowed to be

    [28] https://www.w3.org/TR/xml/#sec-lang-tag

  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


    [29] https://www.unicodeconference.org/

  addison: 28th of this month, unicode consortium will have
  virtual event for introduction of unicode and
  … series of records from groups, one tutorial of
  … 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


    [30] https://aphillips.github.io/bp-i18n-specdev/#personal_name_examples

  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: [31]https://

    [31] https://ja.wikipedia.org/wiki/杏_(女優)

  [conversation for names listed in the table]

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

  r12a: don't think so


    [32] https://w3c.github.io/bp-i18n-specdev/

  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


    [33] https://github.com/w3c/bp-i18n-specdev/issues

  addison: issues here

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


    [34] https://github.com/w3c/i18n-activity/issues/1581


    [35] https://github.com/w3c/secure-payment-confirmation/issues/206

  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

  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
  … 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> [36]Language enablement index

    [36] https://www.w3.org/TR/typography/

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

    [37] 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

  <r12a> [38]https://www.w3.org/International/i18n-activity/

    [38] 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

  Uniview v15.0

 Infoshare 2

  <r12a> [39]https://r12a.github.io/uniview/

    [39] https://r12a.github.io/uniview/

  r12a: two item



    [40] https://w3c.github.io/string-search/

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


    [41] https://aphillips.github.io/string-search/


    [42] https://aphillips.github.io/string-search/#south-asian-scripts

  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
  … 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


    [43] https://github.com/w3c/string-search/files/9278962/ILs-text_variations-final.pdf


    [44] https://github.com/w3c/string-search/issues/10

  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> [45]https://r12a.github.io/scripts/arabic/

    [45] 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].


    [46] https://github.com/w3c/string-search/files/9278962/ILs-text_variations-final.pdf

  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


    [47] https://w3c.github.io/timezone/

  addison: I started a revision of [48]‘Working with Time and
  … Could be useful for ECMA, who want to add temporal support to

    [48] https://w3c.github.io/timezone/


    [49] https://pr-preview.s3.amazonaws.com/w3c/ltli/34/409daae...aphillips:b9fb565.html#metadata-versus-text-processing

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

  <r12a> i believe so

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

  <r12a> [50]https://www.w3.org/International/questions/

    [50] 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> [51]https://w3c.github.io/bp-i18n-specdev/#lang_misc

    [51] https://w3c.github.io/bp-i18n-specdev/#lang_misc


    [52] https://aphillips.github.io/bp-i18n-specdev/#sec_text_processing_lang

  addison: And specdev also has ^^


    [53] https://deploy-preview-75--string-meta.netlify.app/#protocol-strings

  <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
  … 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


    [54] https://github.com/w3c/csswg-drafts/issues/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> [55]https://language.moe.gov.tw/001/Upload/files/

    [55] https://language.moe.gov.tw/001/Upload/files/SITE_CONTENT/M0001/deploy/html_en/index.html

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

  florian: clreq has the same.

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

  florian: Hong-Kong vs Taiwan.

  r12a: This is about the size. Isn't the centering also an
  … 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

  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’


    [56] http://unicode.org/iso15924/iso15924-codes.html

  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

  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


    [57] https://github.com/w3c/csswg-drafts/issues/771

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


    [58] https://github.com/w3c/csswg-drafts/issues/779

  florian: Issue #779

  florian: Bopomofo is not exactly centered, but close.

  <fantasai> [59]https://github.com/w3c/csswg-drafts/issues/

    [59] 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

  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
  … 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.


    [60] https://github.com/w3c/csswg-drafts/issues/7055

  <florian> [61]https://www.w3.org/TR/

    [61] 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: [62]https://www.w3.org/2022/03/

    [62] https://www.w3.org/2022/03/04-clreq-minutes.html#t07)

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


    [63] https://github.com/w3c/csswg-drafts/issues/6001

  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> [64]https://github.com/w3c/csswg-drafts/issues/6950

    [64] https://github.com/w3c/csswg-drafts/issues/6950

  <fantasai> [65]https://github.com/w3c/csswg-drafts/issues/

    [65] https://github.com/w3c/csswg-drafts/issues/6950#issuecomment-1025401290

  <fantasai> CLREQ response [66]https://github.com/w3c/

    [66] https://github.com/w3c/csswg-drafts/issues/6950#issuecomment-1103480275

  <fantasai> Japanese-perspective response [67]https://

    [67] 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

  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> [68]https://github.com/w3c/csswg-drafts/issues/7183

    [68] 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

  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
  … Throw it away and put in the 1/8em?
  … And would it be web-compatible if we *only* did that?

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

    [69] 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> [70]https://www.w3.org/TR/

    [70] 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: [71]https://www.unicode.org/notes/tn33/)

    [71] https://www.unicode.org/notes/tn33/)

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

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


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

    [72] 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 :-)



    [73] https://github.com/whatwg/html/issues/2404

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

    [74] https://github.com/whatwg/html/issues/2404

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

    [75] https://github.com/w3c/alreq/issues/217


  Discussion about whether this was already discussed.

  <fantasai> [76]https://github.com/w3c/csswg-drafts/issues/

    [76] https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-952428897

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

  <fantasai> [77]https://github.com/w3c/csswg-drafts/issues/

    [77] 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
  … 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

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

  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> [78]action-1193: Addison Phillips to Ping css for
  their list of hot issues -- due 2022-09-15 -- OPEN

    [78] https://www.w3.org/International/track/actions/1193

  close action-1193

  <trackbot> Closed action-1193.


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

    [79] https://www.w3.org/International/track/actions/1194

  close action-1194

  <trackbot> Closed action-1194.


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

    [80] https://www.w3.org/International/track/actions/1181

  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> [81]https://github.com/w3c/secure-payment-confirmation/

    [81] https://github.com/w3c/secure-payment-confirmation/issues/202

  <Ian> [82]https://github.com/w3c/secure-payment-confirmation/

    [82] https://github.com/w3c/secure-payment-confirmation/issues/202

Summary of action items

   1. [83]richard: find instructions for doing reviews and add to
      i18n-editors page
   2. [84]richard: add instructions for t: labels to the github
      review instructions
   3. [85]addison: import ijam/tashkil into glossary
   4. [86]richard: read the ILs-text-variations-final doc and
      make sense of it for addison
   5. [87]richard: publish current specdev to TR
   6. [88]richard: file an issue on the danda and SEAsian
Received on Wednesday, 21 September 2022 01:11:27 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 21 September 2022 01:11:27 UTC