[minutes] Internationalization telecon 2013-12-05


Text version follows:

Internationalization Working Group Teleconference

05 Dec 2013



    See also: [3]IRC log

       [3] http://www.w3.org/2013/12/05-i18n-irc


           Richard, David_Clarke, aphillip, fsasaki, koji, JcK,

           Addison Phillips

           Addison Phillips


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

    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)



      [14] http://www.w3.org/International/wiki/Review_radar

    <scribe> ACTION: addison: ping CSS about Shapes issues
    [recorded in

    <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



    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

    <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

    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

    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

    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"

    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

    Jck: case mapping does affect the underlying content in some
    ... 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

    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?


      [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

    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

    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

    <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

    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


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

    [End of minutes]

Received on Friday, 6 December 2013 16:40:32 UTC