– DRAFT –
Internationalization Working Group Teleconference

Agenda Review

Action Items

<addison_> gb, list open actions

<gb> Found actions in w3c/i18n-actions: #49, #48, #47, #46, #44, #43, #42, #41, #39, #35, #33, #32, #18, #16, #12, #11, #10, #8, #7, #5, #4

<addison_> #49

<gb> Action 49 contact unicode about emphasis mark skipping (on aphillips) due 2023-10-05

<addison_> #48

<gb> Action 48 work with clreq to investigate or produce a generics proposal (on xfq) due 2023-10-05

addison_: On #49, not sure who to write to, yet, but will figure it out.

<addison_> #47

<gb> Action 47 make the CSSWG aware of Warichu (on frivoal) due 2023-10-04

<addison_> #46

<gb> Action 46 read the string-meta explainer and consider the new approach addison proposes (on xfq, r12a) due 2023-09-28

<addison_> #44

<gb> Action 44 follow up on the bidi thread of rdf-star (on r12a) due 2023-09-19

<addison_> #43

<gb> Action 43 pull together the list of win/mac/etc apis for setting base direction and/or language (on aphillips) due 2023-09-18

r12a: If we do not discuss #46 today, send me email.

<addison_> #42

<gb> Action 42 work on tc39 proposal (meet with addison and eemeli to start) (on xfq) due 2023-09-18

<addison_> #41

<gb> Action 41 propose new specdev text on strings for xml (on aphillips) due 2023-09-07

<addison_> #39

<gb> Action 39 develop best practice guidelines for name-like fields (on aphillips) due 2023-08-31

<addison_> #35

<gb> Action 35 make the edits of CSS #5478 (on fantasai) due 2023-08-30

<addison_> #33

<gb> Action 33 Close issues marked `close?` or bring to WG for further review (on aphillips)

addison_: #33, worked on that.
… Put some on the agenda.

<addison_> #32

<gb> Action 32 Approve the character markup PR (on fantasai) due 2023-08-17

addison_: Will take another week for the rest.

addison_: #32 may be stale.
… Made a new PR.

r12a: I did look at at it.

<addison_> #18

<gb> Action 18 Have informal explanation sessions about counter style translations with csswg members (on frivoal, fantasai)

<addison_> #16

<gb> Action 16 Keep track of line-breaking in Korean for i18n-discuss#11 (on aphillips)

<addison_> #12

<gb> Action 12 Upgrade/edit the explainer to address issues raised by google (on aphillips)

<addison_> #11

<gb> Action 11 Triage all css properties to determine which are logical, physical, or na by default (on frivoal)

<addison_> #10

<gb> Action 10 With florian triage richard's article into a list of potential generics (on frivoal, fantasai)

<addison_> #8

<gb> Action 8 Create pr against canvas formatted text (on aphillips)

<addison_> #7

<gb> Action 7 Remind shepherds to tend to their awaiting comment resolutions (Evergreen) (on aphillips, xfq, himorin, r12a, bert-github)

<addison_> #5

<gb> Action 5 Check into how to list questions at the top of a digest and/or improve lang enablement communications (on r12a)

<addison_> #4

<gb> Action 4 Work with respec and bikeshed to provide the character markup template as easy-to-use markup (on r12a)

Info Share

addison_: I had a call with VC, see agenda item.
… Last week I mentioned some changes to process. This week was first test of that.
… With WCAG, and plh told me it worked.

<r12a> https://w3c.social/@webi18n/111176326932097219

r12a: See ^^

<r12a> All 3 major browser engines now support the ability to create custom counter styles.

r12a: All three major browsers support custom counter styles, in the released version.
… Safari was the last to move it from the experimental to the main browser.

<addison_> 🎉

r12a: Took time to rewrite all the gap analysis docs as a consequence, but that was worth it.

RADAR Review

<addison_> https://github.com/w3c/i18n-request/projects/1

bert: Did not work on review of C

Pending Issue Review

bert: JOSE and COSE yet.

<addison_> gb, list open issues from w3c/i18n-activity with label pending

<gb> addison_, sorry, I don't understand what you want me to do. Maybe try "help"?

<addison_> https://github.com/w3c/i18n-activity/issues?q=is%3Aissue+is%3Aopen+pending

r12a: That's the shadow DOM stuff, going on since months.

Definition of 'string' revisited

<addison_> https://deploy-preview-117--bp-i18n-specdev.netlify.app/#char_string

addison_: I made some edits, see ^^
… "Unicode scalar value" doens't link correctly. I need to debug that.
… Wrote about different types of strings. No change to the recommendations, but the explanations are completely different.
… So I'd like to merge this. Can r12a review it?

r12a: Much better than before!
… You didn't change the mustard. We had a discussion before about what Web Platform means.
… Not sure we had a better alternative.
… Do you mean, when designing a feature _that uses utf-16_?

addison_: No, for general string.
… It tries to explain the mustard.

