[minutes] Internationalization telecon 2016-08-11

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[minutes] Internationalization telecon 2016-08-11


text version follows:

Internationalization Working Group Teleconference

11 Aug 2016



    See also: [3]IRC log

       [3] http://www.w3.org/2016/08/11-i18n-irc


           felix, addison, Chris, Webber, Sandro, Steve, Richard,
           JcK, Rhiaro, JaSnell


           Addison Phillips



      * [4]Topics
          1. [5]Agenda
          2. [6]Action Items
          3. [7]Radar
          4. [8]Finish discussion of direction in ActivityStreams
             with Social WG
      * [9]Summary of Action Items
      * [10]Summary of Resolutions


    sandro: problem is that relevant editors not present
    ... trying to ping

Action Items


      [11] https://www.w3.org/International/track/actions/open


    <trackbot> action-545 -- Richard Ishida to Create draft of
    bidi-in-plain-text and start email thread on public-i18n-bidi
    -- due 2016-08-04 -- OPEN


      [12] http://www.w3.org/International/track/actions/545

    close action-545

    <trackbot> Closed action-545.



    <trackbot> action-546 -- Addison Phillips to Update the
    metadata wiki page to discuss language/direction metadata
    problems in e.g. json -- due 2016-08-04 -- OPEN


      [13] http://www.w3.org/International/track/actions/546

    close action-546

    <trackbot> Closed action-546.

    <scribe> ScribeNick: aphillips_



      [14] http://w3c.github.io/i18n-activity/radar/

    richard: svg2, nikos replies with 2 weeks


      [15] https://www.w3.org/International/wiki/Project_radar


      [16] http://w3c.github.io/i18n-activity/projects/

    richard: pushed new copy of specdev
    ... putting in the information was necessary for direction and
    ... trying to keep separation about resources or blocks or etc.
    ... added new explanation
    ... please have a look

    <r12a> [17]http://w3c.github.io/bp-i18n-specdev/

      [17] http://w3c.github.io/bp-i18n-specdev/

    richard: on encoding
    ... a lot of encoding went into html

    <scribe> ACTION: addison: ping Martin regarding progress on
    Unicode in XML update [recorded in

      [18] http://www.w3.org/2016/08/11-i18n-minutes.html#action01]

    <trackbot> Created ACTION-547 - Ping martin regarding progress
    on unicode in xml update [on Addison Phillips - due

Finish discussion of direction in ActivityStreams with Social WG



    chris: read the above document
    ... looks pretty good in general
    ... sections on what to do with multi paragraphs
    ... activity streams, two approaches
    ... 1. name field, not more than sentence
    ... that is the one where we can't hav emarkup
    ... 2. other is multiple para types
    ... question for WG
    ... is how to handle RTL/LTR in html considered solved?

    richard: dunno when you read
    ... been changing
    ... if have direction auto on text
    ... use first strong for each paragraph
    ... alignment of chars depends on paras
    ... if thinking of using first strong, then already there
    ... in first copy, both plain and marked text
    ... addison pointed out that is base direction is what's needed
    ... for text input by user, they have to provide it
    ... inside the text
    ... so, in summary, the multi paragraph thing is not an issue

    addison: (discusses why only outside of the text is needed)

    richard: trying to capture why properties are undesirable
    ... what you're left with is two possible apporaches
    ... first strong, or direction metadata in each string
    ... if rely on first strong, but some situations where
    ... and markup is one
    ... putting RLM at start of string doesn't help, except as a
    ... diff by putting character vs. metadata no different
    ... ideas why prefer former

    chris: seem in general that first strong acceptable

    <sandro> Just insert. That's perfect.

    <cwebber2> someone's going to need to convey this conversation
    to evan / james

    <rhiaro> yeah I think sandro will

    <rhiaro> and it's minuted

    <cwebber2> {"name": "foo", "nameDir": "foo"}

    <cwebber2> {"name": "foo", "nameDir": "rtl"}

    <aphillips> chris: for single way if possble

    <aphillips> ... technically markup optional

    <aphillips> ... but always have to process as-if it has markup

    <aphillips> +1

    <jasnell> I'm very sorry all

    <jasnell> I didn't have the call in my calendar and completely
    forgot about it

    <aphillips> RLM<p> -> <div dir=rtl><p>

    <sandro> jasnell, I think we've got it figured out.

    <jasnell> if it would still be useful for me to join, then yes

    <cwebber2> jasnell: it would be useful for us to summarize
    discussion to you

    <cwebber2> both for your sake and ours ;)

    <jasnell> ok, dialing in

    <sandro> Summary: AS2 consumers will use 'first-strong' for
    determining base direction, and AS2 producers MUST anticipate
    that, and add a leading RLM or LRM or whatever if they know the
    base direction.

    <aphillips> richard: modify slightly to say "add RLM/LRM where

    <sandro> sandro: rather not have producers do analysys,

    <aphillips> chris: don't want to analyze the sstring

    <aphillips> +1

    <sandro> aphillips: but don't add a marker if there's one there

    <aphillips> james: for document or by field?

    <aphillips> richard: by field

    <aphillips> ... spec would need to require that base direction
    is indicator

    <aphillips> chris: is there a spec that defines first-strong?

    <sandro> aphillips: html 'auto' or bidi spec

    <aphillips> jasnell: already link to bidi spec

    <aphillips> addison: look for the character if assembling

    <aphillips> ... otherwise bidi handles it

    <sandro> aphillips: When you're putting a markup string, eg
    summary, into HTML, then you look for the leading marker and
    set that as dir on the enclosing HTML

    <aphillips> RLMfoo bar -> <bdi dir=rtl>foo bar

    <aphillips> name: "RLMfoo bar"

    <jasnell> name: "..RLMfoo bar"

    <aphillips> richard: when you consume things, when you create
    strings in AS

    <aphillips> ... don't expec tto change markup in any way

    <aphillips> ... might put an RLM before it

    <aphillips> ... ensure that first strong character in the

    <aphillips> ... in a non-markup string represents the base

    <aphillips> richard: if dealing with markup, the markup will be
    strongly LTR (which is wrong)

    <aphillips> ... need to look past

    <aphillips> ... the markup

    <aphillips> richard: set this up so you can detect

    <aphillips> got a name property

    <aphillips> ... look at the property, the first character is an

    <aphillips> ... know the direciton, wrap this thing in a <span

    <aphillips> next scenario

    <aphillips> ... have a name with weakly direcitonal characters

    <aphillips> ... then see a strongly rtl character

    <aphillips> ... put in div with dir rtl

    <aphillips> next

    <aphillips> ... strong ltr to start

    <aphillips> richard: one other possible, only numbers

    <aphillips> ... have to have an assumptiont hat ltr is default

    <aphillips> as scanning, if not start with rlm, then assume ltr

    <aphillips> addison: can say auto

    <aphillips> summary fields

    <aphillips> ... hopefully starts with markup that says rtl/ltr

    <aphillips> ... if punctuation/numbers and then markup

    <aphillips> unless first strong is rtl

    <aphillips> addison: directly consume the string

    <aphillips> richard: RLM is just a marker

    <aphillips> ... chris's idea of meta on every strong more

    <aphillips> ... produciton of json is what's important here

    <cwebber2> I advocated metadata as a separate supplement to one
    string ;)

    <cwebber2> (and I no longer think it's a good thing for as2

    <aphillips> james: for producers and consumers: MUST or...

    <cwebber2> btw I'm afraid even if we say MUST

    <cwebber2> it'll become a SHOULD

    <cwebber2> in practice

    <cwebber2> gotta go, all

    <aphillips> thanks chris

    <cwebber2> sounds like things mostly resolved though :)

    <r12a> using @language in the context seems to be the most
    straightforward way to provide language information in a
    unilingual situation

    <r12a> where properties are localised into multiple languages,
    then ...Map should be used for all natural language text

    <r12a> where one property is in a different language than
    others, use @language for the default language, and use ...Map
    for properties containing values in other languages.

    <aphillips> james: will spend afternoon writing

    <aphillips> ... throw comments on the pull request

    <aphillips> richard: put something in the open issue so we can

    <aphillips> james: okay

Summary of Action Items

    [NEW] ACTION: addison: ping Martin regarding progress on
    Unicode in XML update [recorded in

      [20] http://www.w3.org/2016/08/11-i18n-minutes.html#action01

Summary of Resolutions

    [End of minutes]