[minutes] Internationalization telecon 2014-07-24


Text version follows:

Internationalization Working Group Teleconference

24 Jul 2014



    See also: [3]IRC log

       [3] http://www.w3.org/2014/07/24-i18n-irc


           Addison, Richard, Fantasai, Mati, David

           JcK, Felix

           Addison Phillips

           Addison Phillips, Elika


      * [4]Topics
          1. [5]Agenda
          2. [6]Action Items
          3. [7]Info Share
          4. [8]RADAR
          5. [9]Tracker tweaks
          6. [10]Locales in HTML
          7. [11]TimeZones in HTML
          8. [12]Encoding LC
      * [13]Summary of Action Items


Action Items


      [14] http://www.w3.org/International/track/actions/open

    <fantasai> aphillip: Working through list of satisfied items in
    CSS3 Text

    <fantasai> aphillip: Not quite done


    <trackbot> action-315 -- Addison Phillips to Close satisifed
    items in css-text -- due 2014-07-03 -- OPEN


      [15] http://www.w3.org/International/track/actions/315


    <trackbot> action-320 -- John Klensin to Send link to "hamza
    above" id to public list -- due 2014-07-24 -- OPEN


      [16] http://www.w3.org/International/track/actions/320

    close action-320

    <trackbot> Closed action-320.

    close action-321

    <trackbot> Closed action-321.

    close action-322

    <trackbot> Closed action-322.


    <trackbot> action-319 -- Koji Ishii to Report back on korean
    justification when response received -- due 2014-07-17 -- OPEN


      [17] http://www.w3.org/International/track/actions/319

Info Share

    fantasai: publish new draft of css-ruby
    ... anon box generation
    ... whitespace handling now defined
    ... bidi now defined
    ... sent mail about it
    ... on html side, koji filed items about too aggressive auto


      [18] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26424


      [19] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26426



      [20] https://www.w3.org/International/wiki/Review_radar