r12a: Doesn't it assume the string is in utf-16?

addison_: Kind of, but a JSON file, e.g., would be in UTF-8.
… In UTF-8, there should be no surrogates.
… WebIDL will use DOMString.
… Only use USVString if you need to count characters or similar.
… That is the theory.
… Just don't specify utf-8 and then work with bytes,

r12a: Do we say why we choose DOMString?

addison_: May need to clarify when to use USVString.
… I will stab at it again.

r12a: There may be something about DOMString assuming utf-16.

addison_: Infra spec defines string as utf-16.

r12a: If you use utf-16 code units, you should use DOMString, otherwise you use USVString. But now it gets confused.

addison_: JavaScript strings are utf-16.

r12a: Maybe we should say use DOMString when required by the API, otherwise use USVString.
… But may conflict with the TAG.

addison_: Maybe we should say why we are in this knot.

atsushi_: Prefer the original description.

addison_: The difference is the surrogate handling.
… RDF guys use XML strings, not DOMStrings.

atsushi_: From implementation POV,
… it is just the interface.

addison_: Depends on what language you write it in.

ACTION: addison to raise TAG request about reviewing string definitions

r12a: XML would use utf-8 as well. It is the internal encoding of the DOM that uses utf-16 strings.

<gb> Created action #50

r12a: Is surrogates the only difference between DOMString and USVString?

addison_: Counting characters and indexing is also different.
… That's why you want a USVString when looking at the internals of a string.

tr-design pr

addison_: r12a and xfq raised an issue on tr design.

<addison_> w3c/tr-design#341

addison_: I made a pull request ^^
… r12a, did you have a concern with it?

<r12a> https://w3c.github.io/i18n-activity/guidelines/editing

r12a: I had a look at it and at our guidelines ^^
… You did it somewhat differently.

<addison_> https://deploy-preview-117--bp-i18n-specdev.netlify.app/#char_ref

r12a: We say in our guidelines that you can use an image. Not an issue per se.

addison_: It is trying to be the same as in specdev.
… Cannot be exactly the same, because of the context, but the text is the same.

r12a: Happy with the specdev thing.

addison_: I published specdev and glossary on TR last week.
… The section about character styling is in there.

r12a: I just approved the PR

VCWG special call results

addison_: We had a special call with Verifiable Credentials.
… We reviewed language & direction metadata.
… They are going to put metadata.
… They are kind of JSON-LD, but they don't require JSON-LD, so they use just a feature from JSON-LD.
… It is a weird, but it satisfies the req to have lang & dir metadata.

String-Meta next steps

<addison_> https://github.com/w3c/i18n-discuss/blob/gh-pages/explainers/string-meta-explainer-updated.md#is-there-a-better-approach

<r12a> [ ^^ previous topic url https://www.w3.org/2023/10/03-vcwg-special-minutes.html ]

addison_: Last week we discussed a different approach.
… We do need to clean up stringmeta, but it can explain how to serialize a string.

r12a: Should we have it in specdev?

addison_: That is an option.

r12a: Handy to have a spearate little doc to point people to.
… Would you make the little doc a Respec doc?

addison_: Yes.

r12a: Best to do this doc first, before specdev.

addison_: Then we need a repo. With what name?

r12a: Will think about it.

ACTION: addison to inform fuqiao and richard what to name the string-meta-2 repo

<gb> Created action #51

HTML EAI support in input type=email

<addison_> whatwg/html#4562

addison_: Thread has woken up.
… Proposed over 3 years ago an input type "email" that validates addresses with unicode on both sides of the "@".
… There is now a long discussion about EAI addresses, whether they are used, what they can contain.
… HTML is not responsible for encoding the address, just for testing that what you typed is a valid address.

atsushi_: From CJK users, IDNA selects domain. Should have validation of them.

addison_: So you are saying the rhs is restricted by IDNA and browsers already know how to resolve those.

atsushi_: lhs is free. Users can use a combined form, with Kana or @@.

atsushi_: From the RFC 822 and 821, the local part is restricted.
… John?

JcK: Non-ASCII on either side is not recommended. RFC strongly recommend not using AA labels.
… On the lhs side there are no rules, no expectation that two encodings give the same results, the interpretation is purely up to the local mail server.
… What big providers are doing. E.g., use of % signs.
… Use of % in URLs clashes with various things.
… % in lhs will not work, it means a change in the standards.
… Trying to interpret the lhs will lead to trouble.

addison_: So that means don't normalize it. HTML doesn't actually send email.
… What atsushi sai about the rhs: browser do know something about that.

JcK: But requiring validation of the IDNA on the rhs, is not recommended by Unicode people. It is too much trouble.

atsushi_: We cannot do much. It is an RFC.

addison_: We can write new RFCs...

JcK: Some providers claim millions of users using certain addresses.
… Address is Unicode with "@" in the middle.

addison_: So only thing we can validate is that it has a "@ in the middle...

addison_: I'm not volunteering to write a new RFC.

AOB?