- From: r12a <ishida@w3.org>
- Date: Thu, 11 Aug 2016 20:00:19 +0100
- To: www International <www-international@w3.org>, public-socialweb@w3.org
https://www.w3.org/2016/08/11-i18n-minutes.html
text version follows:
Internationalization Working Group Teleconference
11 Aug 2016
[2]Agenda
[2]
https://lists.w3.org/Archives/Member/member-i18n-core/2016Aug/0002.html
See also: [3]IRC log
[3] http://www.w3.org/2016/08/11-i18n-irc
Attendees
Present
felix, addison, Chris, Webber, Sandro, Steve, Richard,
JcK, Rhiaro, JaSnell
Regrets
DaveClarke
Chair
Addison Phillips
Scribe
aphillips_
Contents
* [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
__________________________________________________________
Agenda
sandro: problem is that relevant editors not present
... trying to ping
Action Items
[11]https://www.w3.org/International/track/actions/open
[11] 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>
[12]http://www.w3.org/International/track/actions/545
[12] 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>
[13]http://www.w3.org/International/track/actions/546
[13] http://www.w3.org/International/track/actions/546
close action-546
<trackbot> Closed action-546.
<scribe> ScribeNick: aphillips_
Radar
[14]http://w3c.github.io/i18n-activity/radar/
[14] http://w3c.github.io/i18n-activity/radar/
richard: svg2, nikos replies with 2 weeks
[15]https://www.w3.org/International/wiki/Project_radar
[15] https://www.w3.org/International/wiki/Project_radar
[16]http://w3c.github.io/i18n-activity/projects/
[16] 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> [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]
[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
2016-08-18].
Finish discussion of direction in ActivityStreams with Social WG
<cwebber2>
[19]https://www.w3.org/International/wiki/Activity_Streams_dire
ction_notes
[19]
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
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]
[20] http://www.w3.org/2016/08/11-i18n-minutes.html#action01
Summary of Resolutions
[End of minutes]
Received on Thursday, 11 August 2016 19:00:30 UTC