[minutes] Internationalization telecon 2022-09-13


                             – 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 Tuesday, 20 September 2022 11:37:30 UTC