- From: r12a <ishida@w3.org>
- Date: Thu, 10 Jun 2021 17:08:04 +0100
- To: www-international@w3.org
- Message-ID: <f20ae2f1-c75d-66f0-b291-4c29498a97d6@w3.org>
https://www.w3.org/2021/06/10-i18n-minutes.html
– DRAFT –
Internationalization Working Group Teleconference
10 June 2021
[2]Agenda. [3]IRC log.
[2] https://lists.w3.org/Archives/Member/member-i18n-core/2021Jun/0004.html
[3] https://www.w3.org/2021/06/10-i18n-irc
Attendees
Present
Addison, Atsushi, Fuqiao, Richard
Regrets
JcK
Chair
Addison Phillips
Scribe
fsasaki, xfq
Contents
1. [4]Agenda
2. [5]Action Items
3. [6]Info Share
4. [7]Radar
5. [8]Review comments for timing specs
6. [9]CSS Counter Styles
7. [10]String-Meta
8. [11]AOB?
Meeting minutes
<addison> trackbot, prepare teleconference
Agenda
Action Items
<addison> [12]https://www.w3.org/International/track/actions/
open
[12] https://www.w3.org/International/track/actions/open
action-925?
<trackbot> [13]action-925: Addison Phillips to Update
string-meta to include json-ld changes, etc. -- due 2020-07-09
-- OPEN
[13] https://www.w3.org/International/track/actions/925
addison: started on that
action-946?
<trackbot> [14]action-946: Addison Phillips to Create
definition of 'ltr'/'rtl'/'auto' that can be referenced by
other specifications in string-meta -- due 2020-09-03 -- OPEN
[14] https://www.w3.org/International/track/actions/946
done by addison :)
close action-946
<trackbot> Closed action-946.
action-1017?
<trackbot> [15]action-1017: Addison Phillips to Send wpwg list
of specs that implement lang/dir -- due 2021-04-22 -- OPEN
[15] https://www.w3.org/International/track/actions/1017
addison: pending
action-1031?
<trackbot> [16]action-1031: Addison Phillips to Document the
state of payment-request -- due 2021-06-03 -- OPEN
[16] https://www.w3.org/International/track/actions/1031
addison: sent note to chairs, will keep action open until the
github issue is update
action-1032?
<trackbot> [17]action-1032: Richard Ishida to Propose text for
html 4814 (datalist find/string search) -- due 2021-06-03 --
OPEN
[17] https://www.w3.org/International/track/actions/1032
richard: pending
action-1033?
<trackbot> [18]action-1033: Addison Phillips to Create skeleton
of "best practices for manifests" -- due 2021-06-10 -- OPEN
[18] https://www.w3.org/International/track/actions/1033
addison: done
close action-1033
<trackbot> Closed action-1033.
Info Share
Radar
<addison> [19]https://github.com/w3c/i18n-request/projects/1
[19] https://github.com/w3c/i18n-request/projects/1
addison: css counter styles, richard responed to fantasai
… is "in review", is deeper review needed?
richard: did not see anything that is a concern for us
… small editorial thing has been fixed
… review is done, nothing to report
… we can move this to "done"
addison: any volunteer to read counter styles? just move it to
done
xfq: I will have a look
richard: hope that this will be published as rec
xfq: chris and I go through all CSS specs, see what should be
re-published
… need to look at the tests for counter styles
addison: so some period after CR publication will be available
xfq: last CR was 4 years ago
richard: the review I did is an update of the current spec
… not 4 years old, brand new again
addison: will go through normal CR & PR process
atsushi: resource timing and user timing, is completed, part of
the agenda
… there is no issue for resource timing
addison: so I move the doc to completed?
atsushi: yes
addison: will do
… performance timeline is incoming
atsushi: will take this
xfq: closely related to timing specs
Review comments for timing specs
<atsushi> [20]https://github.com/w3c/i18n-activity/issues/1392
[20] https://github.com/w3c/i18n-activity/issues/1392
atsushi: from level 2 to level 3, one feature was added
… convert to timestamp function
… in their ticket, "storing match" is defined as match
richard: what does a timestamp look like?
atsushi: something from page load, a numeric value
xfq: millisecond value
addison: since epoc, or millisecond lapsed?
atsushi: from epoch, I think
… but could be both, per implementation
atsushi: used to measure the marks between two points
… output from the two marks is important
richard: is the spec saying that they produce human readable
output?
atsushi: user can define mark or @@@
<atsushi> [21]https://w3c.github.io/user-timing/#example-1
[21] https://w3c.github.io/user-timing/#example-1
atsushi: see performance mark with text label
… each label can be defined by a developer
addison: developer can name them, but these are just IDs, the
rest is just numbers (time of milliseconds)
atsushi: yes
atsushi describing various process options
addison: using "is" is a good use of this, because otherwise
they do not define matches
<Bert> +1
addison: any objections about this comment? Other observations?
+1
<xfq> +1
addison: atsushi, please file the comment
… I will move the doc to "awaiting comment resolution"
CSS Counter Styles
<r12a> [22]https://www.w3.org/TR/predefined-counter-styles/
[22] https://www.w3.org/TR/predefined-counter-styles/
<addison> [23]https://lists.w3.org/Archives/Member/
member-i18n-core/2021Jun/0006.html
[23] https://lists.w3.org/Archives/Member/member-i18n-core/2021Jun/0006.html
richard: there is a new version on TR
… xfq published the doc
… I published more docs yesterday
… counter styles changes are:
<r12a> [24]https://www.w3.org/TR/predefined-counter-styles/
[24] https://www.w3.org/TR/predefined-counter-styles/
<r12a> [25]https://www.w3.org/TR/
predefined-counter-styles/#affixes
[25] https://www.w3.org/TR/predefined-counter-styles/#affixes
richard: section 1.1: we got examples about suffixes and
prefixes
… seemed to me that it would start to make the doc very large
… so I say: we define the base algorithm
… and we say: we used the common default, and a note saying
"these are common ways to do the affixes"
… so we have notes instead of dublicating the styles
… a section shows how to have a different separator, using the
"extends" keyword
… andrew cunningham is still clarifying things, with a delay
due to the situation in Myanmar
<addison> [26]https://www.w3.org/TR/
predefined-counter-styles/#myanmar-styles
[26] https://www.w3.org/TR/predefined-counter-styles/#myanmar-styles
<r12a> Alternative prefix/suffix styles
<r12a> [27]https://www.w3.org/TR/
predefined-counter-styles/#myanmar-styles
[27] https://www.w3.org/TR/predefined-counter-styles/#myanmar-styles
richard: I changed Myanmar, it used to have default space
suffix
… parenthesis is more common, it seems
richard: moved japanese and korean stuff into "japanese and
korean" section
… added bunch of other stuff
<r12a> [28]https://www.w3.org/TR/2021/
NOTE-predefined-counter-styles-20210606/#app-c
[28] https://www.w3.org/TR/2021/NOTE-predefined-counter-styles-20210606/#app-c
richard: we are in good position with the doc, I think
… also went through tests in the test suite and the gap
analysis
addison: very cool!
… should this be a "statement" in the new process?
richard: no
… we update this regularly, once we get more information
<xfq> [29]https://www.w3.org/Consortium/Process/
Drafts/#registries
[29] https://www.w3.org/Consortium/Process/Drafts/#registries
richard: you can use whatever keyword you want
… so there is no "normative" recommendation, just stuff you may
want to use
… also no intend to cover all things you need, or limit things
addison: ok
String-Meta
<addison> [30]https://github.com/w3c/string-meta/pull/55
[30] https://github.com/w3c/string-meta/pull/55
addison: pull request has bidi keywords in it
… I added small subsection
… xfq commented that basically ltr and rtl refers to CSS, auto
refers to definition in HTML
… question whether I should bring definitions here or put them
by reference
… started to indicate difference between ltr and cases to bring
in auto
… open the floor to comments
richard: there might places where you need to use metadata,
which resolves through other rules to left-to-right
… if the direction of content is not known, you should use auto
rules
addison: if there is no direction, you use auto
richard: you use auto
addison: that is UBA
richard: auto says: use the UBA
… if you do not have auto, things are up to the application
<addison> <p dir=ltr>dldld <span dir=auto>...</span>.... </p>
richard: discussing section 2.4 ... that is "auto"
addison: my thinking is two-fold:
… if you send s.t., you should indicate the direction
… if you do not know the direction, "auto" is not helpful
richard: agree
addison: if you do not know the direction, do not send it
… if you define e.g. HTML, you need all three values
r12a: some of the formats for which we wrote this document
… we do recommend auto
addison: we recommend the auto heuristics, but not necessarily
the auto keyword
… two things
… first is define the direction, the dir attribute
… under what situations you will allow those values and consume
r12a: is there a problem if somebody uses the auto label?
addison: i think i have enough information to do some more
edits
… do we want to draw specific distinctions or recommendations
for when to use direction and when to use dir
r12a: I read that and I had the same question
addison: i could be less prescriptive and just leave that aside
… we would be super sad to see both
r12a: you could have lang and language
addison: it's the same problem
r12a: language is usually used for metadata
epub: [31]https://w3c.github.io/epub-specs/epub33/
core/#sec-shared-attrs
[31] https://w3c.github.io/epub-specs/epub33/core/#sec-shared-attrs
Publication Manifest: [32]https://www.w3.org/TR/
pub-manifest/#manifest-lang-dir-global
[32] https://www.w3.org/TR/pub-manifest/#manifest-lang-dir-global
<addison> "property" not "data value"
addison: i'll take another whack at it
bert: i like it
AOB?
addison: developing localizable manifests
… i used respec to create the draft
… i used i18n-draft as the home
… r12a do you suggest we should just make a new repo?
r12a: it may end up being a very short note
… if it's going to be an article it should be in an article
format
xfq: If we are writing for spec developers, a note might be
better
r12a: if we decide to make it into an article we don't want it
to be in a repo
addison: i'll move it to temp and we'll discuss whether it
should be a note
r12a: it depends on whether we're going to have mustards in it
addison: it's a best practice document
r12a: mustards are not normative, they are recommendations
… a way of getting the message across
… it wasn't to say these are the normative bits
… even in charmod fundamental
addison: if you have comments on the text
… that would be super useful
… i'll email the list
<atsushi> I had the same issue for today's another meeting...
Received on Thursday, 10 June 2021 16:10:59 UTC