Meeting minutes
Planning Page Here
<addison_> https://
<addison_> https://
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.
prep for webapps, localizability of json format
<addison_> w3c/
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> https://
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> w3ctag/
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 action #42
<addison_> w3c/
addison_: That issue for VC I think to provides the options.
<addison_> w3c/
<addison_> https://
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> CLOSED Issue 1 set up a repo for action tracking (by ghurlbot)
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 action #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: https://
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> https://
okay to close url#703 ?
<gb> Issue 703 [not found]
<addison> whatwg/
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> w3c/
<addison> w3c/
<addison> w3c/
<addison> w3c/
https://
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> w3c/
addison: let's look at wcag/issues#3337
<gb> Issue 3337 [not found]
addison: let's look at w3c/wcag#3337
<gb> Issue 3337 Provide exception/limitation text for visual/presentation text (by aphillips) [Survey - Ready for] [i18n-needs-resolution] [1.4.8 Visual Presentation] [i18n]
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> w3c/
Discussion about which PR is for which document.
<addison> https://
xfq: It seems there is no change proposed for the understanding document. The PRs are for the success criteria.
<addison> https://
addison: Both 3347 and 3351 are for the success criteria.
… Our notes ^^ from our meeting with them.
<r12a> hsivonen, we're checking...
https://
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?
<addison> (one more part of their response, othogonal to what we're discussing now, was: https://
<addison> https://
<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’.
https://
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: https://
… Let's next look at wcag#3351
<gb> Pull Request 3351 Note under visual presentation (by alastc)
addison: [adding a comment on GitHub:] We recommend that the notes be similar.
… See https://
<addison> https://
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 https://
minutes for webapps: https://
<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
addison: The pull request adds directional language-tagged strings. Says that language tags may be converted to lowercase.
rendered version of the section: https://
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.