TPAC 2016: Internationalization WG

22 Sep 2016


See also: IRC log


Addison, Richard, Felix, Frencesco, Chunming, Myles, Francesco, Angel, felix, bobby, Najib, Rebeca, Andreas, fantasai
Addison Phillips
Addison Phillips, fsasaki, addison


<myles> https://www.w3.org/TR/encoding/ ?

<r12a> myles https://github.com/whatwg/encoding/issues/62

felix: discussions with schema.org

Upcoming Agenda

<r12a> https://www.w3.org/International/wiki/TPAC2016_Agenda

<fsasaki> scribe: fsasaki

Myles: here to observe what is going on

Chinese Layout Task Force

<r12a> https://www.w3.org/International/wiki/TPAC2016_Agenda

<r12a> sure

<r12a> https://github.com/w3c/clreq

richard introduces layout requirements documents

<addison> Chinese, Mongolian, Tibetan, Uighur

richard: goal to review state of various languages and potential next steps
... we have not moved forward since last TPAC
... we published FPWD for chinese document. We were close to publish simplified chinese doc, but never got it reviewed for accuracy
... nothing has happened for a year. what do you think, what will / should happen next?

bobby: on github we have issues, not so important. Apologies for the delay of the year, this time I will get the issues cleared.
... we want extension to clreq, some editors may have opinions but not expressed on github
... some parts are not done, we want to extend the sections in november
... we should have a gap document for clreq

richard: does it make sense to work on gap document at the same time or should we finish clreq first?

addison: with jlreq document experience, I think having a gap document helps
... helpful to produce a complete as possible set of clreq requirements, we can use that to produce gap document(s)

richard: bobby has some specific issues they like to have addressed soon

addison: clreq describes things that you like to get done?

bobby: yes

addison: don't think we need a formal doc to do that

discussion on how to have the list of gap filling in clreq

richard: a gap document would be helpful, just wondering if it would take a lot longer

addison: do you have one example?

richard: font fallback

addison: if we could produce a list of specific requests we could produce issues

richard: the gap document would say: this is what currently happens. could be in the issue but can be a lot of text
... e.g. "safari does this ..."

addison: can be a living doc as the discussion goes on
... worried that if we build one gap doc it will take time. we are not progressing clreq
... on font fallback: that discussion will be fairly mature in the beginning
... other items will need more documentation work

myles: CSS group is very interested in supporting chinese text
... if we in CSS get things wrong, some items may be more important than others
... would be good to know what to focus on

richard: for that it would be good to structure the items

myles: a mail would be good for me to start with

bobby: I should list the issues I wrote last year / this year
... e.g. text area topic - kojii is working on that already

discussion on how to structure the discussion

myles: happy to help, to put together what CSS needs = turning i18n group outcomes into input to CSS WG

Chunming: we have layout document for many languages
... programmers who want to follow clreq need examples. general content creator wants to know how to write the CSS style rules
... this is different than gap analysis
... another layer of work - collection of best practices that could be met by current web tech
... not sure if this has been done by other layout docs, e.g. latin

addison: jlreq wrote a nearly perfect model on how japanese print publication works
... you then could write an authoring guide for CSS
... in some cases there are gaps
... if we do the same with clreq, it would say: here is a description how the layout works
... then e.g. you say: justification works like this: ...
... in other areas, e.g. ruby, we had a long discussion on how to do this and then how to close gaps

<r12a> https://www.w3.org/TR/ruby-use-cases/

addison: that is normal process: people say "I can't do ...". Then we say "describe what you want to do". Then we may have more keywords in CSS or s.t. else

myles: a web author wants to know: "what do I need to do to make ruby happen?"
... in some cases there is a simple answer, in others it is more complex, e.g. a list of properties
... I have not seen such docs by W3C, but in other places (blog posts ...) by industry

richard: for ruby, we created a WG note that showed all that stuff, on an adhoc basis
... we just need to keep track of things

addison: not loose track of being able to finish work

chunming: for clreq we will continue maintenance
... not sure if we want to publish a snapshot of clreq every year?

richard: we did not publish since simplified chinese had not been reviewed
... I propose a different way: we have echidna , so as soon as there is a github commit the TR version can also be updated, it's so easy it's almost automatic
... I recently ported jlreq into respec
... for jlreq I decided to have two documents, you can still have parallel comparison
... why don't we split clreq into three docs: traditional chinese, simplified, english
... at the moment we cannot publish anything because different progress

angel: how do you synchronize?

richard: manually

