- From: Fuqiao Xue <xfq@w3.org>
- Date: Fri, 14 Feb 2025 15:06:08 +0800
- To: www-international@w3.org
https://www.w3.org/2025/02/13-i18n-minutes.html
text version:
– DRAFT –
Internationalization Working Group Teleconference
13 February 2025
[2]Agenda. [3]IRC log.
[2]
https://www.w3.org/events/meetings/b7edae68-f52c-4aab-a1a6-3c37459e0786/20250213T150000/
[3] https://www.w3.org/2025/02/13-i18n-irc
Attendees
Present
addison, Atsushi, Bert, JcK, r12a, Richard, xfq
Regrets
-
Chair
Addison Phillips
Scribe
xfq
Contents
1. [4]Agenda Review
2. [5]Action Items
3. [6]Info Share
4. [7]RADAR Review
5. [8]Pending Issue Review
6. [9]Specdev edits related to TAG design-principles
7. [10]IETF reviews
8. [11]I18N Glossary
9. [12]Summary of action items
Meeting minutes
Agenda Review
Action Items
<addison> [13]https://github.com/w3c/i18n-actions/issues
[13] https://github.com/w3c/i18n-actions/issues
<addison> #156
<gb> [14]Action 156 Figure out what is preferred for Fig 15 at
https://r12a.github.io/scripts/bopomofo/ontheweb#horhor (on
r12a) due 2025-01-28
[14] https://github.com/w3c/i18n-actions/issues/156
<addison> #155
<gb> [15]Action 155 review glossary definitions for normativity
or candidates for normativity (on aphillips) due 2025-01-23
[15] https://github.com/w3c/i18n-actions/issues/155
<addison> #148
<gb> [16]Action 148 propose specdev text related to
design-principles#464 discussion (on aphillips) due 2024-12-12
[16] https://github.com/w3c/i18n-actions/issues/148
<addison> #143
<gb> [17]Action 143 make comments on the encoding issue
attached to i18n-activity#1940 (on aphillips) due 2024-11-28
[17] https://github.com/w3c/i18n-actions/issues/143
<addison> close #143
<gb> Closed [18]issue #143
[18] https://github.com/w3c/i18n-actions/issues/143
<addison> #142
<gb> [19]Action 142 check if we can publish the new version of
jlreq (on himorin) due 2024-11-21
[19] https://github.com/w3c/i18n-actions/issues/142
<addison> #135
<gb> [20]Action 135 follow up on XR issue 1393 about locale in
session (on aphillips) due 2024-10-17
[20] https://github.com/w3c/i18n-actions/issues/135
<addison> #127
<gb> [21]Action 127 make a list of shared topics of interest
between TG2 and W3C-I18N (on aphillips) due 2024-09-30
[21] https://github.com/w3c/i18n-actions/issues/127
<addison> #89
<gb> [22]Action 89 update i18n specs to support dark mode (on
xfq) due 2024-04-18
[22] https://github.com/w3c/i18n-actions/issues/89
<addison> #33
<gb> [23]Action 33 Close issues marked `close?` or bring to WG
for further review (on aphillips)
[23] https://github.com/w3c/i18n-actions/issues/33
<addison> #7
<gb> [24]Action 7 Remind shepherds to tend to their awaiting
comment resolutions (Evergreen) (on aphillips, xfq, himorin,
r12a, bert-github) due 18 Jul 2023
[24] https://github.com/w3c/i18n-actions/issues/7
<addison> #4
<gb> [25]Action 4 Work with respec and bikeshed to provide the
character markup template as easy-to-use markup (on aphillips)
due 27 Jul 2023
[25] https://github.com/w3c/i18n-actions/issues/4
Info Share
RADAR Review
<addison> [26]https://github.com/orgs/w3c/projects/91/views/1
[26] https://github.com/orgs/w3c/projects/91/views/1
Pending Issue Review
<addison> [27]https://github.com/w3c/i18n-activity/
issues?q=is%3Aissue+is%3Aopen+label%3Apending
[27]
https://github.com/w3c/i18n-activity/issues?q=is:issue+is:open+label:pending
Specdev edits related to TAG design-principles
<addison> [28]w3c/bp-i18n-specdev#149
[28] https://github.com/w3c/bp-i18n-specdev/pull/149
<gb> [29]Pull Request 149 Address differences between
DESIGN-PRINCIPLES and SPECDEV (by aphillips) [Agenda+] [Best
Practice] [normative]
[29] https://github.com/w3c/bp-i18n-specdev/pull/149
<addison> [30]https://
deploy-preview-149--bp-i18n-specdev.netlify.app/#char_string
[30]
https://deploy-preview-149--bp-i18n-specdev.netlify.app/#char_string
r12a: the background info appears first now
… the question I had was whether we actually need that first
bit of mustard
Unless you have a reason not to, use a string definition consistent with
DOMString.
r12a: seems kind of redundant
addison: I'll move the explanations and examples box under the
DOMString one
… should I add something to that DOMString one that says this
should be your default choice unless you have a reason not to?
r12a: well, it's kind of like saying this is the default choice
unless it's not the default choice
addison: OK
IETF reviews
addison: I'll make that change
<addison> [31]https://mailarchive.ietf.org/arch/browse/
last-call/?q=unichars
[31] https://mailarchive.ietf.org/arch/browse/last-call/?q=unichars
addison: any objection to publishing it after making that
change?
r12a: I would publish
addison: IETF review
… I published the comments
… there's been some email with Orie
… I'm slighted disincented from wanting to do more IETF
reviews, simply because they're not shaped like our process
… it's usually inconvenient
JcK: couple of observations
… one of which is that to further complicate things, by the
time you submitted these reviews, one of those documents
actually wasn't last called
… and it's not clear whether the author intends to pursue the
other one
… IMO this is the only competent group looking at i18n issues
on an internet-wide basis
… even though we've been avoiding some non-web protocols
addison: for now, I think we'll see how this thread plays out
… y'all are welcome to follow along
… I put the mail archive link so you can find the thread if
you're interested in it
… I'm having a conversation with Mark Davis and I do see
there's some opportunity to do more work at Unicode on a couple
of these things
… because I'm actually having the exact same char repertoire
subset to use in MessageFormat
… so maybe someone should write this down
… I'm more sensitive to Tim's comments
I18N Glossary
<addison> [32]w3c/i18n-actions#155
[32] https://github.com/w3c/i18n-actions/issues/155
<gb> [33]Action 155 review glossary definitions for normativity
or candidates for normativity (on aphillips) due 2025-01-23
[33] https://github.com/w3c/i18n-actions/issues/155
addison: if you go to that issue, you can see I pasted in a
list
… I went through and made a list of things that could be
normative defs if we wanted them to be
… what I was looking for were things that define stuff probably
not defined elsewhere and potentially useful in specs as a term
… you are welcome to throw rocks at any or all of these because
I don't even have a strong opinion
JcK: no rock throwing but a suggestion, it'd be useful for you
to include the terms that are defined elsewhere with cross-refs
addison: this is not to say we would remove the rest of the
entries in the glossary
… this is just attempting to say which ones of these should be
exported as normative
… as opposed to exported as non-normative or not even exported
… we would not reduce the glossary
JcK: OK
… my apologies for my confusion
Bert: nice work
… next step is how to indicate what is normative or not
normative
addison: I'm not sure
… we would still have problem if we didn't make all of our
terms normative
… we would have people using terms that we have that aren't in
this list
JcK: I would claim that Unicode claims that they have normative
defs of char encoding etc.
… I might disagree with such claims but I believe they would
make that claim
r12a: ruby, not sure that ruby should be a formal def
… the Chinese guys for example in clreq don't refer to ruby,
but use interlinear annotations
addison: we could have interlinear annotation and point ruby at
it
r12a: yeah
xfq: clreq decided to use the term 'ruby' but hasn't changed
the document yet
JcK: I'd have to go back and check but I think wall time and
local time are defined in @@1
addison: string direction is ours
… international preferences is ours dating back 20 years
… I don't think it's widely used, is it?
r12a: we should also probably add a link from paragraph
direction to string direction in our glossary
… as a cross-reference
r12a: string direction and paragraph direction i think are two
different parallel things
addison: string direction is the paragraph direction of a
string
r12a: right
… in paragraph direction we should say also go and look at
string direction and in string direction we should say this is
the string-related version of paragraph direction
addison: yes
… we should probably fix that up
… I think improving our glossary is a great idea
… we should do more work here
… the challenge in my mind is what we're trying to accomplish
with the glossary
… and we've had the discussion with plh about normativity
… we've semi-guided people to ignore the warnings from the
tools
… 'if you want to use a term, just link it'
… but i feel uncomfortable continuing to do that
… we could make some of our terms normative
r12a: i though the idea would be that they would actually
rather than point to our glossary they would point directly to
the normative def
… so if there's a def in the segmentation UAX and Unicode for
grapheme cluster, then they could find that by going to our
glossary and we have a link, they can go and use that one over
there
addison: right but that's inconvenient because then if you
think about how respec works you'd have to import all of those
references
… whereas with our glossary you just import us
… or even get it for free from the tools
… this is not actually the normative def but this link right
here will get you there and here's the summary of it
… is that a convenience or should we make people do the extra
step?
JcK: it is a convenience
r12a: if they refer to the original UAX document by date, then
they still have a valid def for the way that they'd use the
concept
example of a spec referring to UAX links by date: [34]https://
www.w3.org/TR/2024/WD-css-text-4-20240529/#biblio-uax11
[34]
https://www.w3.org/TR/2024/WD-css-text-4-20240529/#biblio-uax11
addison: although most people don't, they just refer to the UAX
… it's not necessarily Unicode's fault because they version
things
r12a: but it might become our problem
addison: if we went down this path, it sounds like the glossary
wants to move to the REC track
JcK: I think so
addison: and we would need to go through before we approached
CR
… who wants to work on that project?
… I think it's a worthwhile project
JcK: time permitting, I want to work on parts of it
addison: OK
r12a: by the way, we probably should have a conformance section
in the glossary
addison: if we're a REC then we definitely have to have a
conformance section
xfq: what about registry?
addison: it makes no difference
addison: we would have to be rechartered to produce it, we go
through every one of the terms and attempt to find its way to
find souce def and link it where necessary
… and then we would attempt to go to CR at some point
… we would do wide reviews
xfq: if we do wide review maybe we want to ask for review from
external orgs like Unicode
addison: certainly ask Unicode for a review, and the Infra
folks
JcK: probably should ask IETF
xfq: If people think it's the way forward, I can help, but my
time is limited
addison: we need more people to participate
… this is going to be a multi-year effort
… like charmod fundamentals
r12a: we may end up deciding that actually only 10 of those are
normative things that we'd want to define forever
addison: no, we would do the whole glossary if we went down
that path
… every term would link to some source
… and have a def
r12a: but those wouldn't have to be normative, right?
addison: they would be normative from the point of view that
everyone of them would point to what we meant
… and people could link them
… because they could use them as a skip reference to the actual
source
… that's a Herculean effort
… we could even make a separate document
r12a: separate glossary for the normative terms
addison: I think we should think seriously about this
… maybe the next step is to write a proposal for how we might
accomplish this
ACTION: addison: write glossary proposal identifying options
and next steps for those options
<gb> Created [35]action #157
[35] https://github.com/w3c/i18n-actions/issues/157
addison: we need to think about it
Summary of action items
1. [36]addison: write glossary proposal identifying options
and next steps for those options
Received on Friday, 14 February 2025 07:06:09 UTC