Meeting minutes
Agenda Review
Action Items
<addison> #85
<gb> Action 85 send a note to privacy folks saying we did a review with notes about i18n (on aphillips) due 2024-03-28
<addison> #84
<gb> Action 84 follow up on i18n-glossary#51 (on r12a) due 2024-03-21
r12a: re #84, I wrote what I think we should do in the issue and somebody needs to do it
<addison> #82
<gb> Action 82 publish khmer lreq with new format (on r12a) due 2024-03-21
<addison> #79
<gb> Action 79 schedule a follow-up call with WHATNOT in ~April (on aphillips) due 2024-03-07
<addison> #78
<gb> Action 78 compare infra to i18n-glossary export list and report back (on aphillips) due 2024-03-07
<addison> #77
<gb> Action 77 create an issue against html requesting the list of named entities based on work in action 73 (on r12a) due 2024-03-07
<r12a> w3c/
<gb> Issue 1841 Request for additional named entities for invisible/ambiguous characters (by r12a) [pending] [s:html] [t:char_ref]
r12a: re #77, I have created a pending issue for people to look at
<addison> #76
<gb> Action 76 propose best practices for producers and for examples in specs in string-meta (on aphillips) due 2024-03-07
<addison> #75
<gb> Action 75 work on developing new specdev material about IDNs/domain names/etc. (on xfq) due 2024-02-29
<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
<addison> #33
<gb> Action 33 Close issues marked `close?` or bring to WG for further review (on aphillips)
<addison> #12
<gb> Action 12 Upgrade/edit the explainer to address issues raised by google (on aphillips) due 18 Jul 2023
addison: re #12, I think I'm done editing the explainer
<addison> #8
<gb> Action 8 Follow up on the status of Canvas and formatted text (on aphillips) due 18 Jul 2023
addison: we can review it again together in an upcoming call
<addison> #4
<gb> Action 4 Work with respec and bikeshed to provide the character markup template as easy-to-use markup (on r12a) due 27 Jul 2023
<r12a> w3c/
<gb> Issue 4462 Provide a shortcut for typing character markup (by r12a) [Feature request]
r12a: re #4, seems to be potentially making some progress, see ^
Info Share
JcK: more colors and cuter fonts in the new IRC client
RADAR Review
[GB 18030 discussions]
Pending Issue Review
<addison> w3c/i18n-activity#1841
<gb> Issue 1841 Request for additional named entities for invisible/ambiguous characters (by r12a) [pending] [s:html] [t:char_ref]
FPWD of Khmer Layout Requirements
<r12a4> https://
addison: r12a, you want to propose the first draft note of the Khmer Layout Requirements, correct?
r12a: correct
<r12a4> https://
r12a: see ^
addison: we need to vote on publishing this
<xfq> +1
<addison> +1
<r12a4> +1
<Bert> +1
<JcK> 0
<r12a4> https://
<JcK> Have not been able to find time to review
RESOLUTION: publish Khmer Layout Requirements as FPWD
<r12a4> https://
r12a: here's another link for Tibetan
… I'm doing the same for Tibetan
… I realised that I wasn't gonna put the links at the bottom of the section
… I was going to put them at the top of the section
… because that's more useful and clear
MathML review
addison: cool. Thank you.
<addison> #1834
<gb> Issue 1834 not found
<addison> w3c/i18n-activity#1834
<gb> Issue 1834 Clarify note on single character of mi as italic (by himorin) [pending] [s:mathml] [wg:math]
Bert: about #1834, it's not quite clear what the spec is saying
… whether it's a letter
… as far as I'm concerned, the example is allowed to be a little less precise than the normative text
<JcK> Richard, once the Tibetan version is ready to be made a bit more public, I probably have a lead on good reviewers who read and write the language daily are are very concerned about it.
<addison> ... On text nodes containing a single characters (after whitespace has been removed)...
Bert: @@1
<addison> w3c/i18n-activity#1837
<gb> Issue 1837 lspace/rspace have confusing names (by bert-github) [pending] [s:mathml]
Bert: the lspace and rspace attributes in mathml are very old
… they're already in the first mathml which is 20+ years old
… they are now logical
… so we could add a note to say that it's not physical
<Bert> https://
Bert: 2 possible places, the first intro of the attributes
… or how it is laid out
<addison> w3c/i18n-activity#1838
<gb> Issue 1838 Whether/when to mirror operators (by bert-github) [pending] [s:mathml]
addison: objections?
Bert: certain operators are mirrored in rtl formulas
… mathml doesn't mention this
<addison> w3/i18n-activity#1839
<gb> Issue 1839 not found
<addison> w3c/i18n-activity#1839
<gb> Issue 1839 Define that (and how) glyph assemblies are mirrored in rtl formulas (by bert-github) [pending] [s:mathml]
Bert: @@2
… There is a document on the Unicode site
https://
Bert: from Kent Karlsson
… from 2 years ago
ACTION: addison: ping the UTC about the status of the mirroring proposal
<gb> Created action #86
Bert: talks exactly about these extension characters
… but I haven't found any other reference to that
<addison> w3c/i18n-activity#1840
<gb> Issue 1840 Explain the mapping tables (appendix C) (by bert-github) [pending] [s:mathml]
Bert: the MathML3 spec and the MathML Core spec are not consistent
… it's a bit unclear
… my question is what are those tables for
… are they indeed for that purpose and why
… if so, why doesn't the spec say that they are for that purpose?
… why are those tables are there?
RFC9457 and string-meta
<addison> RFC9457 defines a JSON (and alternate XML) structure for returning error information. Seems like they could follow our guidance in string-meta and include lang/dir metadata in the document. They do provide for localization externally by doing language negotiation off of Accept-Language, but it seems criminal not to tell the recipient what language
<addison> was negotiated??
addison: RFC 9457 describes a JSON structure and separately in XML for responding with additional info when an error is produced
… for example, if you produce the forbidden HTTP response it could include human readable description of what was forbidden and why
… like your password was wrong or something like that
… that standard does not include any language or direction annotation for the human language strings
… it seems like it ought to
… there doesn't seem to be a reason not to provide it
ACTION: addison: write to IETF ADs about RFC9457 with JcK's assistance
<gb> Created action #87
<addison> rfc-editor.org/rfc/rfc9457.html
String-meta best practices for producers
<addison> w3c/
<gb> Pull Request 86 Add best practices for writing examples and for producers (by aphillips)
<addison> https://
addison: I had an action item to write best practices for writing examples and for producers
… I welcome comments on it
Specdev changes to support IDNs
<addison> w3c/
<gb> Pull Request 128 New section about IDNs (by xfq)
<addison> https://
[Tanych/accept-language] I18N objections to reducing accept-language
xfq: not ready for review yet
<addison> Tanych/
<gb> Issue 10 I18N objections to reducing accept-language (by aphillips)
addison: some time ago, there's a proposal to reduce accept-language to a single value
<addison> https://
addison: I was actioned at some point to reply to them saying we don't think that's a great idea
… with 2 comments
… safari users can only have one language preference
… the second comment is: can you give me any site or code example to understand better about the accept-language use cases for i18n?
<r12a-webkit> https://
addison: do we have an article about language negotiation somewhere?
… I haven't looked at it in a while
r12a-webkit: there's a bunch of stuff here ^
… there is even an article called Accept-Language used for locale setting
addison: the stuff here hasn't been updated in a while
addison: I have a long thing that I wrote outside of standards land about language negotiation
… which with only a little bit of work could probably be adapted appropriately
… I don't have time right now, though
r12a-webkit: why do they want to do that?
xfq: to reduce fingerprinting
addison: the A-L header is potentially a fingerprinting vector because if you put enough things in it, it could be unique
AOB?
xfq: @@