Tracker tweaks

    <r12a> [21]http://www.w3.org/International/track/

      [21] http://www.w3.org/International/track/

    <fantasai> r12a: We used to have ad-hoc and .prev and .monitor
    and then the real one, and we rolled all those together

    <fantasai> r12a: There's a small problem, which we actually
    foresaw at the time

    <fantasai> r12a: Now, you can't necessarily tell, at a glance,
    which has already been sent to the WG and which is waiting

    <r12a> [22]http://www.w3.org/International/track/products/46

      [22] http://www.w3.org/International/track/products/46

    <fantasai> r12a: which is actually being tracked, vs. which is
    a real comment sent to the WG

    <fantasai> r12a: What I've started doing is, wher eyou can see
    at the end of the title I put a circled t, means we're just
    tracking this

    <fantasai> r12a: circled p is pending expedition to the WG

    <fantasai> r12a: my proposal is that in the instructions for
    how to raise an issue that we tell people to put these little
    things on at the ppropriate time, or remove them when you're
    notifying the WG


      [23] http://www.w3.org/International/reviews/review-instructions

    <fantasai> aphillip: Since we want to invite the unverse at
    large to make comments, shouldn't those be unmarked, and you
    and I add notations for the other states?

    <fantasai> r12a: Well, I hope they follow instructions. It
    would save us a lot of grief, and if they follow those
    instructions, would be simple enough

    <fantasai> r12a: I did consider that, but thought it would be
    easier in the long run if our comments to another WG didn't
    have these things

    <fantasai> aphillip: Didn't want to send Unicode chars to other
    groups? :)

    <fantasai> r12a: Yeah. Also then people might forget them, it
    gets confusing, etc.

    <fantasai> fantasai: You could make them non-Unicode. Put in

    <fantasai> r12a: Considered that, but this is cooler.

    <fantasai> aphillip: Any other opinions?

    <fantasai> [not really]

    <dclarke> Seems fine, but might be bettter as prefix

    <scribe> ACTION: richard: modify instrucitons for reviews to
    include the new markings [recorded in

    <trackbot> Created ACTION-323 - Modify instrucitons for reviews
    to include the new markings [on Richard Ishida - due

    <matial> prefices are easier to spot

    <fantasai> r12a: thought about that too, but concluded that
    easier to manage at the end - however that's why I went for
    circles, they are easy enough to spot

Locales in HTML


      [25] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17859

    <fantasai> aphillip: Basically, this is about Ian proposes to
    add a new piece of markup for indicating the locale of elements
    in forms

    <fantasai> aphillip: ought to be aligned with JS, BCP47

    <fantasai> aphillip: We already have an attribute that does

    <fantasai> aphillip: so some ocntention between using lang vs
    not using lang


      [26] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22679

    <fantasai> r12a: seems to be some of ppl on the bug are talking
    about situations an dmixing them

    <fantasai> r12a: where you have data being inserted into a page

    <fantasai> r12a: fairly obvious that if you do that, and then
    insert date sample, which is dynamic thing, that you ought to
    format it according to language of the text into which you're
    inserting it

    <fantasai> r12a: that's a different scenario than having an
    input field in the text, and you are gathering info from the

    <fantasai> r12a: if you're gathering info with an input field,
    seems more plausible that you'll want to consider who is the
    user is than the language of the text

    <fantasai> r12a: not sure if, if you think further, perhaps you
    want to use the format of the text

    <fantasai> r12a: bigger problem is, if you're asking ppl to
    type in a numeric date, causing yourself a problem in any case

    <fantasai> r12a: argument is that currently system settings
    used to identify the locale

    <fantasai> r12a: we're asking for the lang attribute. This will
    cause inconsistencies

    <fantasai> aphillip: Most browsers are like Mozilla. Get a text
    box. Can type anything into it. type=date is just a suggestion

    <fantasai> aphillip: But Chrome has implemented fancy types

    <fantasai> aphillip: Because HTML doesn't define anything, the
    page author has no control over how a date is displayed

    <fantasai> aphillip: When field is empty, Chrome shows MM/DD/YY
    or whatever

    <fantasai> aphillip: but if you put a value in the field, all
    you see is the value

    <fantasai> aphillip: the value is transposed into the correct


      [27] http://www.inter-locale.com/test/DateDemo.html

    <fantasai> aphillip: There are 2 entry fields, enter US date or
    UK date

    <fantasai> aphillip: Tagged with different lang values. But
    show same ordering for me

    <dclarke> mine says 01/02/2014

    <dclarke> on chrome

    <fantasai> fantasai: These are UI controls. Should be in the UI
    language, lfollow OS convention

    <fantasai> r12a: What if you're travelling? can't figure out
    what the strange ideographic characters are

    <fantasai> aphillip: no way to have german calendar on a german

    <fantasai> aphillip: People work aorund this by creating
    complicated javascript controls

    <fantasai> r12a: problem is more, how does the browser know
    what you mean if you are using numeric input?

    <fantasai> r12a: if you type in 01/02/14

    <fantasai> r12a: browser has to know what you mean

    <fantasai> r12a: if you look at the output , the stored value,
    it's stored in ISO format

    <fantasai> r12a: No matter what the settings are, en-US or
    en-GB, user could type something stupid

    <fantasai> r12a: so a pull-down date widget is the best way to
    do this

    <fantasai> r12a: or something that splits out day/month/year

    <fantasai> r12a: like for credit cards

    <fantasai> r12a: shouldn't be asking people to write numeric

    <fantasai> aphillip: Chrome is constraining these, different
    from historical way

    <fantasai> fantasai: That's the whole point of the new types.
    Browsers that don't do this havent' got around to implementing
    it yet

    <fantasai> r12a: the main point is not how you enter the date,
    but rather how the browser interprets that, you don't know how
    the browser is interpreting it

    <fantasai> fantasai: That browser should drop down the widget
    while you're typing it in

    <fantasai> fantasai: so you can see how it's interpreting the

    <fantasai> aphillip: [...]

    <fantasai> aphillip: can't see the prompt once you fill it in

    <fantasai> [could use non-numeric dates]

    <fantasai> aphillip: Hear that browser should match the user's

    <fantasai> aphillip: but sometimes you as an author want to
    control the complete experience

    <dclarke> I agree with Fantasai,

    <fantasai> fantasai: If you have multiple pages, some written
    in US and some in UK, they'll have inconsitent interfaces. As a
    user this is not helpful. Won't know what's going on.

    <fantasai> fantasai: Should match my locale, my settings. That
    way I always know what's going on.

    <fantasai> fantasai: If you have linguistic info, maybe adapt
    to the page's language

    <fantasai> fantasai: but numeric stuff should match the locale.
    If I like 24h clocks, I should get them on all my time widgets,
    not get am/pm because I happen to be booking in a different

    <fantasai> aphillip: Sounds like we have different opinions

    <r12a> r12a: my inclination is to think that a user control is
    more related to the user than to the text content language

    <r12a> ... however information later inserted into the page
    should be in the format related to the language

    <fantasai> aphillip: If we don't give any way to control these
    things, then the only way to get a specific presentation is to
    not use the built-in controls and write it myself

    <fantasai> aphillip: Should provide a way to control for
    content authors who care about it

    <fantasai> r12a: I'm not 100% convinced either way

    <fantasai> r12a: why is this the same as the JS stuff?

    <fantasai> r12a: for JS, you want to take info taken from user,
    and then insert into document. Want it to look like the rest of
    the page content

    <fantasai> r12a: but in terms of gathering the data from the
    user, don't see that strong convention

    <fantasai> r12a: If guy is reading Tibetan, probably speaks and
    reads Tibetan, and is happy because system is all in Tibetan

    <fantasai> r12a: Case where you run into problems is the
    Internet café, where you are not necessarily Tibetan

    <fantasai> r12a: but in that case, you know what's going on,
    you're carefull and less likely to make silly mistakes

    <fantasai> r12a: You shouldn't be doing numeric data in the
    first place. Regardless of whether we match system or page, can
    mess up without noticing

    <fantasai> fantasai: I think if the month were not numeric,
    e.g. 13 Oct 2014, wouldn't have this problem

    <dclarke> or rendering it as a 3 field split

    <fantasai> that's less likely to look nice. People wnat things
    to look nice...

    <dclarke> then the month field only goes up to 12

    <dclarke> etc

    <fantasai> aphillip: Not getting anywhere here

TimeZones in HTML


      [28] https://www.w3.org/International/wiki/HTML5TimeZone

    <fantasai> aphillip: Put two proposals.

    <fantasai> aphillip: Think second is dead on arrival

    <fantasai> aphillip: are we ready to move forward with this and
    make a proposal?

    <fantasai> r12a: Think this needs more time for review

    <scribe> ACTION: addison: give wg action to read the time zone
    proposal for action next week [recorded in

    <trackbot> Created ACTION-324 - Give wg action to read the time
    zone proposal for action next week [on Addison Phillips - due

Encoding LC

    <fantasai> fantasai: Example is a date without a time. Why is
    there a timezone? Binding it to midnight means that when it
    shows up in my calendar, it shows up as the previous date
    (because I'm in SF)

    <fantasai> aphillip: go read the note about time info

    <fantasai> aphillip: issue here is anyway that we have timezone
    offsets or nothing, and we need real timezones

    <fantasai> [discussion of floating vs non-floating times]

    <fantasai> HTML defines time without timezone as floating time,
    but if you pull it into JS, it gets tied to midnight UTC

    <fantasai> aphillip: ^

    <fantasai> aphillip: So this is a real problem


      [30] http://www.w3.org/International/track/products/25

    <fantasai> aphillip: Work on open bugs, or look at received


    <trackbot> issue-374 -- Encoding false statement -- open

    <trackbot> [31]http://www.w3.org/International/track/issues/374

      [31] http://www.w3.org/International/track/issues/374



    <fantasai> aphillip: spec states that it renders the IANA
    registry obsolete

    <fantasai> aphillip: Anne accepted some slightly modified text,
    but probably won't make a real difference

    <fantasai> r12a: perhaps should make it clearer what we're
    referring to


      [33] http://encoding.spec.whatwg.org/


      [34] http://encoding.spec.whatwg.org/#preface

    Historically encodings and their specifications (if any) were
    kept track of by the IANA Character Sets registry. This
    specification renders that registry obsolete.

    <fantasai> r12a: 2nd sentence is what is causing the problem

    <fantasai> r12a: to my mind, the way to solve this is to scope
    that statement a bit better

    <fantasai> r12a: Could say that ths spec renders that registry
    obsolete for the Open Web Platform

    <fantasai> r12a: still worrying, cuz don't know what OWP the
    boundaries of OWP are exactly, and I suspect that some people
    working on the OWP may still need to refer to the IANA spec for
    a whle at least

    <fantasai> r12a: Another possibility, obsoletes that registry
    for all implementations that use this specification.

    <fantasai> aphillip: I think obsolete or replaces isn't really
    even necessary

    <fantasai> aphillip: you don't have to look over there if
    you're looking here

    <fantasai> r12a: Can't use word "obsolete", because you can't
    obsolete a spec you don't own

    <fantasai> r12a: and some ppl will use IANA spec, so can't make
    a universal statement

    <fantasai> r12a: so agree not to use obsolete

    <fantasai> fantasai: Replaces seems fine

    <fantasai> aphillip: replaces for what?

    <fantasai> fantasai: for impl using this spec (as r12a
    suggested) is fine

    <fantasai> aphillip: Then recommend that this spec be used for
    anyone using the OWP

    <fantasai> aphillip: If writing a W3C spec, should reference
    this spec instead of IANA

    <fantasai> r12a: should put that in charmod

    <fantasai> aphillip: yes

    <fantasai> aphillip: Need to update Charmod for various reasons

    <fantasai> fantasai: Don't think it's a problem for a spec to
    say what it thinks it ought to be used for. Not that shouldn't
    update charmod as well

    <fantasai> r12a: That is a field of land mines

    <fantasai> r12a: XML ppl will be very unhappy

    <fantasai> r12a: so just a whole lot simpler to just be

    <fantasai> aphillip: If you refer to this spec, then this
    becomes the definition of encodings and the limit of what
    encodings are acceptable

    <fantasai> aphillip: so we're in agreement with this issue

    <fantasai> aphillip: so that suggests filing a bug against

    <fantasai> aphillip: Do we want to write proposed replacement

    <fantasai> r12a: useful to go to anne with a suggestion, but
    also useful to talk with anne about this

    <fantasai> [discussion of calendaring]

    <fantasai> [and bug-filing logistics]

    <fantasai> aphillip: I think all of these are going to end up
    with bugs

    <scribe> ACTION: addison: propose text for the 'false
    statement' issue [recorded in

    <trackbot> Created ACTION-325 - Propose text for the 'false
    statement' issue [on Addison Phillips - due 2014-07-31].


    <trackbot> issue-355 -- Supporting files referenced rather than
    copied -- open

    <trackbot> [36]http://www.w3.org/International/track/issues/355

      [36] http://www.w3.org/International/track/issues/355



    <trackbot> issue-369 -- IANA transition -- open

    <trackbot> [37]http://www.w3.org/International/track/issues/369

      [37] http://www.w3.org/International/track/issues/369

    not actionable?

    close issue-369

    <trackbot> Closed issue-369.


    <trackbot> issue-371 -- Choice of encoding details -- open

    <trackbot> [38]http://www.w3.org/International/track/issues/371

      [38] http://www.w3.org/International/track/issues/371

    richard: anne asked martin for test results
    ... should encourage him to provide to anne


    <trackbot> issue-372 -- Arithmetic Right Shift -- open

    <trackbot> [39]http://www.w3.org/International/track/issues/372

      [39] http://www.w3.org/International/track/issues/372

    richard: looks like anne will do something about it

    file a bug against


    <trackbot> issue-373 -- Changes of deployment -- open

    <trackbot> [40]http://www.w3.org/International/track/issues/373

      [40] http://www.w3.org/International/track/issues/373

    richard: "not accept" and close since based on browser
    ... ?

    addison: nothing actionable in this item?
    ... accept but not file a bug? response is "noted"

    <matial> Bye

    <scribe> ScribeNick: fantasai

    <aphillip> Scribe: Elika

Summary of Action Items

    [NEW] ACTION: addison: give wg action to read the time zone
    proposal for action next week [recorded in
    [NEW] ACTION: addison: propose text for the 'false statement'
    issue [recorded in
    [NEW] ACTION: richard: modify instrucitons for reviews to
    include the new markings [recorded in

    [End of minutes]

Received on Thursday, 24 July 2014 16:38:21 UTC