<fsasaki_> chunming: all issues may be discussed in chinese

<fsasaki_> ... I'd suggest to have both in same doc, since english doc will be a bit later.

<fsasaki_> angel: simplified chinese editor is not so familiar with github, so my team did significant efforts to back her up

<fsasaki_> addison: can we mark what is out of sync?

<fsasaki_> richard: with CSS classes

<fsasaki_> addison: with echidna we can have publish a draft as push

<fsasaki_> richard: with separate documents you have to do more review

<fsasaki_> ... we should agree that we publish one doc with three languages and make clear that they don't always say the same thing

<fsasaki_> ... or that we publish three docs

chunming: currently we only have 30+ issue open, not big issues
... we just need to go through open issues and see what we fix before we publish
... I see two ways to publish: 1) english doc, then two separate chinese docs 2) have one page with three languages referenced
... for our audience it is preferred to have one doc
... for publishing process, currently we need to have editors keep consistency manually
... editors need to have some effort to assure consistency
... I would prefer to publish one doc
... one doc would be more useful to the audience to follow discussion

myles: who is audience?

chunming: digital publishing / web site content providers in china
... ebook providers on mobile phones
... browser providers, like myles

richard: CSS and similar WGs

chunming: would be good to have a best practices doc on how to follow requirement. propose to keep this in one doc so that this audience has a clear understanding of requirements

richard: we have gone over a year without update, you seem to agree to publish rather soon?

chunming: yes

angel: I see concerns from chunming. if we spit into three, we may have problems with patent policy
... see jlreq: japanese national standards go first
... if people look for original language doc and try to make a national standard, they have an issue
... we try to avoid the possible harmonization problem for the future

richard: the patent policy does not apply, since the docs are not on the rec track

angel: yes, but there are restrictions
... only english is authoritive, the other versions should go through translation process which is very complex
... in jlreq case, there was national standard

JIS 4051

angel: Chinese Chinese layout people who finally realize the value of such a document and decide to make a version of their naitonal standard out of it may be hesitant if English doc is authoritive

addison: we want to document as good as possible how chinese works so that the technology works
... point of this is to be descriptive, not normative, so that we can build other standards out of that

richard: we have resolved to keep the three languages together

angel: yes

richard: will set up clreq to publish with echidna in TR space
... will take an action to prepare that
... tibetan has been ready for publishing for a year, want to discuss that

chunming: we set up the task force and talked about how we organise this. china government does not want to split this language, china is multi ethnic nation
... if we want to do this in china, and get more input from experts, then we keep document creation in the layout task force
... we exchanged the idea with government agency, so I don't want this to be changed
... another example: korea is used in china in some provinces
... that is ok, there is klreq already
... for mongolian, AFAIK, chinese scholars have good links

richard: there is no mongolian task force, just a mailing list
... there is two problems: first, tibetan is not just a chinese language
... if I talk to people outside china, people have resistance to participate because they think this is a Chinese group, focused on Chinese topics
... as W3C we have to take a global point of view. Tibetan is spoken in china but also in other countries
... the other issue is: nothing is happening
... we cannot move requirements forward without regular meetings
... we did have the meetings for jlreq and now for alreq
... so asking: would it make sense to have a task force for tibetan?

angel: we want to avoid unnecessary tension
... would be good to have a neutral home

addison: other task forces are organized on a per script basis.
... task force is not a script of a particular place
... a task force does not say: the script goes with a certain state

chunming: we want to collect information of layout from different languages and want to publish that as different documents
... the only concern is about organising the work
... you are right, tlreq is not pushing fast
... before last tpac, our contact was one professor in mongolian univ.
... now seems not be very active
... but some engineers from our members show interest in mongolian
... currently we don't have first draft, just email discussion

richard: email discussion is mostly on unicode topics

angel: clreq is all fine, chinese can mean mandarin. for us chinese means all the languages spoken in china. we can change the chinese title into saying: hanzi requirements (in chinese title).
... then these people don't have to join the chinese task force
... get another task force to join and change the name of this task force

bobby: could it be possible to share some infos between docs?

addison: I thought we produce separate docs?

agreement from the room

angel: goal to close all issues by the end of this year

bobby: agree

chunming: can we push for official clreq by end of this year?

richard: if you tell us that the doc is complete, sure

angel: should this be a living doc?

addison: we can publish drafts again and again, and then a note
... a new note then would be version two, etc.

discussion on tibetan

addison: in jlreq, mixed layouts was important topic

