W3C

Internationalization Working Group Teleconference

05 Dec 2013

Agenda

See also: IRC log

Attendees

Present
Richard, David_Clarke, aphillip, fsasaki, koji, JcK, matial
Regrets
Chair
Addison Phillips
Scribe
Addison Phillips

Contents


Action Items

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> 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

http://www.w3.org/International/wiki/Review_radar

<scribe> ACTION: addison: ping CSS about Shapes issues [recorded in 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

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 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

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 “ﻧﻮﺵ-ﺗﻦ”.

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> 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.

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 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> 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 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 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 http://www.w3.org/2013/12/05-i18n-minutes.html#action03]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013/12/06 16:37:51 $