- From: Richard Ishida <ishida@w3.org>
- Date: Fri, 06 Dec 2013 16:40:02 +0000
- To: www International <www-international@w3.org>
http://www.w3.org/2013/12/05-i18n-minutes.html
Text version follows:
Internationalization Working Group Teleconference
05 Dec 2013
[2]Agenda
[2]
https://lists.w3.org/Archives/Member/member-i18n-core/2013Dec/0003.html
See also: [3]IRC log
[3] http://www.w3.org/2013/12/05-i18n-irc
Attendees
Present
Richard, David_Clarke, aphillip, fsasaki, koji, JcK,
matial
Regrets
Chair
Addison Phillips
Scribe
Addison Phillips
Contents
* [4]Topics
1. [5]Agenda
2. [6]Action Items
3. [7]Info Share
4. [8]RADAR
5. [9]CSS Text
6. [10]AOB?
* [11]Summary of Action Items
__________________________________________________________
Action Items
[12]http://www.w3.org/International/track/actions/open
[12] http://www.w3.org/International/track/actions/open
action-252: done but will ping again as got no answer
<trackbot> Notes added to action-252 Ping dita folks about
contacting html5 about ruby progress.
close action-264
<trackbot> Closed action-264.
Info Share
richard: multilingual web...
felix: (mumbles something indistinct)
... hoping that there will be another MLWeb Workshop
<fsasaki> [13]http://www.lider-project.eu/
[13] http://www.lider-project.eu/
felix: will try to continue workshops
... and also promote Linked Open Data
... and a new WG connected to it
richard: also bringing multilingualweb.eu inside W3C
... will notice that there is an MLWeb logo on /International
home page
... (activity home page)
RADAR
[14]http://www.w3.org/International/wiki/Review_radar
[14] http://www.w3.org/International/wiki/Review_radar
<scribe> ACTION: addison: ping CSS about Shapes issues
[recorded in
[15]http://www.w3.org/2013/12/05-i18n-minutes.html#action01]
<trackbot> Created ACTION-272 - Ping css about shapes issues
[on Addison Phillips - due 2013-12-12].
JcK: URNbis not quite ready
... currently passing bottlenecks around
... could happen quickly if things work out
addison: need shepherds for HRTime2 and Shapes
... will shepherd shapes
CSS Text
[16]https://lists.w3.org/Archives/Member/member-i18n-core/2013D
ec/0001.html
[16]
https://lists.w3.org/Archives/Member/member-i18n-core/2013Dec/0001.html
JcK: about 1/3 through
... particularly concerned about character/code
point/grapheme/etc. terminology
... also about case distinctions
addison: we are quite late with comments, would like to start
feeding them comments back
richard: also reviewing but still in paper mode
... raise tracker comments and then review via email?
<scribe> ACTION: addison: update CSS on our ETA for CSS Text
comments [recorded in
[17]http://www.w3.org/2013/12/05-i18n-minutes.html#action02]
<trackbot> Created ACTION-273 - Update css on our eta for css
text comments [on Addison Phillips - due 2013-12-12].
quote: At risk features that concern me: text-justify and the
full-width value of text-transform.
Text-align "start end" keyword (*not* to be confused with
"start" and "end" keywords) is at risk, but does not represent
a break with bidi support I think.
koji: at risk features need implementers and that's the reason
for being at risk
1. Section 1.3: The description of "grapheme cluster" feels
abbreviated and terse. Of particular concern to me is this
sentence: -- The UA may further tailor the definition as
required by typographical tradition. -- I think this could be
clearer, perhaps by saying: -- The UA may tailor grapheme
cluster boundaries as required by typographical tradition or
based on additional linguistic requirements. --
JcK: not completely clear, even with this edit?
... "completely optional if you feel you need to ignore it"
<fsasaki> [apologies, have to leave now, talk to you next week
or before]
richard: wondering if what is meant here is: use grapheme
clusters where defined
... but certain languages where need to extend
addison: UTR talks about that
JcK: strange example of classic Mayan
[18]http://www.w3.org/TR/css-text-3/#terms
[18] http://www.w3.org/TR/css-text-3/#terms
richard: needs the word "further" or "there are units bigger
than grapheme clusters"
addison: that makes sense
"The UA may extend grapheme cluster boundaries as required by
typographical tradition (see [example needed]).
richard: ".... based on language requirements"?
addison: problem is there is no way to markup "typographic
tradition", just relies on language markup
quote: Within this specification, the ambiguous term character
is used as a friendlier synonym for grapheme cluster. See
Characters and Properties for how to determine the Unicode
properties of a character.
richard: let's ask why redefinition
... tend to think it's a bad idea
koji: not clear where preference came from, good to get
feedback from I18N
JcK; already ranted a bit: pretty certain is a Bad Idea as very
confusing
scribe: if "every time we say 'character' read as 'grapheme
cluster'" would be less unhappy, but not the case
koji: concern is not about use of term, but about
inconsistency?
richard: probably both
addison: understand that we are more "in tune" with Unicode
terminology than most spec users but in this case the need is
strong for both terms as distinct
richard: add specific cases to comment
3. Section 2.1: There is no corresponding "half-width"
transformation.
koji: intentional
... problem is with katakana
... but then name not consistent if we make an exception
JcK: unfortunately same problem to the case transforms
probably dropping this one
4. Section 2.1: Example 3 discusses Turkish upper and lower
case mappings, which illustrates that the 'capitalize',
'uppercase', and 'lowercase'. More specificity about the
language tailoring is wanted here. Also a discussion of case
mapping
Jck: case mapping does affect the underlying content in some
languages
... just a bit muddled here
... not meaningful without language identification
... why no 'titlecase' instad of 'capitalize'?
... why UA dependent?
addison: UAs implement casing differently
koji: what do you suggest?
as defined in Default Case Algorithm section
--
If (and only if) the content language of the element is,
according to the rules of the document language, known, then
any appropriate language-specific rules must be applied as
well. These minimally include, but are not limited to, the
language-specific rules in Unicode's SpecialCasing.txt.
--
richard: add proposal to have informative link to CLDR if
that's what you think should happen
7. Section 6.1: The Arabic hyphenation shaping example isn't
clear. The segments should be shown separately?
For example, if the word “نوشتنن” were hyphenated, it would
appear as “ﻧﻮﺷ-ﺘﻦ” not as “ﻧﻮﺵ-ﺗﻦ”.
[19]http://www.w3.org/TR/css-text-3/#hyphens-property
[19] http://www.w3.org/TR/css-text-3/#hyphens-property
9. Section 7.3: The tasmeem example of "cursively justified"
Arabic text may not be clear to outside observers unfamiliar
with kashida. In addition, no mention is made of kashida or the
kashida/tatweel character. This is probably called for here.
koji: john daggett again having kashida unless clearly defined
richard: does he mean "defineding the rules for adding baseline
extension characters" or just "explaining what it is"?
koji: a developer who doesn't know arabic can implement
richard: there are other cases where the spec is hand-wavy like
this, would need a spec on its own to well-define kashida rules
koji: msft had low and high kashida or something like that
richard: there was or was not a kashida property value?
<koji>
[20]http://www.w3.org/TR/2012/WD-css3-text-20120814/#text-justi
fy
[20] http://www.w3.org/TR/2012/WD-css3-text-20120814/#text-justify
koji: yes, that's correct
‘kashida’ Justification primarily stretches cursive scripts
through the use of kashida or other calligraphic elongation.
This value is optional for conformance to CSS3 Text. (UAs that
do not support cursive elongation must treat the value as
invalid.)
addison: need a complete definition of kashida?
... and "ALREQ" is needed :-(
richard: next point you made is important too: is kashida off
when you say 'inter-word'? how about 'distribute' (sounds like
you turn it on, actually)?
addison: expect inter-word to turn off
... but not sure about distribute
<matial> Yes, I have to leave.
11. Section 8.2: The section on "tracking" ('letter-spacing')
should probably reiterate that tracking does not break
cursive/ligating scripts like Arabic. Mention of the "bar" in
scripts such as Devanagari is also probably warranted.
[21]http://www.w3.org/TR/css-text-3/#letter-spacing-property
[21] http://www.w3.org/TR/css-text-3/#letter-spacing-property
richard: kashida also used for emphasis and not evenly between
all letters
... also might be appropriate in 'justify' section
addison: don't know about bar in Devanagari
<scribe> ACTION: richard: ask Indic task force about handling
of tracking in CSSText, pariticulary whether the bar "breaks"
in scripts that use one [recorded in
[22]http://www.w3.org/2013/12/05-i18n-minutes.html#action03]
<trackbot> Created ACTION-274 - Ask indic task force about
handling of tracking in csstext, pariticulary whether the bar
"breaks" in scripts that use one [on Richard Ishida - due
2013-12-12].
richard: have a whole ton of tests for this document (line
breaking, hyph, etc.)
... so when you get to CR, don't reinvent it, okay?
<r12a> [23]http://www.w3.org/International/tests/#css3-text
[23] http://www.w3.org/International/tests/#css3-text
AOB?
<r12a> also white-space tests below and some more hyphenation
<scribe> chair: HOMEWORK: CSS3 Text and Syntax
Summary of Action Items
[NEW] ACTION: addison: ping CSS about Shapes issues [recorded
in [24]http://www.w3.org/2013/12/05-i18n-minutes.html#action01]
[NEW] ACTION: addison: update CSS on our ETA for CSS Text
comments [recorded in
[25]http://www.w3.org/2013/12/05-i18n-minutes.html#action02]
[NEW] ACTION: richard: ask Indic task force about handling of
tracking in CSSText, pariticulary whether the bar "breaks" in
scripts that use one [recorded in
[26]http://www.w3.org/2013/12/05-i18n-minutes.html#action03]
[End of minutes]
Received on Friday, 6 December 2013 16:40:32 UTC