chunming: status report of tibetan
... offline mail discussion, does not reflect back to github
... we found people working in publishing house for tibetan content
... we got support of national standards WG in china

<r12a> http://w3c.github.io/tlreq/

chunming: also from @Lasa university
... those people are happy to make review of document
... also found a publishing house in china and china mobile, experts that are happy to contribute
... that is human resource status. Bottleneck is me - we need to set up those people, organize f2f meetings
... so that we can build trust and relationships with them
... according to our previous schedule I am happy to held f2f after this TPAC
... my target is to have first version reflect back to w3c github, open to public document

richard: after last TPAC we agreed that I update doc, you were to translate it and publish as FWPD
... that doc is ready in english, then needs translation
... they may change it completely, but good to have s.t. to look at

chunming: one of my students is working on translation
... need to update it back to html

richard: can I help? I'm willing to dedicate personal time to making it happen.

chunming: I can do it asap

angel: similar issue like with simplified chinese - editor not familar with github

addison: concerns about separate work modes.

chunming: HTML is not a problem. we want to identify right person to take the editor role.
... they should be familiar with github, html etc.
... for tlreq, there is english and chinese, need to update to make it english - chinese version on github
... chunming we have f2f meeting with editors / reviewers, so that they can have f2f discussion on each item
... after that we can reach to first public WD

richard: I just want to make publication asap. Is discussion necessary before publication?

chunming: want to build trust and a relationship with editors, will set up offline f2f, what the next steps are
... want to have whole day f2f meeting to invite some reviewers
... to give a full review of current version, to make sure a more reliable version is released

richard: better to have something than nothing. So I'd like to set a date on the discussions and FPWD
... but also i'm concerned that the review doesn't stop progress to FPWD by debating every point - i think it's better to look for showstoppers and significant problems, fix those quickly, then publish FPWD, and then work through the remaining issues afterwards

chunming: we can have FPWD by end of this year
... before that, we will have small group meetings

agreement on how to proceed

mongolian as a topic to be discussed later

chunming: we have national standard for mongolian, not fully reflected to our requirements

richard: if you need help to create first draft I can help

chunming: this doc will share same outline as clreq or klreq. structure is quite clear

angel: will see if there is formal version of Uighur national standard is available.

richard: there will be discussion on moving task forces to community group - whether it is feasible etc.

angel: happy to join discussion


Issue Triage

<addison> exuent: chunming, bobbytun, angel

<addison> scribe: addison

rebeca: (self introduction)
... improve latin layout requirements

andreas: andreas tai from munich
... work mostly with captions and subtitles
... timed text has ways to markup bidi, kind of mystical
... interested in what this wg does

JSON and Bidi

<r12a> http://w3c.github.io/i18n-discuss/notes/json-bidi.html

richard: (introducing topic)
... the paragraph direction of the string as a whole
... reason that complex is that base direction isn't expressed int he string
... might be expressed in the html document
... like in a form
... going to be submitted, etc.
... text would go from rtl because html file says dir=rtl
... looks rtl oriented because of that
... but when typing in english document
... doesn't look right, so user sets direction on form element
... surrounding "stuff" contains the knowledge
... string doesn't encode it
... and associate it in some way with the string
... so consumer can apply correct direction
... how do we do that association
... one way is a direction property in an annotation
... people like tantek don't like that approach

addison: strings want to carry metadata (dir and lang)

richard: producers == people putting text into a json string
... consumer == people reading the json
... 3 basic approaches
... 1. first strong
... 2. insert markers into string
... 3. property that comes with property
... look at storing base direction

<fsasaki> this is how an RDF language tag looks like in json-ld = the same as the direction property currently being discussed: "http://example.com/myproperty": { "@language": "en", "@value": "That Seventies Show" }

"content": "mystring"@@en-US^^rtl

"content":"mycontent", "content-dir": "ltr"

<fsasaki> this may be addison's wiki page on the issue: https://www.w3.org/International/wiki/ContentMetadataJavaScriptDiscussion

<r12a> https://www.w3.org/TR/activitystreams-core/#h-biditext



question: webannotation: are we doing the right thing

JSON bidi further discussion

- webannotation: changes

- do we need another serialization scheme (pursue standards)?


<cue dir=rtl lang=ar>alala</cue>

"cue": "alala"


"cue": { dir: rtl lang:ar text:alala}

<r12a> https://www.w3.org/International/wiki/TPAC2016_Agenda


