- From: Fuqiao Xue <xfq@w3.org>
- Date: Tue, 19 Sep 2023 15:37:00 +0800
- To: www-international@w3.org
https://www.w3.org/2023/09/11-i18n-minutes.html
– DRAFT –
Internationalization (I18N) TPAC - Day 1 (Monday, 11 September)
11 September 2023
[2]IRC log.
[2] https://www.w3.org/2023/09/11-i18n-irc
Attendees
Present
Addison, Atsushi, Bert, Domenic, Eemeli, Fuqiao, Harald,
Mu-An, Myles, Richard
Regrets
-
Chair
Addison Phillips
Scribe
Bert, xfq
Contents
1. [3]Planning Page Here
2. [4]Agenda
3. [5]prep for webapps, localizability of json format
4. [6]okay to close url#703 ?
5. [7]review WCAG response
6. [8]Webapps
7. [9]RDF prep
8. [10]Summary of action items
Meeting minutes
Planning Page Here
<addison_> [11]https://github.com/w3c/i18n-actions/wiki/
2023-TPAC-Planning
[11] https://github.com/w3c/i18n-actions/wiki/2023-TPAC-Planning
<addison_> [12]https://github.com/w3c/i18n-actions/wiki/
2023-TPAC-Planning
[12] https://github.com/w3c/i18n-actions/wiki/2023-TPAC-Planning
Agenda
<addison_> @hsivonen we're on the bridge now
(Discussion of agenda.)
<r12a> hsivonen, we're investigating...
addison_: Anybody any exciting things to add to the agenda?
xfq: Alan Stearns sent some things for the CSS joint meeting,
see ^^
… We can add more.
<xfq> [13]https://github.com/w3c/csswg-drafts/projects/39
[13] https://github.com/w3c/csswg-drafts/projects/39
prep for webapps, localizability of json format
<addison_> [14]w3c/vc-data-model#1264 (comment)
[14]
https://github.com/w3c/vc-data-model/issues/1264#issuecomment-1713139492
addison_: Verifiable Credentials uses JSON, and some fields
have natural language.
… We told them about language and direction.
… They might have a need for multiple languages, e.g., in case
of language negotiation.
… But they said they have no clean ways to add lang/dir fields.
… The can add an array, but it is still possible to have a
string without lang/dir.
… And they don't like adding @context, because that would need
extra processing beyond straight JSON.
… We have multiple structures. You can have language:string,
but then you dont' have directions.
… And they have questions about setting a document-wide default
languages.
harald: Same question as for WebRTC two years ago?
addison_: Yes
xfq: Difference is that WebRTC is an API and VC is a data
model.
addison_: So far it looks we are not going to get a localizable
string data type in Ecmascript.
… We still need to give guidance for using lang/dir in JSON.
r12a: Can we get more groups in W3C to ask for it in ECMA?
addison_: It already wasn't just my idea.
eemeli: We can propose a stage-0 proposal to TC39.
… The first step has two parts: 1) identify a problem that is
solvable; 2) get a TC39 member as champion to present it into
their TG2.
<xfq> [15]https://www.ecma-international.org/task-groups/
tc39-tg2/
[15] https://www.ecma-international.org/task-groups/tc39-tg2/
eemeli: Trying a different process is likely to get opposition.
addison_: That's helpful.
eemeli: Stage-1 approval means it is a problem that they want
to solve, the motivation exists.
Discussion who is able/has time to lead this.
eemeli: The stage-0 doesn't require having a champion.
eemeli: It might be something for ECMA-262 instead of ECMA-402.
It is in on the boundary.
xfq: The champion needs to be a member of TC39, isn't it?
eemeli: Yes, but the champion get be supported from the
outside.
harald: So we need a flag bearer in TC39 and then people in the
i18n WG to push.
addison_: We need to put together the convincing argument that
the problem needs to be solved and can be solved.
xfq: You [addison] you had meetings with them already, didn't
you?
addison_: Yes, but I have other things that I need to finish.
… And there are other things, in JSON-LD, that we need to work
on, that don't need TC39.
… It is very hard to without first having a pattern for how to
do lang/dir. A datatype would be one way, maybe not the only or
the best.
eemeli: I am already working on two proposals to TC39 already
and soon a third. I can help, but cannot lead another proposal.
xfq: I can maybe do something. How was your, addison's, last
discussion with TC39?
addison_: We had discussions about directions. Dir needs to be
attached to strings, but more convincing to do.
… We have multiple documents explaining it.
… We need to explain that you need both lang and dir.
r12a: What were the doubts they had? Whether it was actually
needed? About the practicality?
addison_: Both.
Domenic: The example code, as mentioned in the thread, would
really help.
… ^^
eemeli: Proposal in ECMAScript for tuples & records that become
immutable seems not progressing.
<Domenic> [16]w3ctag/design-reviews#716 (comment)
[16]
https://github.com/w3ctag/design-reviews/issues/716#issuecomment-1218551452
eemeli: From JS point of view, a localizable string seems
dependent on many other things.
addison_: Talking about the datastructures can be a second
step.
xfq: I can try working on this.
… If addison can introduce me to the ECMA people?
addison_: OK, let eemeli, you and me meet and talk about it
outside this meeting.
ACTION: xfq: work on tc39 proposal (meet with addison and
eemeli to start)
<gb> Created [17]action #42
[17] https://github.com/w3c/i18n-actions/issues/42
<addison_> [18]w3c/vc-data-model#1264 (comment)
[18]
https://github.com/w3c/vc-data-model/issues/1264#issuecomment-1713139492
addison_: That issue for VC I think to provides the options.
<addison_> [19]w3c/manifest#1045
[19] https://github.com/w3c/manifest/issues/1045
<addison_> [20]https://www.w3.org/TR/localizable-manifests/
[20] https://www.w3.org/TR/localizable-manifests/
addison_: Manifest for webapps. Long thread with many attempts
to define localizable strings.
r12a: Our role is to outline problems, we don't always need to
propose the solution.
addison_: We provide best practices. And we don't want
everybody to use a different solution.
… Not different fields with different names. Rather everybody
calls it the same "language" or "document-language" or
something like that.
r12a: We can maybe faciltate the different groups to come
together and find a solution. Don't know exactly how.
addison_: Most groups look back at us what they need to do.
r12a: Yes, if possible, but we are not well enough into these
technologies to propose the solution.
addison_: But it is sort of general. A document with natural
language strings.
… How to localize, how to language-negotiate, can differ.
r12a: Can we set up some sort of coordinate
… coordination group
… where people can together without being members of the i18n
group.
xfq: Who would be in that group?
r12a: Some from i18n, some from other groups.
addison_: We have said you need the metadata. We don't say
where you get the language from.
… We can show some examples.
… A problem is that language maps in JSON do not have the
direction metadata.
Domenic: #1 is would browsers be able to use the lang/dir
metadata. That also depends on the platform APIs.
<gb> [21]CLOSED Issue 1 set up a repo for action tracking (by
ghurlbot)
[21] https://github.com/w3c/i18n-actions/issues/1
Domenic: If the platform doesn't provide it, the discussion
becomes rather theoretical. Few places where the data can be
used.
… And CSS @@
… Backwards-compat:
… In some case maybe you can accept either a string or an
object.
addison_: Browser are pretty good at accepting lang/dir.
… Platforms in general can use it, maybe not on all components.
… In the markup space it clearer.
… Many documents consist of a template that is filled with data
from various sources.
… And we see platform components, e.g., in web payments, being
driven from the browser.
Domenic: In my experience, browser engineers just pass the
strings to the platform API.
… They can pass string + language.
… Just pass it to the OS API.
addison_: The direction stuff needs some time to understand why
you do it.
… If you just pass some English, you'll never see the problems.
… Even if you only pass Arabic, you probably don't see
problems.
… It's the edge cases.
ACTION: addison: pull together the list of win/mac/etc apis
<gb> Created [22]action #43
[22] https://github.com/w3c/i18n-actions/issues/43
Domenic: If you have docs already about how to do this on
Windows and Mac APIs, that would be super helpful.
<myles_> Domenic: BTW, Cocoa string APIs support direction
attributes: [23]https://developer.apple.com/documentation/
uikit/nswritingdirection?language=objc
[23]
https://developer.apple.com/documentation/uikit/nswritingdirection?language=objc
r12a: I don't know those technologies myself. Do we have the
capability to do this?
addison_: I worked with some of them.
xfq: For the manifest case, it is not just for browsers. Also
for app stores and others that can use the metadata.
Myles: Is it also about passing strings from the user to the
app?
addison_: In web payments, e.g., that can also happen,
[break 30 mins]
<addison> [24]https://github.com/w3c/i18n-actions/wiki/
2023-TPAC-Planning
[24] https://github.com/w3c/i18n-actions/wiki/2023-TPAC-Planning
okay to close [25]url#703 ?
[25] https://github.com/w3c/url/issues/703
<gb> [26]Issue 703 [not found]
[26] https://github.com/w3c/url/issues/703
<addison> [27]whatwg/url#703
[27] https://github.com/whatwg/url/issues/703
addison: They are planning to close the issue. Do we have any
comments?
xfq: I think there is nothing for us to do.
addison: OK, close it.
review WCAG response
<addison> [28]w3c/wcag#2680
[28] https://github.com/w3c/wcag/issues/2680
<addison> [29]w3c/wcag#3337
[29] https://github.com/w3c/wcag/issues/3337
<addison> [30]w3c/wcag#3338
[30] https://github.com/w3c/wcag/issues/3338
<addison> [31]w3c/wcag#3351
[31] https://github.com/w3c/wcag/pull/3351
[32]https://www.w3.org/TR/WCAG22/#visual-presentation
[32] https://www.w3.org/TR/WCAG22/#visual-presentation
addison: I think the 1st 2 sentences are related to the
assertions in our call.
… Two separate things.
xfq: So if they remove that sentences, it may be confusing for
peoplew who do not understand the intention.
r12a: I think the sentences are crucial. The q is if they are
clear enough.
addison: I think they are not clear.
r12a: There is also an ‘understanding’ document.
… That gives commentary on the success criteria.
… Text there seems to make it a little clearer.
<addison> [33]w3c/wcag#3337
[33] https://github.com/w3c/wcag/issues/3337
[34]Understanding SC 1.4.8
[34]
https://www.w3.org/WAI/WCAG22/Understanding/visual-presentation.html
addison: let's look at [35]wcag/issues#3337
[35] https://github.com/wcag/issues/issues/3337
<gb> [36]Issue 3337 [not found]
[36] https://github.com/wcag/issues/issues/3337
addison: let's look at [37]w3c/wcag#3337
[37] https://github.com/w3c/wcag/issues/3337
<gb> [38]Issue 3337 Provide exception/limitation text for
visual/presentation text (by aphillips) [Survey - Ready for]
[i18n-needs-resolution] [1.4.8 Visual Presentation] [i18n]
[38] https://github.com/w3c/wcag/issues/3337
addison: the PR is for the ‘understanding’ document.
addison: We thought they would expand the understanding doc and
add a note to the success criteria.
<addison> [39]w3c/wcag#3347
[39] https://github.com/w3c/wcag/pull/3347
Discussion about which PR is for which document.
<addison> [40]https://lists.w3.org/Archives/Member/
member-i18n-core/2023Aug/0017.html
[40]
https://lists.w3.org/Archives/Member/member-i18n-core/2023Aug/0017.html
xfq: It seems there is no change proposed for the understanding
document. The PRs are for the success criteria.
<addison> [41]https://lists.w3.org/Archives/Member/
member-i18n-core/2023Aug/0015.html
[41]
https://lists.w3.org/Archives/Member/member-i18n-core/2023Aug/0015.html
addison: Both 3347 and 3351 are for the success criteria.
… Our notes ^^ from our meeting with them.
<r12a> hsivonen, we're checking...
[42]https://www.w3.org/TR/WCAG22/#text-spacing
[42] https://www.w3.org/TR/WCAG22/#text-spacing
addison: We agreed to add notes.
xfq: I think the notes are useful. I haven't looked at the
change to ‘understanding’ yet.
r12a: It doesn't clearly say you can ignore it of your language
does something different. But I think I saw it somewhere...
… Maybe suggest: s/when a user overrides/if a user overrides/
… (is editorial)
r12a: There was a paragraph that asked to supply back info
about other languages, wasn't there?
[43]w3c/wcag#3347
[43] https://github.com/w3c/wcag/pull/3347
<addison> (one more part of their response, othogonal to what
we're discussing now, was: [44]https://github.com/w3c/wcag3/
discussions/17)
[44] https://github.com/w3c/wcag3/discussions/17)
<addison> [45]https://github.com/w3c/wcag/pull/
3347#discussion_r1311995846
[45] https://github.com/w3c/wcag/pull/3347#discussion_r1311995846
<addison> > <p>If the user chooses to go beyond the metrics
specified, any resulting loss of content or functionality is
the user's responsibility. It is beneficial for users if
authors use any locally available guidance for improving
readability in the local language or writing system.</p>
addison: I think we should re-suggest adding ^^
xfq: Not sure this text is better than the text suggested in
the PR.
addison: The first para is not necessarily better or worse, but
the 2nd para is missing.
… There is nothing that says the guidelines work for a limited
set of languages and ‘your mileage may vary’.
[46]https://github.com/w3c/wcag/pull/3347/files
[46] https://github.com/w3c/wcag/pull/3347/files
xfq: I think that para *is* added, in the understanding doc.
addison: OK
r12a: I think the previous formulation was clearer.
addison: So are we happy with the 1st para? (‘It is not
required that content use the values specified […]’).
… How about the second? (‘Some human languages or writing
systems have different needs and […]’)
xfq: It does not say what people should do in that case.
addison: In the understanding doc, say that the success
criteria ‘does not address’? or ‘does not limit’?
addison: [writing suggested text]
r12a: And swap the last two sentences.
addison: Suggested change is here: [47]https://github.com/w3c/
wcag/pull/3347#pullrequestreview-1619673973
… Let's next look at [48]wcag#3351
[47]
https://github.com/w3c/wcag/pull/3347#pullrequestreview-1619673973
[48] https://github.com/w3c/wcag/issues/3351
<gb> [49]Pull Request 3351 Note under visual presentation (by
alastc)
[49] https://github.com/w3c/wcag/issues/3351
addison: [adding a comment on GitHub:] We recommend that the
notes be similar.
… See [50]https://github.com/w3c/wcag/pull/
3351#discussion_r1321350142
[50] https://github.com/w3c/wcag/pull/3351#discussion_r1321350142
<addison> [51]https://github.com/w3c/wcag3/discussions/17
[51] https://github.com/w3c/wcag3/discussions/17
addison: Issue for WCAG version 3 ^^
r12a: Different languages have different requirements. Probably
more differences for languages than for scripts.
<addison> lunch at 1300 ending at 1430
<addison> Nervion I, Level -1
The joint meeting with WebApps at 14:30 will be in Nervion I,,
level -1.
david_singer: The AB is working on a Vision document, which is
about values. A question I have is how to measure how well we
are doing. Maybe count how many scripts are supported? Maybe
team up with Unicode or others and set a goal, something like
‘25 new scripts by 2025’?
addison: Unicode still working on scripts that are partially
coded. Also CSS working on details, very fine grained. It is
not that there is no support, but there is still work to do.
… Some bigger things, related to direction support.
… We do care about values.
Myles: Language matrix shows language rows. I think David is
asking about the columns.
david_singer: I know it is not as simple.
addison: We have been doing more with languages than with
cultures. But we do want all cultures to access the web.
david_signer: I'd like to know how fast things are changing.
myles: counting specs or implementations?
david_singer: specs, initially, But implementations also
interesting.
How to count? count number of people? but some people may have
alternatives and others not. How do you define ‘is supported’?
Value of ‘small’ languages, if those get less investment.
Stuff to think about for the Vision document over the next
year...
<addison> (joining webapps down in the cool cool basement, aka
Nervion I)
<addison> (note that they are logging on [52]https://
www.w3.org/2023/09/11-webapps-irc#T12-30-29)
[52] https://www.w3.org/2023/09/11-webapps-irc#T12-30-29)
minutes for webapps: [53]https://docs.google.com/document/d/
1RIaeXT_-j8n4iGPI3odZyJTqtHCKqe3oWZTO-j21z9U/
edit#heading=h.5i48hfw584ma
[53]
https://docs.google.com/document/d/1RIaeXT_-j8n4iGPI3odZyJTqtHCKqe3oWZTO-j21z9U/edit#heading=h.5i48hfw584ma
<addison> (back to Bambu)
<addison> (will start at 1545-ish)
Webapps
<addison> (met with webapps about their manifest for one hour
in their room)
<addison> (see above google docs link for notes)
RDF prep
[54]w3c/rdf-concepts#51
[54] https://github.com/w3c/rdf-concepts/issues/51
[55]w3c/rdf-concepts#48
[55] https://github.com/w3c/rdf-concepts/pull/48
addison: The pull request adds directional language-tagged
strings. Says that language tags may be converted to lowercase.
rendered version of the section: [56]https://
pr-preview.s3.amazonaws.com/w3c/rdf-concepts/pull/
48.html#section-text-direction
[56]
https://pr-preview.s3.amazonaws.com/w3c/rdf-concepts/pull/48.html#section-text-direction
addison: [writing a comment about the section on Initial Text
Direction to clarify the intended rendering order of the
example.]
<addison> meeting adjourned for today.
Summary of action items
1. [57]xfq: work on tc39 proposal (meet with addison and
eemeli to start)
2. [58]addison: pull together the list of win/mac/etc apis
Received on Tuesday, 19 September 2023 07:37:02 UTC