Internationalization Working Group Teleconference

Agenda

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

Action Items

https://www.w3.org/International/track/actions/open

action-545?

<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

<trackbot> http://www.w3.org/International/track/actions/545

close action-545

<trackbot> Closed action-545.

actin-546?

action-546?

<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

<trackbot> http://www.w3.org/International/track/actions/546

close action-546

<trackbot> Closed action-546.

<scribe> ScribeNick: aphillips_

Radar

http://w3c.github.io/i18n-activity/radar/

richard: svg2, nikos replies with 2 weeks

https://www.w3.org/International/wiki/Project_radar

http://w3c.github.io/i18n-activity/projects/

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

<r12a> 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 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 2016-08-18].

Finish discussion of direction in ActivityStreams with Social WG

<cwebber2> https://www.w3.org/International/wiki/Activity_Streams_direction_notes

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 flag
... 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 necessary"

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

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

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

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

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

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

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

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

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

<aphillips> james: okay