<scribe> ACTION: addison: write to json-ld about potential for a serialization form for natural language strings to address issues with dir and lang [recorded in http://www.w3.org/2016/09/22-i18n-minutes.html#action01]

<trackbot> Created ACTION-552 - Write to json-ld about potential for a serialization form for natural language strings to address issues with dir and lang [on Addison Phillips - due 2016-09-29].

discussion of webannotation vs. activitystreams

richard: for external resources (uris), doesn't make sense to include direction?

<r12a> https://github.com/w3c/web-annotation/issues/335

<r12a> https://github.com/w3c/web-annotation/issues/335#issuecomment-237636530

<r12a> https://github.com/w3c/web-annotation/issues/335#issuecomment-237895142

<scribe> ACTION: addison: work with richard to develop a pros/cons document describing the different bidi-in-json handling proposals [recorded in http://www.w3.org/2016/09/22-i18n-minutes.html#action02]

<trackbot> Created ACTION-553 - Work with richard to develop a pros/cons document describing the different bidi-in-json handling proposals [on Addison Phillips - due 2016-09-29].

Issues Triage

<r12a> http://w3c.github.io/i18n-activity/reviews/

<fsasaki> [just for reference, discussion of the json issue in the XLIFF tc: https://lists.oasis-open.org/archives/xliff/201510/msg00009.html ]

• rb and rtc non-conforming in html5.1 https://github.com/w3c/i18n-activity/issues/215


<r12a> https://github.com/whatwg/html/issues/1771

okay, don't close and track whatwg 1771 in that issue

• BP3 should recommend locale-neutral representation https://github.com/w3c/i18n-activity/issues/187





• What Latin means https://github.com/w3c/i18n-activity/issues/47


changed text to: "... books that use the Latin script, based on ...


• Possibility for a character to be interpreted differently depending on locale https://github.com/w3c/i18n-activity/issues/114




addison: prefer language to locale in several places in the text, but okayy


• list of displays: should it address display name, language, etc.? https://github.com/w3c/i18n-activity/issues/113


close as stale

• Make unicode-bidi: isolate the default for elements with a dir attribute (mozilla) https://github.com/w3c/i18n-activity/issues/26

they did it


• [csvw] instance definitions for direction https://github.com/w3c/i18n-activity/issues/153


• Consider removing TextEncoder support for UTF-16 https://github.com/w3c/i18n-activity/issues/116


Coffee Break

Social Web

(Social Web folks join)

Amy Guy




Chris W

<addison> http://w3c.github.io/i18n-activity/reviews/

<r12a> https://github.com/w3c/Micropub/issues/39

<addison> https://github.com/w3c/Micropub/commit/82a49a3fa6ff6b19923344eae1288bf367f3b2bf

addison: that looks okay

RESOLUTION: close https://github.com/w3c/Micropub/issues/39 with everyone happy

aaronpk: that was my only still-open micropub one

<aaronpk> https://github.com/w3c/webmention/issues/57

on webmention:

aaronpk: "no language support"
... wm is a server-to-server protocol. In normal operation the response body is never seen.
... it only comes up when people are developing / debugging
... some developers never realized there was a response body
... talking about it today, we're curious about for error responses, is there any typical guidance?

addison: Several classes of things have occured
... in past standard
... ietf has idefault
... not a very global-friendly thing
... we generally look at, if you're going to exchange natural lang text, you should including an indication of the language
... so it's a good idea to provide language information if it's available
... for APIs that interact with users, language negotiation is good
... so the server can respond with the language the user wants
... we not ulta-concerned

sandro: can we just use http header?

addison: that's what I recommended

aaronpk: we're planning to change the example to not include a body, because there's no functionality in having a body
... since we're not recommending that
... and adding a note explaining what implementations have done.
... and saying some endpoints, when the request comes from the browser, give a full HTML response with all the negotiation
... so include something about using HTTP best practices around Accept-Language

addison: example would just be HTTP 201 Created

aaronpk: do we want to remove specific recommendation of returning human-readable text

addison: if you take out human readable, we wouldn't care very much

r12a: Content-Language can have multiple languages, though, so maybe it's not ideal

addison: although that's not best practice

r12a: if you happen to have multiple languages, it could be a problem

sandro: sounds like: if you include a body, you should include a content-language

aaronpk: in practice, there's usually very little information returned from API to reduce attack vector

addison: when running in production

aaronpk: in 3.2.3 error responses

addison: when the server is down, you probably don't have a lot more information. It's nice to do i18nish things, but whatever.

aaronpk: send to target URL that doesn't exist

addison: that's okay
... can leave that section alone
... We'd have nothing to comment on if there's no example there.
... I dont know what else you'd put in a response body

aaronpk: Some return a data dump, some have an English sentence, etc
... none of it affects interop

addison: cool

aaronpk: Noting in issue....

<aaronpk> https://github.com/w3c/webmention/issues/57#issuecomment-248931056

aaronpk commented 16 seconds ago

Notes from discussion with i18n:

Remove example english text from response body

Don't include "bad examples" of returning English without returning a language header

Error response section does not need an i18n recommendation because it does not suggest any response body

r12a: we don't have 167 marked as green

addison: your change will get rid of 167 because there's no longer a text/plain

aaronpk: In POST the body is form-encoded URL

addison: we were just responding to your response examples
... These are just URLs, its fine
... don't include charset with form-encoded. It's with text/plain.
... that's why you MUST pre-define that this is utf-8, because there's no where in the protocol to say that.


<r12a> https://github.com/w3c/webmention/issues/56

aaronpk: we just covered this

<ben_thatmustbeme> sandro: woohoo

sandro: we'll be sending you two more specs right away, and two more soon-ish

cwebber2: ActivityPub is unlikely to have much i18n, because it mostly just is a user of AS2

<cwebber2> https://www.w3.org/TR/activitypub/ is activitypub

<Loqi> [Christopher Allan Webber] ActivityPub

csarven: In Linked Data Notification (LDN) it's just HTTP

<cwebber2> https://linkedresearch.org/ldn/ is linked data notifications

<cwebber2> https://www.w3.org/International/techniques/developing-specs

addison: Give us URLs and maybe we can take a quick glance, ... or you can look at our list
... And then let us know when you've done that

aaronpk: on json....?

addison: No charset of json, defined as utf8

<addison> www.org/International/

addison: On our homepage is a huge box on how to request review.

<r12a> https://www.w3.org/International/review-request

addison: mostly it means send email.

sandro: so review is likely to go more smoothly if we've done the checklist?

addison: generally, but not everything is clear from the checklist

aaronpk: just to clarify, including charset with json is wrong?

addison: that's right, don't do it.



r12a: It's hanging around because I suggested adding a note saying it's useful to including a language when you're dealing with strings

cwebber2: the normalization algorithm loses it. I see.


<Loqi> [James M Snell] Activity Streams 2.0

<cwebber2> http://json-ld.org/playground/?startTab=tab-expanded&json-ld=%7B%22%40context%22%3A%22https%3A%2F%2Fwww.w3.org%2Fns%2Factivitystreams%22%2C%22%40language%22%3A%22fr%22%2C%22type%22%3A%22Note%22%2C%22name%22%3A%22Une%20note%20br%C3%A8ve%22%7D

<cwebber2> http://json-ld.org/playground/?startTab=tab-expanded&json-ld=%7B%22%40context%22%3A%22https%3A%2F%2Fwww.w3.org%2Fns%2Factivitystreams%22%2C%22%40language%22%3A%22fr%22%2C%22type%22%3A%22Note%22%2C%22name%22%3A%22Une%20note%20br%C3%A8ve%22%7D

<cwebber2> http://json-ld.org/playground/#startTab=tab-nquads&json-ld=%7B%22%40context%22%3A%5B%22https%3A%2F%2Fwww.w3.org%2Fns%2Factivitystreams%22%2C%7B%22%40language%22%3A%22fr%22%7D%5D%2C%22type%22%3A%22Note%22%2C%22name%22%3A%22Une%20note%20br%C3%A8ve%22%7D

r12a: In "When using [JSON-LD] mechanisms to produce or consume Activity Streams 2.0 documents, the @language property MAY be used " ... we'd expect SHOULD there

sandro: I think the MAY is about which way you provide lang, not whether you provide lang.
... so maybe somewhere at the start of 4.7 we can say "You should put the language information in there somewhere"

addison: that's what we'd be looking for

sandro: so Example 16 is bad....

r12a: we at one point asked if you could put language in every example
... but didn't insist.

sandro: anyone want to speak for AS2?
... I'd like it'd be fine to make these editorial changes

cwebber2: It is kind of distracting to have it in every example

addison: Maybe state that we omited it from examples, with a ...

sandro: the At Risk phrasing is very confusing

addison: it can be hard to convince people to implement

cwebber2: there's a possible foot-aimed-gun, with developers just hardcoding "en".

addison: SHOULD helps with that, MUST tends to cause that more
... I understand some developers aren't terribly motivated

sandro: Our concern is developers might then just not use AS2

addison: we understand...
... you could provide a more elegant way to specify the language, but that would be a different pain.

cwebber2: that's what @language without the { } is
... it gets lost in RDF-land

sandro: it seems reasonable TO ME to update many/most examples to be like example 19, AND to add a note explaining the importance of including language information, eg around Example 16.
... but there may be other views in the WG, and implementor community

r12a: yes, we'd be happy with that

rhiaro: thinking about Social Web Protocols...
... Any examples are going to use AS2

sandro: doesn't MF2 have the same problem?

aaronpk: yes?

rhiaro: why hasn't this been noticed before?
... so the examples in the MicroPub spec that are in English?


<Loqi> [Aaron Parecki] Micropub

(example of posting some natural language text, with no language indicator)

MicroPub is using MicroFormats (MF2), and MF2 doesn't happen to handle lang

rhiaro: so, this was swept under the rug, and now we've noticed. What do we do about it?

bigbluehat: there is a proposal to add lang to MF2, but it's not mature

rhiaro: Does MP have to resolve this dependency on MF? Can MP proceed without this problem being solved?

addison: it's not exactly your problem that you based MP on MF2, but it is the problem of the international community. Maybe some day we tackle i18n for MF.

<tantek> for reference: https://github.com/microformats/microformats2-parsing/issues/3

<tantek> input welcome!

<addison> I think we are coming to the conclusion that we (I18N) might ought to do a review

<tantek> I think that would be welcomed, certainly speaking for myself. Appreciate the consideration!

<addison> https://www.w3.org/International/wiki/ContentMetadataJavaScriptDiscussion

<r12a> https://www.w3.org/International/questions/qa-lang-why

(from earlier)

aaron: we can handle bidi and non-english text, it's just not labeled
... best plan: write a note in MP saying we recognize this doesnt do lang, please see MF issue, and when that gets updated it will automatically be incorportated by reference.

sandro: yep, sounds fair. references to things that are updated in place are well known, if a bit challenging. For example: unicode.

addison: You don't want a social web protocol that references Unicode 7, so it doesn't have emogi!

<rhiaro> can't have a social web without emoji

<aaronpk> http://www.bbc.com/future/story/20151012-will-emoji-become-a-new-language

<tantek> https://socialwg.indiewebcamp.com/irc/social/2016-09-22/line/1474561478592 😃

<scribe> ACTION:addison: work to schedule a review of microformats [recorded in http://www.w3.org/2016/09/22-i18n-minutes.html#action03]

<scribe> ACTION:addison:work to schedule a review of microformats [recorded in http://www.w3.org/2016/09/22-i18n-minutes.html#action04]

<fsasaki> ACTION: addison to work to schedule a review of microformats [recorded in http://www.w3.org/2016/09/22-i18n-minutes.html#action05]

<trackbot> Created ACTION-554 - Work to schedule a review of microformats [on Addison Phillips - due 2016-09-29].

<scribe> ACTION: addison to provide implementer guidelines for how to obtain language from runtime environment, users, et al [recorded in http://www.w3.org/2016/09/22-i18n-minutes.html#action06]

<trackbot> Created ACTION-555 - Provide implementer guidelines for how to obtain language from runtime environment, users, et al [on Addison Phillips - due 2016-09-29].

End of Day/Closing

adjourning for the day

Summary of Action Items

[NEW] ACTION: addison to provide implementer guidelines for how to obtain language from runtime environment, users, et al [recorded in http://www.w3.org/2016/09/22-i18n-minutes.html#action06]
[NEW] ACTION: addison to work to schedule a review of microformats [recorded in http://www.w3.org/2016/09/22-i18n-minutes.html#action05]
[NEW] ACTION: addison: work to schedule a review of microformats [recorded in http://www.w3.org/2016/09/22-i18n-minutes.html#action03]
[NEW] ACTION: addison: work with richard to develop a pros/cons document describing the different bidi-in-json handling proposals [recorded in http://www.w3.org/2016/09/22-i18n-minutes.html#action02]
[NEW] ACTION: addison: write to json-ld about potential for a serialization form for natural language strings to address issues with dir and lang [recorded in http://www.w3.org/2016/09/22-i18n-minutes.html#action01]
[NEW] ACTION: addison:work to schedule a review of microformats [recorded in http://www.w3.org/2016/09/22-i18n-minutes.html#action04]

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/09/30 07:53:38 $