Meeting minutes
Action Items
xfq: there was some discussion on i18n-CSS joint call
<addison> #54
<gb> 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
addison: on ruby text-to-speech, what was discussion there and comment from Murata-san?
<xfq> https://
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> 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
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
<gb> 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]
https://
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
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
<gb> Issue 1786 [VC-JSON-SCHEMA] overwritting internationalization consideration section? (by himorin) [pending] [s:vc-json-schema]
<addison> https://
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
https://
atsushi: JSON Schema doesn't have anything about language and direction metadata
<gb> Issue 108 JSON schema (by dontcallmedom) [Data]
addison: file that issue and I'll move it over to Awaiting comment resolution
Working with String Data Values (draft)
addison: this is from my action item
<addison> https://
addison: see hashed link above
… early days I wanted to see feedbacks on these sections
addison: whole new section
<addison> w3c/
<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
<gb> Issue 1783 CSS `text-spacing` property and its longhands (by w3cbot) [pending] [tracker]
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 action #56