- From: Fuqiao Xue <xfq@w3.org>
- Date: Fri, 27 Oct 2023 10:43:46 +0800
- To: www-international@w3.org
https://www.w3.org/2023/10/26-i18n-minutes.html
text version:
[1]W3C
[1] https://www.w3.org/
– DRAFT –
Internationalization Working Group Teleconference
26 October 2023
[2]Agenda. [3]IRC log.
[2]
https://www.w3.org/events/meetings/c5b143d1-0a5b-4adb-8d60-0f5f9bfe5a41/20231026T150000/
[3] https://www.w3.org/2023/10/26-i18n-irc
Attendees
Present
Addison, Atsushi, Fuqiao, r12a
Regrets
JcK
Chair
Addison Phillips
Scribe
atsushi, xfq
Contents
1. [4]Action Items
2. [5]Info Share
3. [6]RADAR Review
4. [7]no needs-resolution on vc-json-schema
5. [8]Working with String Data Values (draft)
6. [9]AOB?
7. [10]Summary of action items
Meeting minutes
Action Items
xfq: there was some discussion on i18n-CSS joint call
<addison> #54
<gb> [11]Action 54 read Murata-san's ruby-t2s-req and Chinese
requirements and Zaima and see what we're going to do (on xfq)
due 2023-11-01
[11] https://github.com/w3c/i18n-actions/issues/54
addison: on ruby text-to-speech, what was discussion there and
comment from Murata-san?
<xfq> [12]https://w3c.github.io/ruby-t2s-req/
[12] https://w3c.github.io/ruby-t2s-req/
xfq: see link above for tracker issue
… murata-san has been working on this document for a while
… florian pointed this during i18n-css call
… this document explains ruby requirements from Japanese point
of view
… and discussion was raised to see any additional requirement
from clreq or other languages
<xfq> Zaima
xfq: I'll read Zaima document and will comment
<addison> #53
<gb> [13]Action 53 come up with a set of information CSS want
the i18n group to provide support for generic font families (on
frivoal, fantasai) due 2023-11-01
[13] https://github.com/w3c/i18n-actions/issues/53
addison: florian and fantasai presented on generic font support
for i18n point of view
… we had some discussion on generic font name, and had some
idea for proposal
xfq: there seems some discussion on registries like document,
but florian seems to have some disagreement on having such
… and framwork has not been initiated yet
Info Share
addison: published specdev to /TR/
atsushi: Murata-san complained about replaced simple-ruby in
jlreq
[14]w3c/i18n-activity#1779
[14] https://github.com/w3c/i18n-activity/issues/1779
<gb> [15]Issue 1779 [css-text] Extra spacing between ideographs
and non-fullwidth punctuation/symbols (by w3cbot) [tracker]
[s:css-text] [i:spacing] [spec-type-issue] [jlreq] [clreq]
[t:typ_misc]
[15] https://github.com/w3c/i18n-activity/issues/1779
[16]https://w3c.github.io/jlreq/docs/simple-ruby/
[16] https://w3c.github.io/jlreq/docs/simple-ruby/
xfq: have one point on text-spacing
… between ideograph and other characters
… this should be promoted to needs-resolution, since it's under
real implementation
… and discussion is required sonner than later
… there are several issues identified
… spacing between ideographs and others like wester characters,
but there are open question on ideograph-like characters
addison: that seems reasonable to mark as needs-resolution
atsushi: as I reported in i18n/CSS call, there was so much
ambiguity in the general category code
… a lot of discussions about things like halfwidth kana
… we may have some questions in the next jlreq call next
Tuesday
addison: if the spec isn't quite right or the implementations
aren't quite right
… then we should push on it
atsushi: one interesting discussion is Circled Katakana
characters
… combining characters are quite messy
RADAR Review
<addison> [17]https://github.com/w3c/i18n-request/projects/1
[17] https://github.com/w3c/i18n-request/projects/1
no needs-resolution on vc-json-schema
atsushi: the spec has a i18n considerations section
… I believe there's no need to have a i18n considerations
section, because the considerations are in another spec
… I raised an issue in i18n-activity
[18]w3c/i18n-activity#1786
[18] https://github.com/w3c/i18n-activity/issues/1786
<gb> [19]Issue 1786 [VC-JSON-SCHEMA] overwritting
internationalization consideration section? (by himorin)
[pending] [s:vc-json-schema]
[19] https://github.com/w3c/i18n-activity/issues/1786
<addison> [20]https://www.w3.org/TR/
vc-json-schema/#example-example-name-credential-schema
[20]
https://www.w3.org/TR/vc-json-schema/#example-example-name-credential-schema
addison: I do see they have some examples that have name and
description fields
… and they're not serialised with lang and dir metadata
… their example should include language=en and direction=ltr
… either at the document level or for those fields
… this document is about other stuff, but they exemplify
natural language strings
<addison> "name": "Name schema", "description": "A schema
capturing a human name",
addison: there's nothing wrong with the serialisation stuff and
it's all valid JSON Schema
[21]Schema.org
[21] https://schema.org/
[22]JSON Schema
[22] https://json-schema.org/
[23]https://json-schema.org/specification
[23] https://json-schema.org/specification
atsushi: JSON Schema doesn't have anything about language and
direction metadata
<gb> [24]Issue 108 JSON schema (by dontcallmedom) [Data]
[24] https://github.com/w3c/strategy/issues/108
addison: file that issue and I'll move it over to Awaiting
comment resolution
Working with String Data Values (draft)
<addison> [25]https://
deploy-preview-121--bp-i18n-specdev.netlify.app/#working-with-n
on-localizable-and-localizable-data-values
[25]
https://deploy-preview-121--bp-i18n-specdev.netlify.app/#working-with-non-localizable-and-localizable-data-values
addison: this is from my action item
<addison> [26]https://
deploy-preview-121--bp-i18n-specdev.netlify.app/#working-with-s
tring-data-values
[26]
https://deploy-preview-121--bp-i18n-specdev.netlify.app/#working-with-string-data-values
addison: see hashed link above
… early days I wanted to see feedbacks on these sections
addison: whole new section
<addison> [27]w3c/bp-i18n-specdev#121
[27] https://github.com/w3c/bp-i18n-specdev/pull/121
<r12a> specificatino -> specification
xfq: second paragraph, above typo exists
asigning -> assigning
r12a: couple of questions, this is in markup and syntax
section, not quite sure why this is not in more general advice
… what is the point of this 8.3 section
… what we are saying in this section is not matching with title
… string data values are very bake, you also categorize normal
as down style
<xfq> maybe "predefined values" or "predefined constants"?
addison: section marked as this is elements and attributes are
identified as markup
… names and values are written in syntax
… we may state these to be syntaxed as well defined
r12a: what we should do for strings and captalized schema
addison: this is between strings and predefined strings, or
seriarized strings
r12a: syntax is small, and could drop from here
… idea is to have specific markup, or perhaps in some syntax in
general
xfq: wanted to say another thing on markup and syntax, 8.3 is
not specific to syntax
… other markup is mentioned also
… markups should be moved into another section?
addison: upper 8.2 talks about identifiers, so could be?
[discussion between markup and syntax...]
AOB?
r12a: small infoshare
… mentioned last week, but I've been working on fonts' list and
sample
… and getting there
… why decided to work on this, for generic callback categories,
what kind of fonts exist in OS is important for generics'
fallbacks
… I think it's florian's ball to look into my article
… this document makes understanding what is required
[28]w3c/i18n-activity#1783
[28] https://github.com/w3c/i18n-activity/issues/1783
<gb> [29]Issue 1783 CSS `text-spacing` property and its
longhands (by w3cbot) [pending] [tracker]
[29] https://github.com/w3c/i18n-activity/issues/1783
xfq: since we have issue above, there is TAG issue on css
property, and as i18n-tracker
… one alternative might be having another label
addison: we should be aware of these
addison: we may need to ask TAG that what HR groups should work
on review requested from TAG issue
r12a: I would say we have s:css-text for specific to document
… alternatively s:design-review or something could work?
r12a: ask xfq for looking into the triage permission of the
w3ctag org on github
xfq: will take an action
ACTION: xfq to check on permissions with w3ctag and follow up
with plh on looking for notifications
<gb> Created [30]action #56
[30] https://github.com/w3c/i18n-actions/issues/56
Summary of action items
1. [31]xfq to check on permissions with w3ctag and follow up
with plh on looking for notifications
Received on Friday, 27 October 2023 02:43:48 UTC