W3C

Internationalization Core Working Group Teleconference

22 Jun 2011

Agenda

See also: IRC log

Attendees

Present
Regrets
Chair
Addison Phillips
Scribe
Addison Phillips

Contents


Minutes and Agenda review

Action Items

Talk with Bert about how to deal with change marks in Ruby spec

richard: dealt with the change marks
... will ask webmaster to publish

close ACTION-36

<trackbot> ACTION-36 Talk with Bert about how to deal with change marks in Ruby spec closed

<r12a> http://www.w3.org/International/track/actions/open

Propose move of Ruby CSS spec to WD on agenda for CSS WG

richard: fantasai did it

close ACTION-37

<trackbot> ACTION-37 Propose move of Ruby CSS spec to WD on agenda for CSS WG closed

close ACTION-40

<trackbot> ACTION-40 Rewrite response with new proposal to do normalization in comparison closed

close ACTION-41

<trackbot> ACTION-41 Forward revised normalization letter to CSS including information about namespaces closed

close ACTION-42

<trackbot> ACTION-42 Create wiki page with normalization position paper closed

Review Contacts API and collect last call comments for the WG. WG members to perform review.

koji: first cut of review to mailing list

close ACTION-25

<trackbot> ACTION-25 Finish edits and convert time zones document to HTML closed

Contact epub folks and see if jukugo-ruby can be supported with html5 markup or if something else is needed

koji: can be supported with existing html5 markup

richard: general question was "do we need complex ruby"
... which means, "is there a way to do jukugo ruby in html5"

koji: double ruby not possible?

richard: possible to do with nested markup

koji: kind of a hack
... doesn't represent context

<kojiishi> http://fantasai.inkedblade.net/weblog/2011/ruby/

koji: fantasai's blog (above) describes it
... CSS3 needs to add properties to support it
... double ruby can be done without rtc, but semantics are wrong

close ACTION-49

<trackbot> ACTION-49 Contact epub folks and see if jukugo-ruby can be supported with html5 markup or if something else is needed closed

<kojiishi> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12935

scribe: but 12935 is something else

addison: so we may need to file a new bug

Info Share

richard: may have noticed all of the email
... put all comments into tracker

<scribe> ... closed and open both

UNKNOWN_SPEAKER: so we don't need to look at old tables

fsasaki: link from home page to tracker?

richard: meaning to do that for awhile
... links from review page

<r12a> http://www.w3.org/International/reviews/

richard: now actually says tracker there
... put on core page
... maybe on main page too?

<r12a> http://www.w3.org/International/resources

richard: updated resources page
... didn't point to techniques page
... and topic index

Upcoming Reviews

HTML5 WebIDL Widgets

<r12a> http://www.w3.org/International/core/review-radar

http://lists.w3.org/Archives/Public/public-i18n-core/2011AprJun/0125.html

Review spec at http://dev.w3.org/2009/dap/contacts/

find() 1. Does it search by ignoring cases? If so, does it take the Unicode casing algorithm into account? 2/ Does it search by using Unicode normalizations?

1. Which version of vCard is supported?

problem because charset support is changed in v3.0

2. Does it support CHARSET type parameter defined in vCard 2.1, which was eliminated in vCard 3.0? Outlook 2010, for instance, generates vCard 2.1 with CHARSET type parameters.

3. Outlook and some East Asian vCard providers such as mobile phones use "X-" proprietary extension fields to represent reading/phonetic information (see below.) How much do you care interoperability with such providers?

Personal names around the world[1] indicates that there are some cases where multiple family names are required. I'm not sure whether we should ask the spec to incorporate this by making familyName as an array of strings or not, as one can set multiple words in the property anyway, and doing so may affect vCard format. Any opinions?

Some scripts such as East Asian scripts requires fields to indicate how to read and/or pronounce values, since there could be multiple ways to read a written text. Reading/phonetic field is not only helpful to know how to read/pronounce his/her name, but also for sorting and grouping since sorting and grouping are usually done by reading/phonetic rather than written text in such scripts. Properties that should consider adding reading/phonetic information are

There are a few ways to solve this issue: 1. Add properties for fields that has reading/phonetic information associated. For instance, Microsoft MAPI/Outlook API adds 3 fields for this purpose; YomiFirstName, YomiLastName, and YomiCompanyName ("Yomi" stands for "reading" in Japanese.) 2. Use an extension of pronunciation attribute[2] defined by IMC. In this case, it is helpful to have utility functions to split reading and display from combined strings, and

[2] http://www.imc.org/pdi/vcard-pronunciation.html

<r12a> http://www.w3.org/International/questions/qa-personal-names#sorting

Marie-Jose Carreño Quiñones

two way problem: culture that is sending the card and culture that is doing the sorting

addison: directionality?

<scribe> chair: objections to making these WG comments?

richard: needs to be packaged slightly differently
... make separate comments out of the items

<r12a> http://www.w3.org/International/track/products/5

<scribe> ACTION: addison: convert koji's comments on contacts API into tracker comments to forward to DAP [recorded in http://www.w3.org/2011/06/22-i18n-minutes.html#action01]

<trackbot> Created ACTION-50 - Convert koji's comments on contacts API into tracker comments to forward to DAP [on Addison Phillips - due 2011-06-29].

<scribe> ACTION: richard: create a new product for contacts API in tracker [recorded in http://www.w3.org/2011/06/22-i18n-minutes.html#action02]

<trackbot> Created ACTION-51 - Create a new product for contacts API in tracker [on Richard Ishida - due 2011-06-29].

richard: be aware that instructions on raising issues is updated

<r12a> http://www.w3.org/International/reviews/review-instructions

Normalization

addison: summarizes phone call with cssns

richard: will go ahead with css-ns
... also with selectors
... peter agrees normalization is important "to fix at a future date"

addison: did not say we wouldn't object to that
... need to prepare to ask for a TAG finding
... 1. here is the problem of normalization
... 2. list of examples from the wild
... 3. recommendation for the finding (selector matching)
... 4. impacts

<David> +1

<scribe> ACTION: addison: contact the TAG to ask for finding on normalization in about a month [recorded in http://www.w3.org/2011/06/22-i18n-minutes.html#action03]

<trackbot> Created ACTION-52 - Contact the TAG to ask for finding on normalization in about a month [on Addison Phillips - due 2011-06-29].

<scribe> ACTION: addison: create working draft of TAG finding document [recorded in http://www.w3.org/2011/06/22-i18n-minutes.html#action04]

<trackbot> Created ACTION-53 - Create working draft of TAG finding document [on Addison Phillips - due 2011-06-29].

AOB?

Summary of Action Items

[NEW] ACTION: addison: contact the TAG to ask for finding on normalization in about a month [recorded in http://www.w3.org/2011/06/22-i18n-minutes.html#action03]
[NEW] ACTION: addison: convert koji's comments on contacts API into tracker comments to forward to DAP [recorded in http://www.w3.org/2011/06/22-i18n-minutes.html#action01]
[NEW] ACTION: addison: create working draft of TAG finding document [recorded in http://www.w3.org/2011/06/22-i18n-minutes.html#action04]
[NEW] ACTION: richard: create a new product for contacts API in tracker [recorded in http://www.w3.org/2011/06/22-i18n-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2011/07/05 09:59:39 $