W3C

- DRAFT -

Internationalization Working Group Teleconference

09 Apr 2020

Agenda

Attendees

Present
addison, fuqiao, atsushi, Bert, richard, Felix, JcK
Regrets
Chair
Addison Phillips
Scribe
addison

Contents


trackbot, parepare teleconference

<trackbot> Sorry, addison, I don't understand 'trackbot, parepare teleconference'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

trackbot, prepare teleconference

<scribe> scribenick: addison

<agendabot> clear agenda

Agenda and Minutes

Action Items

https://www.w3.org/International/track/actions/open

action-870?

<trackbot> action-870 -- Addison Phillips to Write scope statement for locale-related work -- due 2020-03-19 -- OPEN

<trackbot> https://www.w3.org/International/track/actions/870

close action-870

<trackbot> Closed action-870.

action-872?

<trackbot> action-872 -- Addison Phillips to Convert personalization-semantics comments into separate issues putting needs-resolution and tracker labels -- due 2020-03-26 -- OPEN

<trackbot> https://www.w3.org/International/track/actions/872

close action-872

<trackbot> Closed action-872.

action-881?

<trackbot> action-881 -- Richard Ishida to Set up simple-ruby repo -- due 2020-04-02 -- OPEN

<trackbot> https://www.w3.org/International/track/actions/881

close action-881

<trackbot> Closed action-881.

action-884?

<trackbot> action-884 -- Addison Phillips to Revise comment in issue 871 for consideration next week -- due 2020-04-09 -- OPEN

<trackbot> https://www.w3.org/International/track/actions/884

close action-884

<trackbot> Closed action-884.

action-885?

<trackbot> action-885 -- Felix Sasaki to Investigate if any more work needs doing in rdf for language and direction metadata -- due 2020-04-09 -- OPEN

<trackbot> https://www.w3.org/International/track/actions/885

close action-885

<trackbot> Closed action-885.

Info Share

xfq: as you may know, the next version of Unicode to be released in september instead of march

<xfq> Virtual FTF on font fingerprinting on 4/14 https://lists.w3.org/Archives/Member/w3c-css-wg/2020AprJun/0017.html

xfq: css wg will hold a f2f on font fingerprinting next week
... since we've discussed before, if interested, can talk to alan to invite you

jck: you mean the next major version of unicode is 14 in september 2021

xfq: correct

RADAR Review

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

Consider Simple-Ruby for wide review

richard: jlreq had an ad hoc meeting to discuss aims and objectives of doc
... became clear that there was not yet consensus
... result of meeting was agreed to publish doc
... but kobayashi-sensei will provide text for the intro explaining how doc is positioned
... and there are a few odds and ends
... wrote back and asked "what's the outlook"
... haven't heard back yet (this is just today)
... so small delay

Language/direction metadata in RDF-related specs

felix: found that there is no standards group/body taking up issue
... had most feedback from ontolex
... their impression is they see bcp47 lacks granularity in some areas
... such as diachronic variations of a language
... they said defining uris would be a way to fill gap
... browsed examples they gave
... in these cases a lot of additional information was given
... with uris, you can add addition info, e.g. location, number speakers, etc.
... the argumentation about validation
... such as combination of subtags; I argued that bcp47 ABNF allows vast number of combinations
... the "here we go again", it's a long discussion and not a clear group of stakeholders
... speaking in terms of W3C, there is no industry group. mostly academics

richard: part of concern is that, reading through threads
... they don't understand bcp47 terribly well
... for example one person suggested iso639, not understanding that number of subtags there is only part
... "can you validate", etc.
... how can we better education?
... we talked about the infinity of URIs might be worked around with one per subtag
... it would be a large number but not an infinitude

jck: to describe a language you'd need several URIs instead of just a tag

richard: they weren't suggesting a solution per se

felix: same issues; a lot of education needed
... on argument that I don't have answer for is dischronic variants
... also academic corpus, might need additional info
... private use for accepted varieties
... hard to get academic communities to get them to register subtags, etc.
... currently users are global usership while academics are narrow

addison: sounds like an extension or a side-standard; not like 639 solves this for them

felix: bcp47 community doesn't need URIs either
... just validate or use registry
... from an accepted standards body, counterpart for registry in URIs
... bcp47 community that is *not* fragmented
... would not be a big deal to create URIs for subtag
... if from accepted standards body, could foster accpetance

