See also: IRC log
<myles> https://www.w3.org/TR/encoding/ ?
<r12a> myles https://github.com/whatwg/encoding/issues/62
felix: discussions with schema.org
<r12a> https://www.w3.org/International/wiki/TPAC2016_Agenda
<fsasaki> scribe: fsasaki
Myles: here to observe what is going on
<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
<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
<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
https://www.w3.org/International/wiki/TPAC2016_Agenda#Thursday.2C_22_September
question: webannotation: are we doing the right thing
- webannotation: changes
- do we need another serialization scheme (pursue standards)?
https://www.w3.org/International/wiki/ContentMetadataJavaScriptDiscussion
<cue dir=rtl lang=ar>alala</cue>
"cue": "alala"
"RLMalala"
"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].
<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
close
<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
http://w3c.github.io/dwbp/bp.html#locale_parameter
http://w3c.github.io/dwbp/bp.html#LocaleParametersMetadata
close
• What Latin means https://github.com/w3c/i18n-activity/issues/47
https://github.com/w3c/dpub-pagination/issues/6
changed text to: "... books that use the Latin script, based on ...
close
• Possibility for a character to be interpreted differently depending on locale https://github.com/w3c/i18n-activity/issues/114
https://github.com/w3c/presentation-api/issues/218
https://github.com/w3c/presentation-api/pull/280
https://github.com/w3c/presentation-api/commit/a6f555345a7b98016c6954ff0465b6b45cef7ec8
addison: prefer language to locale in several places in the text, but okayy
close
• list of displays: should it address display name, language, etc.? https://github.com/w3c/i18n-activity/issues/113
https://github.com/w3c/presentation-api/commit/c19d0570ace9494192694ceee94d25ccaee31b49
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
close
• [csvw] instance definitions for direction https://github.com/w3c/i18n-activity/issues/153
close
• Consider removing TextEncoder support for UTF-16 https://github.com/w3c/i18n-activity/issues/116
skipped
(Social Web folks join)
Amy Guy
Aaron
Sarven
Sandro
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.
https://github.com/w3c/webmention/issues/56
<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.
https://github.com/w3c/i18n-activity/issues/205
https://github.com/w3c/activitystreams/issues/354
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.
https://www.w3.org/TR/activitystreams-core/#naturalLanguageValues
<Loqi> [James M Snell] Activity Streams 2.0
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?
https://www.w3.org/TR/micropub/#new-note
<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].
adjourning for the day