jck: not clear what their problem is
... what could come back to, end up with a lot more URIs than expected
... representation might be matter of taste
... don't understand problem

felix: having URI embedded instead of string

jck: invent a syntax with the tag in the tail and then we move along :-)

richard: one of the main reasons was tools and specs don't say how you could do this thing

jck: two ways; put tag in tail or turn into set of name-value pairs
... if we need to make a (very short) doc pushed through

richard: one of the issues I seem to perceive
... bcp47 was not perceived as accurate enough or specific enough
... but a problem with that people who use bcp47 use it in a non-specific way
... can be ambiguous
... I wrote a doc about Kurdish in Arabic and then in Devanagari script
... and I use bcp47. I don't say ks-Arab in one and ks-Deva in the other because don't need to
... if in same document, then I might need to
... so the tag I use is 'ks'
... and that's perfectly valid. Don't have to be overly specific and it's application specific
... more problematic vs. very specific URLs

addison: problem is that there isn't a way to use @lang or @dir in RDF so we have a gap linking standards together; what to do?

felix: could invite christian to a following call

addison: we're public and could talk to other groups
... sense of WG? want to?

richard: one worry is that discuss is in email; can we move to github?
... had a look at ontolex, but didn't see where to discuss there

felix: github makes sense
... could also make discussion in github first

<scribe> ACTION: fsasaki: create github issue to discuss RDF bcp47 issue in i18n-discuss repo

<trackbot> Created ACTION-886 - Create github issue to discuss rdf bcp47 issue in i18n-discuss repo [on Felix Sasaki - due 2020-04-16].

<r12a> https://github.com/w3c/i18n-discuss/issues

CSS generic fonts

https://github.com/w3c/csswg-drafts/issues/4910

(addison summarizes)

richard: did you read the discuss from fantasai?
... (quoting from link) create generic names for unicode ranges? or script codes?

<xfq> https://lists.w3.org/Archives/Public/www-style/2020Feb/0013.html

<xfq> link from fantasai ^

richard: thinking of shoe-horning into existing categories and also thinking of new categories
... thinking that new keywords that are particular to script needs is better
... so naskh and nastaliq and ruqah for arabic; slanted/upright for thai/khmer, etc.
... a whole bunch of scripts that you use the different writing style for particular purpose
... semantic like heading vs. body
... or want text to look in partiular way
... think that if you put stuff on web and don't have font you need on user system
... should look for another font of similar type
... maintains the distinction

xfq: if generic fonts installed, no need to make network request for webfont

jck: remembering discussions in another context
... they have no idea what they are getting into
... deciding what font is a substitute for another is difficult
... requires magic

richard: wrote a post in one of these threads
... first knee jerk reaction is that browsers have to make a list of fonts
... not sure that's necessary
... know and can classify system fonts or choose one; leave open to user who cares to customize
... I think we do choose sans/serif as a default
... difficult for average English-speaker to understand e.g. arabic script choices, but not for them

jck: can get into trouble, such as quranic example

<atsushi> (actually, same for me...)

richard: css meeting upcoming, perhaps book a slot

xfq: the fingerprinting or next v-f2f?

richard: next v-f2f, which is different

xfq: can add

jck: make distinction between type style family and a font is useful

richard: and a writing style yet again

<scribe> ACTION: xfq: request a slot to discuss generic font family rules in next css virtual f2f

<trackbot> Created ACTION-887 - Request a slot to discuss generic font family rules in next css virtual f2f [on Fuqiao Xue - due 2020-04-16].

AOB?

Summary of Action Items

[NEW] ACTION: fsasaki: create github issue to discuss RDF bcp47 issue in i18n-discuss repo
[NEW] ACTION: xfq: request a slot to discuss generic font family rules in next css virtual f2f
 

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/04/09 15:51:15 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/understand e.g. arabic script choices/understand e.g. arabic script choices, but not for them/
Default Present: addison, fuqiao, atsushi, Bert, richard, Felix, JcK
Present: addison fuqiao atsushi Bert richard Felix JcK
Found ScribeNick: addison
Inferring Scribes: addison
Agenda: https://lists.w3.org/Archives/Member/member-i18n-core/2020Apr/0005.html
Found Date: 09 Apr 2020
People with action items: create fsasaki github issue xfq

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]