[webapps] spec title editorial nit [I18N-ISSUE-433]

[Phillips, Addison]

Dear webapps,

This note is to forward a minor comment from the I18N WG about your document 
"Manifest for web applications" [1] that we missed forwarding previously.

Our comment is editorial in nature:

--
The title of the specification is "Manifest for web application". Should this 
be "Manifest for a Web application"?
--

Thanks (for I18N),

[1] http://www.w3.org/TR/2015/WD-appmanifest-20150212/
[2] https://www.w3.org/International/track/issues/433

Addison Phillips
Principal SDE, I18N Architect (Amazon)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

RE: RfC: Service Workers

[Phillips, Addison]

Hello Art,

Could you better define what "soon" means? More specifically, do you have a 
deadline for comments? I don't see any dates in the thread below.

Thanks,

Addison Phillips
Principal SDE, I18N Architect (Amazon)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@gmail.com]
> Sent: Monday, September 21, 2015 5:27 AM
> To: public-webapps
> Subject: Re: RfC: Service Workers
> 
> Please use the Version 1 branch for this review:
> 
> 
> On 9/21/15 7:27 AM, Arthur Barstow wrote:
> > [ Bcc: TAG (www-tag), WebAppSec WG (public-webapsec), Mobile IG
> > (public-web-mobile), W3C Chairs (chairs),  Review Announce list
> > (public-review-announce), Geolocation WG (public-geolocation) ]
> >
> > The Editors and active contributors of Service Workers intend to
> > publish a Candidate Recommendation soon (details below). Consequently,
> > this is a Request for Comments by the WebApps group to seek wide
> > review of the latest version of the spec:
> >
> > 
> >
> > The open issues for Version 1, and the spec's version history are [1]
> > and [2], respectively.
> >
> > If you have any comments, we prefer you submit them as Github issues
> > [3]; otherwise, please send your comments to the public-webapps list
> > [4] using a Subject: prefix of "[serviceworkers]".
> >
> > -Thanks, AB
> >
> > [1]
> >
>  > issue+milestone%3A%22Version+1%22>
> > [2] 
> > [3] 
> > [4] 
> >
> >
> > On 9/18/15 2:22 AM, Jungkee Song wrote:
> >> Hi all,
> >>
> >> We editors are happy to announce that we make a new branch for
> >> Service Workers 1 today [1].
> >>
> >> Thanks to all the contributions, Service Workers 1 now covers the
> >> fundamental model and the associated APIs to support offline-first
> >> and background processing requirements. The features in this version
> >> include:
> >>   - Register/Update/Unregister of a service worker registration
> >>   - Handle fetch events
> >>   - Fetch and Cache resources
> >>   - Manage service worker clients
> >>   - Communicate between a client and a service worker
> >>   - Define interfaces and algorithms for extensions (Push,
> >> Notification,
> >> etc.)
> >> ([2] is the remaining issues for this version in the github issue
> >> tracker.)
> >>
> >> On top of the above work, the contributors are now ready to continue
> >> with the discussions about new features including foreign fetch [3],
> >> fetch event's request's client, header-based installation,
> >> kill-switch, and so forth. These efforts will be put in Service
> >> Workers Nightly [4] which is just a new name for the original ED
> >> branch.
> >>
> >> We are planning to publish a CR based on Service Workers 1 soon
> >> during which we would like to focus on stabilizing the features (bug
> >> fix) and resolving compatibility issues among multiple
> >> implementations.
> >>
> >> For editors,
> >> Jungkee
> >>
> >>
> >> [1]
> >> https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/
> >> [2]
> >>
> https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3A
> >> issue+m
> >>
> >> ilestone%3A%22Version+1%22
> >> [3] https://github.com/slightlyoff/ServiceWorker/issues/684
> >> [4] https://slightlyoff.github.io/ServiceWorker/spec/service_worker/
> >>
> >>
> >> --
> >> Jungkee Song
> >> Samsung Electronics
> >
> 

RE: Copying multi-range selection

[Phillips, Addison]

> > This appears to make visual selection appealing--although it doesn't, for 
> > the
> reasons mentioned elsewhere, lead to sensible text operations unless the
> selected run happens to be all in a single direction.
> 
> and if the text runs all in a single direction, there's no difference between
> logical and visual selection anyway, right?.
> 

Exactly so.

RE: Copying multi-range selection

[Phillips, Addison]

> >> what's the use case driving this, and where are the requirements
> >> coming from?
> >>
> >> i ask because i'm inclined to think that the circumstances in which
> >> this would a produce useful results, given the way it carves up the
> >> actual content, are quite, perhaps extremely, limited.
> >
> > Well, the web platform "supports" editing, text selection, and
> > drag-and-drop/copy-and-paste, etc. through various APIs. The question
> > is how those should work with RTL content.
> 
> my question was specifically, why do it in a non-standard way for bidi text?
> (typical scenario is split visual but one range internally)
> 

I can understand why the question might occur, or at least why it might occur 
now. Logical selection, as mentioned in various responses, including Mati's, is 
much more convenient to implement on an API or coding level--and has the 
benefit that the selection is aligned with the actual structure/meaning of the 
text. But it is more difficult to implement the display and interface for 
logical selection, particularly on mobile displays where the "mouse" is a 
person's finger. The user cannot see through their finger when performing 
selection and the selection "handles" and highlights are a lot more complicated 
both to draw and for users to understand. This appears to make visual selection 
appealing--although it doesn't, for the reasons mentioned elsewhere, lead to 
sensible text operations unless the selected run happens to be all in a single 
direction.

Addison

RE: I18N comments on "Manifest for Web applications"

[Phillips, Addison]

Hi Kenneth,

Thanks for the reply.

I know you're using GitHub. However, whenever I'm filing/forwarding comments on 
a document on behalf of the Working Group, I always look at the SOTD in the 
document in question to see what instructions the receiving WG has. In this 
case, you have a fairly generic SOTD, which says in part:

--
This document was published by the Web Applications (WebApps) Working Group as 
a Working Draft. This document is intended to become a W3C Recommendation. If 
you wish to make comments regarding this document, please send them to 
public-webapps@w3.org (subscribe, archives). All comments are welcome.
--

If you prefer to have comments filed to GitHub, perhaps modify your 
instructions?

Thanks!

Addison

Addison Phillips
Globalization Architect (Amazon Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.



> -Original Message-
> From: Christiansen, Kenneth R [mailto:kenneth.r.christian...@intel.com]
> Sent: Friday, March 20, 2015 1:15 AM
> To: Phillips, Addison; public-webapps@w3.org
> Cc: public-i18n-c...@w3.org
> Subject: RE: I18N comments on "Manifest for Web applications"
> 
> Hi there,
> 
> The spec authors use GitHub for issue tracking. I duplicated your issues 
> there:
> https://github.com/w3c/manifest/issues
> 
> Thanks for looking into internationalization issues with the current spec.
> 
> Cheers,
> Kenneth
> 
> > -Original Message-
> > From: Phillips, Addison [mailto:addi...@lab126.com]
> > Sent: Thursday, March 19, 2015 6:20 PM
> > To: public-webapps@w3.org
> > Cc: public-i18n-c...@w3.org
> > Subject: I18N comments on "Manifest for Web applications"
> >
> > Hello Webapps,
> >
> > As previously mentioned, I am about to send you comments from the
> > Internationalization Working Group on your document (whose current
> > iteration lives at [1]). Because we use Tracker for our comments, I
> > will be sending each comment under separate cover. The I18N WG is
> > always happy to discuss our comments or ways to address same. Please
> > let me know if you prefer to receive comments in a different format
> > (such as Bugzilla) or if you need additional information.
> >
> > If you want to see a summary of our comments, you can find them
> > tracked at [2]
> >
> > Regards (for I18N)
> >
> > Addison
> >
> > [1] http://www.w3.org/TR/appmanifest/
> > [2] http://www.w3.org/International/track/products/74
> >
> > Addison Phillips
> > Globalization Architect (Amazon Lab126) Chair (W3C I18N WG)
> >
> > Internationalization is not a feature.
> > It is an architecture.

[appmanifest] appropriate use of ACI [I18N-ISSUE-417]

[Phillips, Addison]

From Tracker:

http://www.w3.org/TR/2015/WD-appmanifest-20150212/#sizes-member

In section 8.3 there are instructions for comparing/extracting size values that 
are either the string 'any' or in the format wwwxyyy (e.g. 1024x768). This 
section refers to ASCII case-insensitive comparison in an appropriate way. This 
comment is to call out the appropriate usage in this case.

==

Obviously, no action is required on this comment.

Addison Phillips
Globalization Architect (Amazon Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

[appmanifest] No direction metadata for 'name' (etc.) [I18N-ISSUE-416]

[Phillips, Addison]

From Tracker:

http://www.w3.org/International/track/issues/416

http://www.w3.org/TR/2015/WD-appmanifest-20150212/#name-member

The 'name' manifest member does not provide a means of indicating the base 
direction of the name string. This is equivalent to extracting the 'dir' 
attribute appropriate for the HTML  element's scope and may be necessary 
for correct rendering of bidirectional content.

For example, the author might need to set the base direction explicitly, since 
the Unicode paragraph detection algorithm can be fooled by a paragraph that 
starts with a strong LTR character, but is actually a RTL paragraph (or vice 
versa), eg. "نشاط التدويل is how you say 'i18n Activity' in Arabic."

It would be helpful to the author to be able to set the default base direction 
for a whole manifest file to rtl.

Addison Phillips
Globalization Architect (Amazon Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

[appmanifest] No language metadata for 'name' [I18N-ISSUE-415]

[Phillips, Addison]

From Tracker:

http://www.w3.org/International/track/issues/415

http://www.w3.org/TR/2015/WD-appmanifest-20150212/#name-member

The 'name' manifest member does not provide a way to indicate the language of 
the string. This may be necessary for proper presentation/rendering of the 
name, since, for example, different fonts might be selected for different 
languages (such as when selecting between Japanese and Chinese).

==

Note: this was addressed by [1] and I am only forwarding for completeness.

[1] https://lists.w3.org/Archives/Public/public-i18n-core/2015JanMar/0080.html 

Addison Phillips
Globalization Architect (Amazon Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

[appmanifest] No means of obtaining correctly localized manifest [I18N-ISSUE-414]

[Phillips, Addison]

From Tracker:

http://www.w3.org/International/track/issues/414

http://www.w3.org/TR/2015/WD-appmanifest-20150212/#obtaining

Section 6.1 discusses the steps in obtaining a manifest. There is no discussion 
of obtaining a correctly localized reference, particularly for use in cases 
where the source page itself has used language negotiation.
==

Note: this was previously discussed in the thread with your WG and apparently 
is considered out of scope?

Addison Phillips
Globalization Architect (Amazon Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

[appmanifest] No localized examples [I18N-ISSUE-413]

[Phillips, Addison]

From Tracker:  

http://www.w3.org/International/track/issues/413

http://www.w3.org/TR/2015/WD-appmanifest-20150212/#example-manifest 

There is an example of a manifest, but no example of non-English or non-ASCII 
data. Please consider adding some of each.

(This is an editorial comment)

Addison Phillips
Globalization Architect (Amazon Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

[appmanifest] No localization model [I18N-ISSUE-412]

[Phillips, Addison]

From tracker:
==
http://www.w3.org/TR/2015/WD-appmanifest-20150212/

Having read the entire document, I can't find any mention of localizbility. 
There is no way to indicate in the manifest the language of any of the language 
bearing metadata (name, short_name, etc.) nor a way to indicate different 
language versions of external resources (such as paths to icons). This seems 
like a serious oversight in the design and is not consistent with other 
packaging schemes.
==

Please note that this was previously discussed on your mailing list in response 
to my note [1], with a number of helpful responses by Marcos Caceres and 
others, such as [2].


[1] https://lists.w3.org/Archives/Public/public-i18n-core/2015JanMar/0068.html
[2] https://lists.w3.org/Archives/Public/public-i18n-core/2015JanMar/0071.html 

Addison Phillips
Globalization Architect (Amazon Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

I18N comments on "Manifest for Web applications"

[Phillips, Addison]

Hello Webapps,

As previously mentioned, I am about to send you comments from the 
Internationalization Working Group on your document (whose current iteration 
lives at [1]). Because we use Tracker for our comments, I will be sending each 
comment under separate cover. The I18N WG is always happy to discuss our 
comments or ways to address same. Please let me know if you prefer to receive 
comments in a different format (such as Bugzilla) or if you need additional 
information.

If you want to see a summary of our comments, you can find them tracked at [2]

Regards (for I18N)

Addison

[1] http://www.w3.org/TR/appmanifest/
[2] http://www.w3.org/International/track/products/74 

Addison Phillips
Globalization Architect (Amazon Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

[manifest] I18N review in progress

[Phillips, Addison]

Dear webapps,

The Internationalization Working Group is reviewing [2] your specification 
"Manifest for web application" per your request [1]. We were unable to complete 
our review during this week's teleconference. Our next teleconference is 
scheduled for 5 March, which is your deadline for comments. This note is to let 
you know that we will have some comments for you.

There are two concerns that I want to note in advance that perhaps you can 
clarify:

1. There is no localization model or apparently a means of finding out about 
the availability of different languages of a given app, including alternate 
icons, names, short names and such. I'm curious as to whether there is an 
intention to provide this capability? What do authors of localized web 
applications do?

2. There is no provision for language or bidirectional control for natural 
language text inside a manifest. For example, you can't tag the name of an app 
as being in Japanese (necessary for correct font selection by the host 
environment, for example) or to set the base direction of the name (so that 
mixed right-to-left and left-to-right text is drawn correctly).

Thanks (for I18N),

Addison

[1] https://lists.w3.org/Archives/Public/www-international/2015JanMar/0067.html
[2] https://www.w3.org/International/wiki/Review_radar 

Addison Phillips
Globalization Architect (Amazon Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

REMINDER: Last Call for: "Encoding"

[Phillips, Addison]

Dear HTML/CSS/SVG/Webapps/XML Core WGs,

As a reminder, the Last Call on the Encoding specification will close on 
Tuesday, 1 July. We hope for reviews from your working groups. Please let us 
know if you intend to review this document.

Thanks!

Addison Phillips
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

> -Original Message-
> From: Phillips, Addison
> Sent: Tuesday, June 03, 2014 12:45 PM
> To: cha...@w3.org
> Subject: Last Call for: "Encoding"
> 
> All,
> 
> Today, 3 June 2014, the Internationalization Working Group published a Last
> Call Working Draft of the "Encoding" specification. The Internationalization 
> WG
> specifically invites the following working group's comments: HTML, CSS,
> Webapps, Webapps Security, SVG, XML Core. We welcome and encourage
> other reviews.
> 
> 
> Title: Encoding
> Publication: 3 June 2014
> LC Ends: 1 July 2014
> URI: http://www.w3.org/TR/encoding/
> Full LC URI: http://www.w3.org/TR/2014/WD-encoding-20140603/
> Editors URI: http://encoding.spec.whatwg.org/
> 
> Instructions for Providing Feedback:
> 
> Please submit comments to the www-internatio...@w3.org mailing list with a
> subject line prefixed with "[Encoding]". The Internationalization working 
> group
> will track issues and create bugzilla bugs for you.
> 
> Issues are tracked by the Working Group here:
> https://www.w3.org/International/track/products/25
> Open bugs against the Encoding spec are found here:
> https://www.w3.org/Bugs/Public/buglist.cgi?product=WHATWG&component=E
> ncoding&resolution=---
> 
> Abstract of this Specification:
> 
> While encodings have been defined to some extent, implementations have not
> always implemented them in the same way, have not always used the same
> labels, and often differ in dealing with undefined and former proprietary 
> areas
> of encodings. This specification attempts to fill those gaps so that new
> implementations do not have to reverse engineer encoding implementations of
> the market leaders and existing implementations can converge.
> 
> This document is a snapshot of the WHATWG document of the same name.
> 
> 
> Record of the Decision to Request Transition:
> 
>  http://www.w3.org/2014/05/29-i18n-minutes.html#item05
> 
> There are no formal objections to this document currently.
> The patent disclosure page is located here: http://www.w3.org/2004/01/pp-
> impl/32113/status
> 
> The last call period for this document will end 1 July 2014 (approximately 4
> weeks).
> 
> Addison Phillips
> Chair (W3C I18N WG)
> 
> Internationalization is not a feature.
> It is an architecture.

IME API work...

[Phillips, Addison]

Dear Webapps,

Glenn Adams was kind enough to copy me on a recent note regarding the proposal 
to add IME API work to your charter [1]. The I18N Core WG discussed this 
proposal at our most recent teleconference [2]. Members of the WG are receptive 
to reviewing and commenting on this work. Several people expressed concerns 
related to recent experience with mobile devices and with keyboard APIs 
previously mooted, but we don't see any reason for you not to proceed.

The I18N Core WG tasked me with I18N-ACTION-96 [3] (this email) to express our 
interest in this work and particularly to request being included as a WG at 
appropriate review milestones.

Thanks (for I18N),

Addison

[1] https://lists.w3.org/Archives/Member/member-i18n-core/2012Feb/0008.html
   Aka: 
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0588.html 
[2] http://lists.w3.org/Archives/Public/public-i18n-core/2012JanMar/0043.html
[3] http://www.w3.org/International/track/actions/96 

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

widgets P&C rule 9.1.12...

[Phillips, Addison]

Hi Marcos and Webapps,

This is a personal last call comment [chair hat off]. I realize that it is 
late, but I was on vacation

A developer recently sent me a code review implementing the latest spec and I 
found some code that was utterly mystifying to me. It turns out that he 
implemented rule 9.1.12 in the current spec, which defines 
"user_agent_locales". This text seems really odd to me.

What I expected was from looking at step 8 in section 9.1.17 was to have a 
"language priority list" containing the locale(s) to search for using the 
Lookup algorithm from BCP 47. I expected that this list would usually consist 
of a single locale identifier (language tag) representing the current Widget 
runtime locale, although an implementation might occasionally use 
Accept-Language or some other source for a full language priority list such as 
shown in the examples. I read "user_agent_locales" to be the Widget's version 
of a language priority list.

The odd thing is that the rules in 9.1.12 "explode" each language range, but 
the BCP 47 Lookup algorithm already does this. For example, 9.1.12 would 
convert the language priority list "zh-Hans-CN,*" to the user_agent_locales 
string "zh-Hans-CN,zh-Hans,zh,*". But this is unnecessary because the Lookup 
algorithm's "remove from right logic" already does this (or, for xml:lang 
matching, you can use prefix matching). If you do both the lookup algorithm 
*and* the computation of user_agent_locales, you will do a bunch of unnecessary 
searching with lower efficiency.

If what you want is to define lookup by computing user_agent_locales and then 
doing exact path matches for each element, then that's okay, I suppose, 
although personally I would (and have) implemented it in memory rather than by 
computing an "exploded" user_agent_locales list.

So my request/proposal would be to either (a) eliminate section 9.1.12 and just 
specify BCP 47 Lookup or (b) specify the complete match algorithm using the 
list computed in 9.1.12 and state that it is compatible with BCP 47 lookup. I 
would strongly prefer (a) personally. The internationalization work in 
ECMAScript and at least one implementation do it that way.

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

clarification on 9.1.3

[Phillips, Addison]

In section 9.1.3 of the Widget P&C, the first step of the algorithm to find a 
file says:

Let path be the valid path to the file entry being sought by the user agent.

"valid path" is defined by a rather strict grammar — paths that have a double 
slash aren't matched by the grammar e.g. "path//to/file". 

What the spec doesn't say is what to do if step one fails, i.e. the path is not 
valid. Should null be returned? An error? Or is that implementation defined?

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

ES I18N participation (was: Re: Minor comments on Widgets)

[Phillips, Addison]

Robin Berjon asked:

>> I happened to be referring to the Widget spec this morning
>
> Out of curiosity: in what context?

One such context is on-going work on JavaScript/ECMAScript 
internationalization. My team at Lab126 is implementing the strawman [1] (and 
then some) for the Kindle version of WebKit. One of my team's extensions is 
resource lookups for JavaScript. I want that implementation to work *exactly* 
like Widgets P&C.

Incidentally, only the WebKit, Chrome, and IE folks seem to be participating in 
the above? It would be good if FF and Opera folks participated too.

[1] http://wiki.ecmascript.org/doku.php?id=strawman:i18n_api

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.

RE: Minor comments on Widgets

[Phillips, Addison]

I am happy with this resolution to my comments.

I will submit an LC comment about case handling in the locales path at an 
appropriate time.

Thanks,

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: Marcos Caceres [mailto:marc...@opera.com]
> Sent: Thursday, March 17, 2011 6:17 AM
> To: Arthur Barstow
> Cc: Phillips, Addison; public-webapps@w3.org; public-i18n-c...@w3.org
> Subject: Re: Minor comments on Widgets
> 
> Hi Art,
> 
> On 3/17/11 1:14 PM, Arthur Barstow wrote:
> > [Ooops; Sent before read ... ]
> >
> > Marcos - Addison's comments were submitted during the comment period
> > of a proposal to publish a new LCWD of this spec. I think that
> > publication should be blocked until there is consensus on how to address the
> comments.
> 
> With the updates I have just made, I think we are good to publish. If there 
> are
> further comments, we should address them during LC.
> 
> WDYT?

RE: Minor comments on Widgets

[Phillips, Addison]

Hi,

One more minor note. In the grammar in section 5.3, you have:

low-alpha  = %x61-71

I suspect you mean for this to be:

low-alpha  = %x61-7a


thanks,

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.




> -Original Message-
> From: Phillips, Addison
> Sent: Tuesday, March 15, 2011 8:41 AM
> To: 'public-webapps@w3.org'
> Cc: 'public-i18n-c...@w3.org'
> Subject: Minor comments on Widgets
> 
> Hello Webapps WG,
> 
> (these are personal comments)
> 
> I happened to be referring to the Widget spec this morning and noticed a few
> minor items that I feel should be brought to your attention.
> 
> 1. Section 5.3 (Zip Relative Paths). The ABNF defines "language-range". I 
> think
> this is not desirable. Language ranges are input to the matching algorithm 
> (i.e.
> the user's request). You don't really want paths like "locale/de-*-1901". You
> want concrete paths here and "*" has no business in a path. Ideally you would
> reference the "Language-Tag" production in BCP 47 (RFC 5646). However, since
> it is a large production and you don't probably want to directly incorporate 
> it,
> you could incorporate the "obs-language-tag" production in the same document
> instead. You should still say that language tags used in paths "must" be valid
> language tags according to the more formal production.
> 
> 2. Section 5.3. The same production corresponds to BCP 47 (RFC 4647)
> "extended-language-range", although it only allows the tags to use lowercase
> letters. I really feel that mixed case is not that difficult to support and 
> that it
> will save many developers from inexplicable silent failures.
> 
> 3. There is no mention of case sensitivity of filenames anywhere that I can 
> find.
> You should define if filenames are case sensitive (or not) and what is meant 
> by
> "case sensitive" if it is supported (just ASCII case? Unicode default case
> mapping?)
> 
> Thanks,
> 
> Addison
> 
> Addison Phillips
> Globalization Architect (Lab126)
> Chair (W3C I18N, IETF IRI WGs)
> 
> Internationalization is not a feature.
> It is an architecture.

Minor comments on Widgets

[Phillips, Addison]

Hello Webapps WG,

(these are personal comments)

I happened to be referring to the Widget spec this morning and noticed a few 
minor items that I feel should be brought to your attention. 

1. Section 5.3 (Zip Relative Paths). The ABNF defines "language-range". I think 
this is not desirable. Language ranges are input to the matching algorithm 
(i.e. the user's request). You don't really want paths like "locale/de-*-1901". 
You want concrete paths here and "*" has no business in a path. Ideally you 
would reference the "Language-Tag" production in BCP 47 (RFC 5646). However, 
since it is a large production and you don't probably want to directly 
incorporate it, you could incorporate the "obs-language-tag" production in the 
same document instead. You should still say that language tags used in paths 
"must" be valid language tags according to the more formal production.

2. Section 5.3. The same production corresponds to BCP 47 (RFC 4647) 
"extended-language-range", although it only allows the tags to use lowercase 
letters. I really feel that mixed case is not that difficult to support and 
that it will save many developers from inexplicable silent failures.

3. There is no mention of case sensitivity of filenames anywhere that I can 
find. You should define if filenames are case sensitive (or not) and what is 
meant by "case sensitive" if it is supported (just ASCII case? Unicode default 
case mapping?)

Thanks,

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.

minor comment about file extensions

[Phillips, Addison]

Dear Webapps WG,

This is a personal comment on the Widgets P&C draft dated 5 October 2010. I 
recognize that your last call period closed, however, a colleague of mine 
noticed that rule 9 at [1] defines only the ASCII alphabetic ranges and does 
not include the ASCII digits. This means that it can't be used to identify 
types such as 'mp3'.

Thanks,

Addison

[1] http://www.w3.org/TR/widgets/#rule-for-identifying-the-media-type-of-a

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.

RE: [widget] proposal to add defaultlocale attribute to widget element (P&C Spec), I18N ACTION-18

[Phillips, Addison]

Dear Marcos,

[this is a reply on behalf of the Internationalization Core WG]

We agree that not providing a default locale for a Widget is an oversight in 
the Widget's localization model. The ability to provide multiple languages in 
the configuration file or in the locales directory structure does not provide 
the Widget container with a clear choice when the runtime language is not one 
of the languages provided.

Part of this oversight may be due to an expectation that there would be a 
"default" set of resources present in the Widget. For example, if you had a 
structure like this:

   Foo.html
   /locales
  /de-DE
  Foo.html

... then if the top "Foo.html" is the start file, it is the default and 
"/locales/de-DE/Foo.html" represents a German appropriate resource 
corresponding to that same file. The language of the top-level resource can be 
anything and can be defined using the usual attributes. However, there is no 
requirement that such content be provided nor that it be in any particular 
language.

This does not, as you point out, work with items defined in the config.xml file 
itself.

In practice, most resource systems require that the "base" or "root" locale's 
resources be present to guarantee full functionality. The description in 
Widget's P&C implies this. It should state it explicitly and/or provide a 
mechanism for specifying the default.

The attribute 'defaultlocale' that you propose makes sense as a means of doing 
this. The alternative is to overload xml:lang="", but this has a number of 
negative things associated with it--such as the fact that it prevents the 
format from indicating what language the default is.

Finally, on a separate topic, we want to note that there is significant 
progress on internationalization additions to ECMAScript going on currently, 
which will be of great benefit to widget writers interested in 
internationalization and which may be of interest to Webapps WG as a result.

Regards (for I18N),

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core-
> requ...@w3.org] On Behalf Of Marcos Caceres
> Sent: Monday, December 27, 2010 5:29 AM
> To: public-webapps; public-i18n-c...@w3.org
> Cc: Richard Ishida
> Subject: [widget] proposal to add defaultlocale attribute to widget
> element (P&C Spec), was Re: [widgets] Span example
> 
> On Fri, Apr 30, 2010 at 5:16 PM, Marcos Caceres 
> wrote:
> > Hi Richard,
> >
> > On Fri, Mar 26, 2010 at 9:32 PM, Richard Ishida 
> wrote:
> >>
> >> The example looks rather baroque, but I think it does illustrate
> a number
> >> of points.  (I think that in real life it may be simpler to just
> use
> >> xml:lang="he" and dir="rtl" on the description tag in a
> localized config
> >> file like this.  The example does currently illustrate
> inheritance though.
> >
> > Yeah, the example is convoluted on purpose to illustrate all the
> features
> > you mentioned.
> >
> >>
> >> It also shows how to markup up the language while still marking
> default
> >> text for localization failures.  I hadn't realised that that was
> how you
> >> indicated the default for localization. FWIW I'd have preferred
> a special
> >> attribute for that, rather than overloading the xml:lang
> attribute, but I
> >> guess it's too late to change that now. An attribute like
> >> localizationdefault="yes" would reduce the need for the extra
> spans.
> >
> > good point. We can add it to our list of things to add in the
> future.
> 
> Seems the future finally arrived!:)... After some experience with
> deploying i18nlized widgets and trying to communicate the i18n
> model
> of widgets to developers, Opera strongly feels the need to add a
> "defaultlocale" (or similarly named) attribute to the widget
> element
> defined in the P&C spec.
> 
> As was pointed out by Richard, the problem with the current spec is
> that we have overloaded the semantics and functionality of xml:lang.
> As a result, the only way for an author to say that some content is
> not localized was for it not to have an xml:lang attribute (or for
> the
> xml:lang attribute to be explicitly empty). This is causing
> confusion
> amongst our development community. What would be preferable would
> be
> to have some means for authors to explicitly declare the default
> locale of a widget.
> 
> Consider the addition of a defaultlocale attribute:
> 
> http://www.w3.org/ns/widgets";
> defaultlocale = "en-us">
> 
>
> The Ultimate Weather Widget
>
> 
>
> Boletim Metereológico
>
> 
> 
> As in this case there is no unlocalized content, the user agent
> that
> does not support either 'en-us' or 'pt' will not select any content
> (!). Having  the defaultlocale allows the author to hint to user
> agent
> which one of the two to use in case it cannot match any conte

RE: Comment on Widget Interface...

[Phillips, Addison]

Hello Art, Marcos, and Webapps,

During our teleconference yesterday [1], I was tasked with formally replying to 
this request on behalf of the Internationalization WG. 

I would still like to see the 'locale' field restored to the interface. It's 
important to be able to query which locale the widget is running in (especially 
in the face of upcoming ECMAScript internationalization changes) so that the 
caller can match it if necessary.

I agree with Marcos's approach to returning the @lang. Marcos concluded with 
this comment:

> >
> > 3. At runtime, upon getting an attribute from the Widget object
> (e.g.,
> > widget.name), you need to display that properly. The case is:
> >
> > $("#somePElement).innerHTML = widget.name; //in Arabic
> >
> > To display it properly, we need something like the algorithm
> described in:
> > http://www.iamcal.com/understanding-bidirectional-text/

Most user-agents have implemented the Unicode Bidirectional Algorithm (which is 
what Cal is describing), so that isn't the issue, so much as the fact that 
sometimes the algorithm needs a little help. The problem is that the base 
direction of a string is sometimes necessary to get the correct behavior from 
strings. 

For excellent illustrations of this, see [2]. 

Using Unicode Bidi control characters is one way to manage this, but in a 
markup context, the 'dir' attribute is really preferable. If you're going to 
create LocalizedString, it should have both a lang and dir attribute that can 
be queried. Having @dir in P&C will help the Widget engine display the string 
properly too.

I look forward to seeing the resulting spec published. Please let me know if 
you need any assistance from me in making progress.

Thanks,

Addison

[1] http://www.w3.org/2010/10/13-i18n-minutes.html
[2] http://www.w3.org/International/articles/inline-bidi-markup/ 

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.

RE: Comment on Widget Interface...

[Phillips, Addison]

Hi Art,

I have scheduled this topic for our telecon tomorrow.

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@nokia.com]
> Sent: Tuesday, October 12, 2010 5:16 AM
> To: marc...@opera.com; Phillips, Addison; public-i18n-c...@w3.org
> Cc: public-webapps
> Subject: Re: Comment on Widget Interface...
> 
>   Hi Addison - our Widget Interface spec is blocked, pending
> feedback
> from the I18N community regarding Marcos' proposal below.
> 
> Would you please provide feedback by October 20 (the day before our
> next
> voice conf)?
> 
> -Art Barstow
> 
> On Oct/5/2010 12:10 PM, ext Marcos Caceres wrote:
> > hi Addison,
> >
> > On Thu, Sep 30, 2010 at 8:57 PM, Phillips,
> Addison  wrote:
> >>> Are you talking about a script using navigator.language?
> >> Not really, unless you expect navigator.language to be how
> widget containers expose the runtime locale.
> >>
> >> Widget P&C describes how a widget is packaged (which can include
> localization) and how it is configured (what the widget container
> should do when it "unpackages" and runs the widget). The container
> determines what the locale is going to be for the widget (which, as
> you pointed out in your earlier reply, is implementation specific).
> This, in turn, affects what language the 'name' or other fields
> returned by the Widget Interface are in. I'm suggesting that you
> need to provide programmatic access to this value, which may be
> distinct from navigator.language. Text direction for those fields
> might also need to be exposed.
> >>
> > Ok, so there are essentially three problems we need to tackle
> here:
> >
> > 1. Exposing the actual language which was used (during Step 7 in
> P&C)
> > to choose the localize the content for name and description (we
> don't
> > expose). We have this bit - this is solved:
> >
> > [[
> > 9.1.5. Rule for Getting a Single Attribute Value
> > ...
> >E. Let lang be the language tag derived from having processed
> the
> > xml:lang attribute on either element, or in element's ancestor
> chain
> > as per [XML]. If xml:lang was not used anywhere in the ancestor
> chain,
> > then let lang be an empty string.
> >
> >F. Associate lang with result.
> > ]]
> >
> > And similarly in section "9.1.8. Rule for Getting Text Content".
> [2]
> >
> > Essentially, for each element or attribute that is displayable,
> we
> > have an abstract object (a so called 'localizable string)' that
> is
> > represented as:
> >
> > {string: ' unicode |  ltr marker | rtl marker | lro marker | rlo
> marker |',
> > lang: "language tag | empty string"}
> >
> > 2. Given the liberal way that P&C selects languages, we could end
> up
> > with each attribute in the widget object containing different
> > languages:
> >
> > widget.name; /*in English*/
> > widget.shortName; /*unlocalized*/
> > widget.description; /*in French*/
> >
> > So, we basically need to extend DOMString:
> >
> > interface LocalizedString : DOMString {
> >  readonly attribute DOMString lang;
> > }
> >
> > Then:
> >
> > widget.name.lang === "en";
> >
> > 3. At runtime, upon getting an attribute from the Widget object
> (e.g.,
> > widget.name), you need to display that properly. The case is:
> >
> > $("#somePElement).innerHTML = widget.name; //in Arabic
> >
> > To display it properly, we need something like the algorithm
> described in:
> > http://www.iamcal.com/understanding-bidirectional-text/
> >
> >
> > WDYT?
> >
> > [1] http://dev.w3.org/2006/waf/widgets/#rule-for-getting-a-
> single-attribute-valu0
> > [2] http://www.w3.org/TR/widgets/#rule-for-getting-text-content
> >
> >

Re: Comment on Widget Interface...

[Phillips, Addison]

Hi Scott,

Yes, that's it. Do you know why it was removed?

Addison

Sent from my iPhone

On Oct 5, 2010, at 4:12 AM, "Scott Wilson"  
wrote:

> 
> On 5 Oct 2010, at 01:28, Charles McCathieNevile wrote:
> 
>> On Mon, 04 Oct 2010 23:32:46 +0200, Scott Wilson 
>>  wrote:
>> 
>>> Actually, just to totally contradict myself, we implemented the locale 
>>> attribute of the Widget interface and forget to take it out again when it 
>>> was removed from the spec :-)
>> 
>> The functionality Addison wants would most logically be defined in The 
>> Widget Interface, no?
> 
> It used to be:
> 
> http://www.w3.org/TR/2009/WD-widgets-apis-20090423/
> 
> It was removed in later revisions.
> 
>> 
>> cheers
>> 
>>> On 30 Sep 2010, at 20:37, Scott Wilson wrote:
>>> 
>>>> On 30 Sep 2010, at 16:51, Phillips, Addison wrote:
>>>> 
>>>>> Hi Art,
>>>>> 
>>>>> No, I don't think it does. While the means by which the (user/system 
>>>>> default) locale is determined may be implementation dependent, it is 
>>>>> still necessary that the runtime determine what it is. The Widget 
>>>>> interface thus needs to provide access to what it is. Otherwise how can 
>>>>> the script calling the interface determine what language it is getting 
>>>>> for the name, shortname, etc.? Or what locale the widget is actually 
>>>>> using in its runtime? Obtaining this would be useful if the script were 
>>>>> to request content or data formatting remotely (or do so locally using 
>>>>> the JavaScript I18N extension that is being developed).
>>>> 
>>>> At present in Wookie we generate a widget instance using localization 
>>>> parameters passed to our API, so the information you get from the widget 
>>>> interface will be localized. However for things like making AJAX calls to 
>>>> other services, you are correct that this information will not be 
>>>> available in the Widget runtime - seems like a reasonable UC.
>>>> 
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Addison
>>>>> 
>>>>> Addison Phillips
>>>>> Globalization Architect (Lab126)
>>>>> Chair (W3C I18N, IETF IRI WGs)
>>>>> 
>>>>> Internationalization is not a feature.
>>>>> It is an architecture.
>>>>> 
>>>>> 
>>>>>> -Original Message-
>>>>>> From: Arthur Barstow [mailto:art.bars...@nokia.com]
>>>>>> Sent: Thursday, September 30, 2010 6:18 AM
>>>>>> To: Phillips, Addison
>>>>>> Cc: public-webapps
>>>>>> Subject: Re: Comment on Widget Interface...
>>>>>> 
>>>>>> 
>>>>>> Hi Addison,
>>>>>> 
>>>>>> On 9/7/10 6:06 PM, ext Phillips, Addison wrote:
>>>>>>> Hello Webapps WG,
>>>>>>> 
>>>>>>> (This is a personal comment and is not necessarily indicative of
>>>>>> the I18N WG's opinion)
>>>>>>> 
>>>>>>> In Section 5 (The Widget Interface), the interface provides for
>>>>>> retrieving values such as 'name', 'shortName', etc. In Widgets P&C,
>>>>>> these can be localized in the configuration document (I assume that
>>>>>> the configuration document in this document means the same document
>>>>>> as P&C??). There is no mention of whether or how this value is
>>>>>> localized or if the locale/language is subject to programmatic
>>>>>> control (I assume not, since it is not mentioned).
>>>>>>> 
>>>>>>> Could there be an explicit mention of the language/locale and how
>>>>>> it interacts with user-agent? Can/should there be an accessor for
>>>>>> language? How about a way of querying the value by locale?
>>>>>> Support for locale was part of the Widget Interface spec but as we
>>>>>> worked through the localization model for the Packaging and
>>>>>> Configuration spec, we decided to remove it (at least for this
>>>>>> version
>>>>>> of the spec). The Packaging spec includes the gist of the
>>>>>> rationalization for this decision:
>>>>>> 
>>>>>> [[
>>>>>> http://www.w3.org/TR/widgets/#step-5--derive-the-user-agents-locale
>>>>>> 
>>>>>> As there are numerous ways a user agent can derive the end-user's
>>>>>> preferred languages and regional settings, the means by which those
>>>>>> values are derived are beyond the scope of this specification and
>>>>>> left
>>>>>> up to the implementation.
>>>>>> ]]
>>>>>> 
>>>>>> I suppose one could argue the Widget Interface implies the above
>>>>>> indirectly (via the reference to P&C spec). However, I don't see
>>>>>> any
>>>>>> harm if the above text were copied into the Interface spec. Would
>>>>>> doing
>>>>>> so address your concern?
>>>>>> 
>>>>>> -Art Barstow
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> -- 
>> Charles McCathieNevile  Opera Software, Standards Group
>>   je parle français -- hablo español -- jeg lærer norsk
>> http://my.opera.com/chaals   Try Opera: http://www.opera.com
> 

RE: Comment on Widget Interface...

[Phillips, Addison]

> Are you talking about a script using navigator.language?

Not really, unless you expect navigator.language to be how widget containers 
expose the runtime locale.

Widget P&C describes how a widget is packaged (which can include localization) 
and how it is configured (what the widget container should do when it 
"unpackages" and runs the widget). The container determines what the locale is 
going to be for the widget (which, as you pointed out in your earlier reply, is 
implementation specific). This, in turn, affects what language the 'name' or 
other fields returned by the Widget Interface are in. I'm suggesting that you 
need to provide programmatic access to this value, which may be distinct from 
navigator.language. Text direction for those fields might also need to be 
exposed.

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.

> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@nokia.com]
> Sent: Thursday, September 30, 2010 11:15 AM
> To: Phillips, Addison
> Cc: public-webapps; public-i18n-c...@w3.org
> Subject: Re: Comment on Widget Interface...
> 
> 
>   On 9/30/10 11:51 AM, ext Phillips, Addison wrote:
> > Otherwise how can the script calling the interface determine what
> language it is getting for the name, shortname, etc.? Or what
> locale the widget is actually using in its runtime? Obtaining this
> would be useful if the script were to request content or data
> formatting remotely (or do so locally using the JavaScript I18N
> extension that is being developed).
> Are you talking about a script using navigator.language?
> 
> -Art Barstow

RE: Comment on Widget Interface...

[Phillips, Addison]

Hi Art,

No, I don't think it does. While the means by which the (user/system default) 
locale is determined may be implementation dependent, it is still necessary 
that the runtime determine what it is. The Widget interface thus needs to 
provide access to what it is. Otherwise how can the script calling the 
interface determine what language it is getting for the name, shortname, etc.? 
Or what locale the widget is actually using in its runtime? Obtaining this 
would be useful if the script were to request content or data formatting 
remotely (or do so locally using the JavaScript I18N extension that is being 
developed).

Thanks,

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@nokia.com]
> Sent: Thursday, September 30, 2010 6:18 AM
> To: Phillips, Addison
> Cc: public-webapps
> Subject: Re: Comment on Widget Interface...
> 
> 
>   Hi Addison,
> 
> On 9/7/10 6:06 PM, ext Phillips, Addison wrote:
> > Hello Webapps WG,
> >
> > (This is a personal comment and is not necessarily indicative of
> the I18N WG's opinion)
> >
> > In Section 5 (The Widget Interface), the interface provides for
> retrieving values such as 'name', 'shortName', etc. In Widgets P&C,
> these can be localized in the configuration document (I assume that
> the configuration document in this document means the same document
> as P&C??). There is no mention of whether or how this value is
> localized or if the locale/language is subject to programmatic
> control (I assume not, since it is not mentioned).
> >
> > Could there be an explicit mention of the language/locale and how
> it interacts with user-agent? Can/should there be an accessor for
> language? How about a way of querying the value by locale?
> Support for locale was part of the Widget Interface spec but as we
> worked through the localization model for the Packaging and
> Configuration spec, we decided to remove it (at least for this
> version
> of the spec). The Packaging spec includes the gist of the
> rationalization for this decision:
> 
> [[
> http://www.w3.org/TR/widgets/#step-5--derive-the-user-agents-locale
> 
> As there are numerous ways a user agent can derive the end-user's
> preferred languages and regional settings, the means by which those
> values are derived are beyond the scope of this specification and
> left
> up to the implementation.
> ]]
> 
> I suppose one could argue the Widget Interface implies the above
> indirectly (via the reference to P&C spec). However, I don't see
> any
> harm if the above text were copied into the Interface spec. Would
> doing
> so address your concern?
> 
> -Art Barstow
> 
> 

Comment on Widget Interface...

[Phillips, Addison]

Hello Webapps WG,

(This is a personal comment and is not necessarily indicative of the I18N WG's 
opinion)

In Section 5 (The Widget Interface), the interface provides for retrieving 
values such as 'name', 'shortName', etc. In Widgets P&C, these can be localized 
in the configuration document (I assume that the configuration document in this 
document means the same document as P&C??). There is no mention of whether or 
how this value is localized or if the locale/language is subject to 
programmatic control (I assume not, since it is not mentioned).

Could there be an explicit mention of the language/locale and how it interacts 
with user-agent? Can/should there be an accessor for language? How about a way 
of querying the value by locale?

Regards,

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.

RE: [widgets PC] i18n comment 21: i18n string

[Phillips, Addison]

(personal response)

Having case-sensitive file/folder matching is going to lead to frustrated 
authors being unable to figure out why their localizations don't work. If there 
is no way to do case-less matching in the widget engine itself, I think your 
solution is workable. While it would be nice to recommend using the BCP 47 case 
conventions, if you don't, you need to really highlight the casing requirements 
in packaging.

The original point of this editorial comment is that your XML examples should 
show the expected case folding of language tags. While perfectly legal to show 
them as all lowercase, it is just as legal to scream them in uppercase or use 
alternating case or otherwise make them look "odd". By adding a recommendation 
to your document to use the case conventions in BCP 47 (which I see as 
unnecessary), but not using that recommendation in your examples, and then 
having a separate case convention buried elsewhere in your document you risk 
confusion.

I think your text for the "folder based localization" section is good. I would 
put it directly following the first paragraph and I would reword it as follows:

--
Although BCP 47 recommends a particular case-folding convention, the use of 
upper or lowercase letters has no meaning in a language tag. Because folders 
inside a widget package are treated by the user-agent in a case-sensitive 
manner, the names of the folders inside a 'locale' folder MUST be all 
lowercase. All language tags are mapped to lowercase for matching purposes 
(although they can appear in any form in the configuration file or elsewhere).
--

And I would replace your text in "The xml:lang Attribute" section with a 
pointer to the warning above. Perhaps:

--
Although BCP 47 recommends that language tags be casefolded in a particular way 
for presentation, case has no meaning in a language tag. Because user-agents 
map all language tags to lowercase because they treat file names in a 
case-sensitive manner, all examples in this document use lowercase as a 
reminder to authors. See [[folder-based localizations]].
--

Addison 

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core-
> requ...@w3.org] On Behalf Of Marcos Caceres
> Sent: Tuesday, June 29, 2010 7:08 AM
> To: Richard Ishida
> Cc: public-i18n-c...@w3.org; public-webapps@w3.org
> Subject: Re: [widgets PC] i18n comment 21: i18n string
> 
> On Fri, May 28, 2010 at 8:38 AM, Richard Ishida 
> wrote:
> > Comment from the i18n review of:
> > http://dev.w3.org/2006/waf/widgets/
> >
> > Comment 21
> > At http://www.w3.org/International/reviews/0907-widgets-pc/
> > Editorial/substantive: E
> > Tracked by: AP
> >
> > Location in reviewed document:
> > General
> >
> > Comment:
> > Language tags are presented as lowercase. While case has no
> meaning in language tags, they are typically canonicalized (and are
> recommended to use) the case conventions in BCP 47. See
> http://tools.ietf.org/html/bcp47#section-2.1.1
> >
> 
> That is no problem for when language tags appear in xml:lang, as
> they
> are cononicalized to lower-case. However, following BCP 47 would
> cause
> issues with matching folders, as they are treated as case sensitive.
> 
> In the "Folder-based localization" section, I've added the
> following
> to the authoring guidelines:
> 
> "Because folders inside a widget package are treated by the user
> agent
> as case sensitive, the names of the folders inside a locale folder
> need to be in lower-case. Unfortunately, this violates the case
> conventions recommended in BCP 47. "
> 
> In the "The xml:lang Attribute" section of the spec, I've added the
> following to the authoring guidelines:
> 
> "Please note that, while case has no meaning in language tags, it
> is
> recommend that with xml:lang authors use the case conventions
> recommended in BCP 47."
> 
> --
> Marcos Caceres
> Opera Software ASA, http://www.opera.com/
> http://datadriven.com.au

RE: Client side JavaScript i18n API

[Phillips, Addison]

Our (I18N activity) experience seems to suggest that a dedicated list is more 
useful when a project is active. The key thing is to engage in coordination 
between groups at appropriate times (there exist various means of doing that). 

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.

> -Original Message-
> From: c...@google.com [mailto:c...@google.com] On Behalf Of Nebojša
> Ciric
> Sent: Thursday, May 13, 2010 5:35 PM
> To: Doug Schepers
> Cc: Robin Berjon; Phillips, Addison; public-webapps WG; public-
> i18n-c...@w3.org
> Subject: Re: Client side JavaScript i18n API
> 
> Doug,
>  do you think we should create a new list and move this discussion
> there? Or should we use one of the existing i18n lists?
>  If we do move this discussion off the webapps list, we may lose
> some
> audience/expertise...
> 
>  If nobody objects, we (Google) would like to take this discussion
> to
> webkit-dev list too, and maybe start prototyping the Locale API in
> next couple of weeks (both for JSC and V8).
> 
> Regards,
>  Nebojsa Ciric
> 
> On Tue, May 4, 2010 at 8:46 AM, Doug Schepers 
> wrote:
> > Hi, Robin-
> >
> > Robin Berjon wrote (on 4/27/10 12:21 PM):
> >>
> >> On Apr 27, 2010, at 18:13 , Phillips, Addison wrote:
> >>>
> >>> A project to implement this could go quite fast, I think, but
> would
> >>> require agreement by the major browser vendors and a place to
> do
> >>> the work. We could do this at W3C, but I think ECMA should be
> >>> involved from early on.
> >>
> >> In general a good place for discussion that involves W3C/TC39
> >> coordination is public-script-co...@w3.org. It doesn't have an
> >> attached group and therefore cannot publish specifications, but
> >> that's a sausage-making detail that can be handled orthogonally
> (we
> >> just need to find a WG that can justify having this in its
> charter).
> >
> > Actually, public-script-coord is associated with the WebApps WG,
> and was
> > formed to coordinate between TC39 and the WebApps WG,
> specifically on Web
> > IDL issues, but also on other matters of coordination.
> >
> > If we do decide to bring this i18n work to W3C (which I think
> would be a
> > good idea, though not by necessity in the WebApps WG), we could
> reuse
> > public-script-coord, or we could make a new dedicated list.  I
> think the
> > latter makes more sense, since the i18n folks wouldn't have to
> drink from
> > the public-script-coord hose.
> >
> > Regards-
> > -Doug Schepers
> > W3C Team Contact, SVG and WebApps WGs
> >
> >
> 
> --
> Nebojša Ćirić

RE: Client side JavaScript i18n API

[Phillips, Addison]

I agree (and am empowered by the I18N WG to say so). I don’t think we need to 
saddle the I18N efforts with the TC39 process but rather that what we do be 
compatible and consistent with internationalization changes in ES6.0 that TC39 
eventually really *MUST* take up---that we push forward with them appropriately 
and consistently (I’m thinking here more of things like supplementary character 
support, but also that “toLocaleString()” is consistent with how 
internationalization is specified).

A much bigger concern to me is not TC39’s involvement but rather that we get 
the major vendors involved and committed. To that end, I would be happy to help 
chartering efforts within the International Activity (although I18N Core WG 
cannot host this effort directly). Alternatively, the I18N WG supports 
chartering this work as part of Webapps.

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

From: mark.edward.da...@gmail.com [mailto:mark.edward.da...@gmail.com] On 
Behalf Of Mark Davis ?
Sent: Wednesday, April 28, 2010 12:14 PM
To: Phillips, Addison
Cc: Robin Berjon; "Jungshik Shin 
(신정...@poing.nachbaur.com",
 _?= 申政湜)"; marc...@opera.com; Nebojša Ćirić; public-webapps WG; 
public-i18n-c...@w3.org
Subject: Re: Client side JavaScript i18n API

Referring to the process:

Trying to get effective and useful internationalization supported in ECMAScript 
has been a fruitless process (see Markus's memo of some seven or eight years 
ago). It might be possible to get needed changes if one were to spend enough (a 
huge amount of) time with the ECMA committee, but even then, the process will 
take a long time.

A better way would be to develop and standardize API in the W3C (or some other 
suitable venue), aimed at developers who need internationalization on the web 
in a more timely fashion. And in a way, one could view intl as an (important) 
library layered on top of the basic language. We could make sure that ECMA is 
in the loop, and if some of those changes are picked up in ECMAScript later on, 
that wouldn't be so bad (the APIs could just be converted into wrappers at that 
point).

Mark

— Il meglio è l’inimico del bene —

2010/4/27 Phillips, Addison mailto:addi...@lab126.com>>
(personal response)

Speed is a problem with the ECMAScript process. It would probably be several 
years (based on their testimony) before ES 6.0 would be complete. That doesn't 
mean we have to wait for the rest of the 6.0 paint to dry, though. The standard 
can take the form of recognizing what has already been agreed elsewhere.

My concern about making a separate API or part of CommonJS is that there *do* 
exist methods (toLocaleString, sort, etc.) that promise (but do not deliver) 
internationalization in the core. These methods could be extended in a 
backwards compatible fashion and result in a low-learning curve means for 
scripters to get what they need.

A locale facet in the language would also enable developers to rely on the 
locale data being present for development of their own solutions. This could 
reside in CommonJS (along with Time Zone, the other missing bit). The goal 
would be to have universal, consistent support for the syntax (even if, say, 
Microsoft's locale data varies from say Google's).

A project to implement this could go quite fast, I think, but would require 
agreement by the major browser vendors and a place to do the work. We could do 
this at W3C, but I think ECMA should be involved from early on. We have had 
success in the International activity with Task Forces, although we would need 
some chartering work. Webapps might also be a good home for this work.

Addison

Addison Phillips
Globalization Architect -- Lab126
Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: Robin Berjon [mailto:ro...@berjon.com<mailto:ro...@berjon.com>]
> Sent: Tuesday, April 27, 2010 6:49 AM
> To: =?utf-
> 8?q?=22jungshik_shin_=28=ec=8b=a0=ec=a0=95=ec=8b...@poing.nachbaur.
> com; _?= 申政湜)"
> Cc: Phillips, Addison; marc...@opera.com<mailto:marc...@opera.com>; Nebojša 
> Ćirić; public-
> webapps WG; public-i18n-c...@w3.org<mailto:public-i18n-c...@w3.org>
> Subject: Re: Client side JavaScript i18n API
>
> On Apr 27, 2010, at 00:11 , Jungshik Shin (신정식, 申政湜) wrote:
> > Yes, I agree. Now it's not just web sites but also local
> "apps/widgets/browser extensions" written in HTML/JS/CSS are
> affected.
>
> As a side note it's interesting to note that you're taking widgets
> into account, I didn't know you were interested in those.
>
> > First of all, I'm not sure of the wisdom of making a large set of
> i18n APIs (locale, collation, formatting - number, date, message -,
> and  more) a part of 'the language' proper.  Javascript does not

RE: Client side JavaScript i18n API

[Phillips, Addison]

(personal response)

Speed is a problem with the ECMAScript process. It would probably be several 
years (based on their testimony) before ES 6.0 would be complete. That doesn't 
mean we have to wait for the rest of the 6.0 paint to dry, though. The standard 
can take the form of recognizing what has already been agreed elsewhere.

My concern about making a separate API or part of CommonJS is that there *do* 
exist methods (toLocaleString, sort, etc.) that promise (but do not deliver) 
internationalization in the core. These methods could be extended in a 
backwards compatible fashion and result in a low-learning curve means for 
scripters to get what they need.

A locale facet in the language would also enable developers to rely on the 
locale data being present for development of their own solutions. This could 
reside in CommonJS (along with Time Zone, the other missing bit). The goal 
would be to have universal, consistent support for the syntax (even if, say, 
Microsoft's locale data varies from say Google's).

A project to implement this could go quite fast, I think, but would require 
agreement by the major browser vendors and a place to do the work. We could do 
this at W3C, but I think ECMA should be involved from early on. We have had 
success in the International activity with Task Forces, although we would need 
some chartering work. Webapps might also be a good home for this work.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: Robin Berjon [mailto:ro...@berjon.com]
> Sent: Tuesday, April 27, 2010 6:49 AM
> To: =?utf-
> 8?q?=22jungshik_shin_=28=ec=8b=a0=ec=a0=95=ec=8b...@poing.nachbaur.
> com; _?= 申政湜)"
> Cc: Phillips, Addison; marc...@opera.com; Nebojša Ćirić; public-
> webapps WG; public-i18n-c...@w3.org
> Subject: Re: Client side JavaScript i18n API
> 
> On Apr 27, 2010, at 00:11 , Jungshik Shin (신정식, 申政湜) wrote:
> > Yes, I agree. Now it's not just web sites but also local
> "apps/widgets/browser extensions" written in HTML/JS/CSS are
> affected.
> 
> As a side note it's interesting to note that you're taking widgets
> into account, I didn't know you were interested in those.
> 
> > First of all, I'm not sure of the wisdom of making a large set of
> i18n APIs (locale, collation, formatting - number, date, message -,
> and  more) a part of 'the language' proper.  Javascript does not
> have a concept of standard library. If it had, wouldn't everybody
> agree that this should be a part of that library rather than the
> 'language proper'? Javascript does not have that notion. Does it
> mean we can/should add a slew of APIs to 'the language proper'?
> 
> No, I think that we should operate on the assumption that JS's
> standard library is CommonJS and the browser (merging the two to a
> point would be great, but that's another topic). I would think that
> making an API that can work for both shouldn't be excessively hard
> in this case.
> 
> > Secondly, I'm worried about the pace of the language
> standardization process. I have an 'impression' (which may be
> totally off the mark or outdated) that the process is rather slow.
> On the other hand, WebApps WG has been moving fast. We'd like to
> start with a working prototype of a small subset of APIs fairly
> soon and iterate through WG to fix/refine/expand.
> 
> Standards can be fast and they can be slow — it all depends on how
> they're made. IME fast standards depend on:
> 
>   1) Scoping: defining the scope of v1 to be as small as possible
> while still being useful and then being a fascist about it.
>   2) Manpower: writing specifications, answering comments, writing
> tests all take time. More time than you think they will (a standard
> has to be of much higher quality than typical technical
> documentation).
>   3) Implementation & Usage: as tight as possible a feedback loop
> with implementers and developers speeds things up.
> 
> If you have the means to commit all three, you'll probably go
> fast :)
> 
> --
> Robin Berjon - http://berjon.com/
> 
> 

RE: Client side JavaScript i18n API

[Phillips, Addison]

Hi,

I think that Internationalization support in JavaScript has been too long 
overlooked and represents a barrier to development of multilingual web sites.

The Internationalization WG actually approached the ECMASCript folks about 
providing for international support in the JavaScript language. We feel that 
explicit support in the language is important, and the ECMAScript people we met 
with at W3C TPAC 2009 seemed open to our suggestions.

An outline of the requirements we presented to them can be found here:

   http://www.w3.org/International/wiki/JavaScriptInternationalization

Based on our conversation with the ECMA working group, we should be prepared to 
make proposals and work with them on language standardization in the near 
future. If functional implementations can be demonstrated, that would probably 
be helpful as well.

If you would like, I would be happy to devote some time at an upcoming I18N 
Core WG teleconference to discuss this. You might also bring this conversation 
to the www-internatio...@w3.org mailing list.

Regards,

Addison

Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core-
> requ...@w3.org] On Behalf Of Robin Berjon
> Sent: Monday, April 26, 2010 2:55 AM
> To: marc...@opera.com
> Cc: Nebojša Ćirić; public-webapps WG; Jungshik Shin; public-i18n-
> c...@w3.org
> Subject: Re: Client side JavaScript i18n API
> 
> On Apr 26, 2010, at 11:38 , Marcos Caceres wrote:
> > 2010/4/23 Nebojša Ćirić :
> >>  We would like to propose an API for locale-based collation,
> >> date/number formatting, ... Does anybody else think this would
> benefit
> >> the authors?
> >>
> >>  We would be happy to answer questions to what problems are we
> trying
> >> to solve, and how.
> >
> > I think the DAP guys are trying to handle some of this in their
> > Calendar API.
> 
> Hmm no we're not — we're simply looking at ways of handling the
> massive number of different calendars that users could want to use.
> 
> Nebojša: I think that there could be value in the sort of API that
> you describe, but it'd be easier to answer your question if we
> could see it :)
> 
> --
> Robin Berjon - http://berjon.com/
> 
> 
> 

RE: i18n comments:

[Phillips, Addison]

This doesn't make any sense to me. I think you are over-thinking this.

The author element contains the author's *NAME*. It can also include an href 
and an email attribute. UTR#36 refers explicitly to IRIs and IDNA addresses, 
which would be the values of these attributes. However, it does NOT refer to 
plain text (the body of the element 'author') which is what the 'dir' attribute 
really applies to. To not provide bidirectional overrides for the author's name 
strikes me as incredibly short sighted, given that you can override any 
higher-level element. To have one place in your configuration document that 
requires controls is not to improve security, it is to reduce usability.

It would make far more sense for you to cite UTR#36 with regard to an 
implementations presentation of the href or email attributes, suggesting (or 
forbidding) the application of the dir attribute to these values. But the body 
of the  element needs the bidi markup and should not depend on Unicode 
bidi controls.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: Marcos Caceres [mailto:marc...@opera.com]
> Sent: Monday, March 29, 2010 4:35 AM
> To: "Martin J. Dürst"
> Cc: Felix Sasaki; Arthur Barstow; Phillips, Addison; public-i18n-
> c...@w3.org; public-webapps; Richard Ishida
> Subject: Re: i18n comments:
> 
> Hi Martin,
> 
> On 29/03/10 10:01 AM, "Martin J. Dürst" wrote:
> > [comments below]
> >
> > On 2010/03/27 18:49, Marcos Caceres wrote:
> >
> >> Thanks Felix, I will update the schema. However, the BIDI spec
> warns,
> >> for security reasons, to avoid the overrides so I didn't include
> them
> >> into our spec. Should I put lro and rlo into the spec regardless?
> the
> >> spec now contains a note about this in the dir section:
> >>
> >> Note:
> >> Under the guidance of the [BIDI] specification, the values that
> would
> >> allow directional overrides in this specifications, namely Left-
> to-Right
> >> Override (LRO) and Right-to-Left Override (RLO), have
> deliberately been
> >> left out of this specification because of security concerns (see
> >> [UTR36]). Authors wanting to override the [BIDI] algorithm can
> do so by
> >> using [XML] entities and the appropriate Unicode directional
> markers.
> >
> > Reading this note, it seems to make NO sense whatever for me to
> leave
> > out the lro/rlo values. Essentially, the Note tells you that
> there is a
> > security problem that apparently was addressed, and then it goes
> on to
> > tell you how to circumvent the solution. Or did I get something
> wrong?
> 
> Your reading of the note is correct. My intention with excluding
> overrides was to make it slightly harder for authors (so they would
> not
> be used by accident). The spec may benefit from advisory for user
> agents
> - like warning end users if BDOs are used or making a visual
> distinction
> when an override occurs (particularly if they affect URIs).
> 
> I've adapted the following from TR36 as a straw-man, please feel
> free to
> improve:
> 
> "In the case where the BIDI algorithm has been explicitly
> overridden by
> the author, a user agent may use coloring or icons to draw the
> user's
> attention as a means of indicating that there may be a security
> risk
> with the presented content; or more obvious, the user agent may
> display
> an alert dialog describing the issue and requiring user
> confirmation
> before continuing (particularly in cases relating to IRIs); or even
> more
> stringent, a user agent may ignore the use the bidirectional
> overrides
> altogether. Implementers are encouraged to refer to [UTR36] for
> advice
> on dealing with the security risks associated with bi-directional
> text,
> IRIs, and Unicode in general."
> 
> Kind regards,
> Marcos
> 
> --
> Marcos Caceres
> Opera Software

RE: [widgets] dir and span elements

[Phillips, Addison]

> 
> Thanks Addison - and yes, I think this makes a lot of sense for a
> "content"-style spec like HTML, however as the Widgets P&C is a
> configuration document most of which is IRIs, integers and so on
> rather than text content its less of a clear case.
> 

No, I understand and don't disagree. However, there is something to be said for 
making it an attribute of , for example. Then you could have an 
override of directionality only when a given element has a different base 
direction. In the example in the spec [1], consider how this might be cleaner:




But ltr override here works fine.



   Some rtl text.


bidi authors name


...




Compared to:

 


   Some RTL.



   Have to include dir a lot.



   ...



...



I'm not suggesting that 'dir' makes sense everywhere, but there is some utility 
in allowing direction (and maybe language/locale??) in at the outermost element?


> If dir conformance is tested in relation to the Rule For Obtaining
> Text Content then this already scopes its use to the four elements
> mentioned as these are the only elements that the rule applies to.
> 

I agree, but there is one more potential case. The  element could have 
a default base directionality set (each  target or localized 
equivalent might also override it).

I agree that a scoped 'dir' attribute is a pain to deal with 
implementation-wise, so I personally would be open to not doing this. But I 
think it worth considering.

Addison

[1] http://dev.w3.org/2006/waf/widgets/#example-configuration-document

RE: [widgets] dir and span elements

[Phillips, Addison]

Hi Scott,

One reason to make 'dir' available on higher-level elements is that 'dir', like 
'xml:lang', has scope. It is often useful to specify a "base" directionality 
for an entire document or block of elements rather than having to repeat it 
over-and-over on each affected element. I can agree that it might not make 
sense on every element and perhaps we should look at which structural elements 
in P&C make sense as a place to set a base directionality or directionality 
override.

I also agree about making  available inside . In fact, it is 
probably the *most* useful inside the license element.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core-
> requ...@w3.org] On Behalf Of Scott Wilson
> Sent: Monday, March 01, 2010 9:44 AM
> To: marc...@opera.com
> Cc: public-webapps; public-i18n-c...@w3.org
> Subject: Re: [widgets] dir and span elements
> 
> Hi Marcos,
> 
> On 26 Feb 2010, at 17:44, Marcos Caceres wrote:
> 
> > Hi i18n WG,
> > I've added the dir attribute and span elements to the Widgets P&C
> > Specification, as well as a bunch of examples (which are wrong,
> so I
> > would really appreciate some help with these!).
> >
> > The dir attribute is specified here:
> > http://dev.w3.org/2006/waf/widgets/#global-attributes
> >
> > The span element is specified here:
> > http://dev.w3.org/2006/waf/widgets/#the-span-element
> >
> > The processing step that defers to the yet to be written [WIDGET-
> BIDI]
> > specification is defined here:
> > http://dev.w3.org/2006/waf/widgets/#rule-for-getting-text-content
> >
> > The specification makes it mandatory that a user agent implement
> the
> > WIDGET-BIDI spec:
> >
> > "A user agent is an implementation of this specification that
> also
> > supports [XML], [XMLNS], [UTF-8], [DOM3CORE], [SNIFF], [WIDGETS-
> BIDI],
> > and [ZIP]..."
> >
> > We would appreciate your review and any assistance you can
> provide.
> > In particular, we would appreciate your guidance into what would
> go
> > into the Widgets Bidi specification (i.e., how processing is done
> for
> > dir and span). At the moment, we only have the following text for
> such
> > a specification (based on HTML5's bdo element):
> >
> > [[
> > If an element has the dir attribute set to the exact value ltr,
> then
> > for the purposes of the bidi algorithm, the user agent must act
> as if
> > there was a U+202D LEFT-TO-RIGHT OVERRIDE character at the start
> of
> > the element, and a U+202C POP DIRECTIONAL FORMATTING at the end
> of the
> > element.
> >
> > If the element has the dir attribute set to the exact value rtl,
> then
> > for the purposes of the bidi algorithm, the user agent must act
> as if
> > there was a U+202E RIGHT-TO-LEFT OVERRIDE character at the start
> of
> > the element, and a U+202C POP DIRECTIONAL FORMATTING at the end
> of the
> > element.
> >
> > The requirements on handling the span element for the bidi
> algorithm
> > may be implemented indirectly through the style layer.
> > ]]
> 
> I can live with this, with a few comments:
> 
> 1. "dir" is now an (optional?) attribute of every element; however,
> previously its usage was limited to elements that contain human-
> readable text content: , , , and
> .
> Is there a reason for making it global in this manner? E.g. would
> it
> not make more sense to specify "dir" attributes on these four
> specific
> P&C elements? I don't see anyone putting "dir" on (e.g.) the height
> attribute, nor would we want to include a test for it for
> compliance
> with optional spec features.
> 
> 2. "span" should be allowed as a child element of the 
> element as well as for ,  and .
> 
> >
> > Thanks again for all your time and help!
> >
> > Kind regards,
> > Marcos
> > --
> > Marcos Caceres
> > http://datadriven.com.au
> >

RE: [i18n+P&C] IRI/URI normalization

[Phillips, Addison]

Hello Marcin,

Thank you for the note. This is a PERSONAL response.

I immediately spotted some red flags in your email. You state:

> 1. The widget configuration document may contain only US-ASCII
> characters, and thus conform to P&C.

This appears to me to be false. The widget configuration document is defined as 
an XML document. The examples all declare the encoding as UTF-8. See, for 
example [1]. A UTF-8 encoded configuration document can represent any Unicode 
character sequence. For that matter, an XML document can also use numeric 
character entities to represent characters not in the document's character 
encoding and the configuration document could use any valid character encoding 
recognized by the XML processor.

However, you go on to say:

> 4. To use the non-US-ASCII feature-name, I would percent-encode it,
> as e.g. in [2]. (This seems to be the core of the problem, namely
> usage of feature-name specified in one language within the
> configuration document and text editor using another
> language/encoding).

Percent encoding is described in the IRI spec as part of mapping IRIs to URIs. 
If you encode it, you should decode it later. But it is not necessary to 
percent-encode it, even if you use US-ASCII-7 as the character encoding of your 
configuration document. You can use NCRs, for example (these are decoded by the 
XML processor in the WUA).

> Proposed solutions (OR-ed):
> 
> a. Define a rule similar to "10.1.4 Rule for Getting a Single
> Attribute Value" (or a statement in that rule) that would specify
> the IRI/URI normalization according to RFC3987 (section 5.3.2.3).

I would support changing this, although I note that the widget document goes 
out of its way to prohibit URL-encoding (percent encoding) of IRIs. As noted 
above, there are other ways to put non-ASCII path characters into your 
configuration document.

> 
> c. Mandate only UTF-8 encoded configuration documents and disallow
> other encodings (like Shift-JIS, ISO-XY etc).

This would be wrong. It doesn't really solve the problem anyway. The character 
encoding of the serialized XML document is not the limit on the characters that 
can be represented in it, although it might be inconvenient for a lot of NCRs 
to appear in a document.

Please note, I am not recommending that anyone actually use other character 
encodings. I always, personally, recommend that people use UTF-8 for XML. But 
if you need to use a legacy encoding, the spec should not necessarily prevent 
you from doing so.

> 
> d. Mandate only US-ASCII feature-names (probably bad/against
> internationalization).

This I18N WG would certainly object to this.

I hope that helps. The I18N WG will consider this at our next meeting (next 
week).

Kind Regards,

Addison


[1] http://www.w3.org/TR/2009/CR-widgets-20090723/#configuration-document

Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.

RE: [WIDGET PC] i18n comment 6: Use of its:dir

[Phillips, Addison]

(personal response)

> The concerns are that people won't implement ITS 

Saying "we're concerned no one will implement ITS" makes it sound like some 
exotic specification that may not find community support. But plenty of Recs 
have 'dir' and 'span' attributes/elements to allow for proper bidi markup. 
Having ITS define these for you in a conveniently referenced spec is a novelty, 
but shouldn't be used as a reason for "people" to think they "don't need to 
implement it" :-).

I believe that most widget engines can easily implement these features because 
they already leverage the text layout capabilities of a browser, of the host 
operating system, or both and because most JavaScript engines already implement 
Unicode bidi. Setting base direction or directional override from markup is a 
small matter of implementing the parsing---not a total rewrite. If you specify 
it, I believe it can happen.

I recognize that your WG is merely noting that the feature is "at risk". I 
believe the I18N WG would object to its removal and urge the webapps community 
to include bidi support.

> The concerns are that people won't implement ITS (or that authors
> can
> use the appropriate Unicode markers to achieve the same thing as
> ITS).

We have a FAQ about that. In fact, we just announced it a few minutes ago. 
Please see [1] for links.

[1] http://lists.w3.org/Archives/Public/www-international/2009JulSep/0001.html

Best Regards,

Addison

Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.

> -Original Message-
> From: Marcos Caceres [mailto:marc...@opera.com]
> Sent: Friday, July 10, 2009 8:49 AM
> To: Phillips, Addison
> Cc: ish...@w3.org; public-Webapps@w3.org; public-i18n-c...@w3.org
> Subject: Re: [WIDGET PC] i18n comment 6: Use of its:dir
> 
> 
> 
> On 7/10/09 5:40 PM, Phillips, Addison wrote:
> > (personal response)
> >> Fantastic. Unfortunately, implementer feedback has raised
> concerns
> >> about ITS and so the WG has put ITS features "at risk" (and
> marked
> >> as
> >> such in the soon to be released CR spec). We will see what
> happens
> >> in
> >> CR; hopefully implementers will understand the value of
> >> implementing
> >> it.
> >>
> >
> > I noticed that in the transreq. Obviously the I18N WG is
> concerned about any such feedback: can webapps please share what
> the concerns are? I know that many developers consider bidi support
> "kind of scary"; I hope that the implementation issues are not
> simply fear driven. Is there some way that the Internationalization
> community can support implementers?
> >
> 
> The concerns are that people won't implement ITS (or that authors
> can
> use the appropriate Unicode markers to achieve the same thing as
> ITS).
> 
> Kind regards,
> Marcos

RE: [WIDGET PC] i18n comment 6: Use of its:dir

[Phillips, Addison]

(personal response)
> 
> Fantastic. Unfortunately, implementer feedback has raised concerns
> about ITS and so the WG has put ITS features "at risk" (and marked
> as
> such in the soon to be released CR spec). We will see what happens
> in
> CR; hopefully implementers will understand the value of
> implementing
> it.
> 

I noticed that in the transreq. Obviously the I18N WG is concerned about any 
such feedback: can webapps please share what the concerns are? I know that many 
developers consider bidi support "kind of scary"; I hope that the 
implementation issues are not simply fear driven. Is there some way that the 
Internationalization community can support implementers?

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

RE: [WIDGET PC] i18n comment 7: Step not necessary?

[Phillips, Addison]

(personal response)

> 
> The WebApps WG believes that removing the redundant repetitions in
> a
> standardized way may avoid interop issues. Having said that, in the
> latest editors' draft, the rightmost occurrences are removed (as
> suggested above).

Actually, I don't believe that there are interoperability issues to avoid. If 
two identical ranges appear in a language priority list, the second occurrence 
will produce the same results as the first one. If you are processing the 
second one, presumably the result will be no match.

Note that, with the lookup algorithm, this also applies to ranges that are 
prefixes of other ranges. For example, consider the list "en-us-boont,en". The 
second item (en) mirrors the last match attempted with "en-us-boont".

It is an optimization to omit these ranges, but won't change the results.

> 
> Please see for the updated algorithm:
> http://dev.w3.org/2006/waf/widgets/#step-5--derive-the-user-agents-
> locale
> 

Thanks. We'll review it.

Addison

I18N proposals document review...

[Phillips, Addison]

Hello Marcos,

Sorry about the delay in responding to your e-mail of the 16th [1] regarding 
the document at:

  http://dev.w3.org/2006/waf/widgets/i18n.html

Our WG had a bit of a break due to holidays, etc., so we're just now catching 
up. I realize that your WG had a desired date of the 23rd for a response from 
us. However, we're just now getting to it. We definitely will have comments for 
you.

The Internationalization WG expects to send you a complete our review during 
our next teleconference, which is scheduled for 6 May 2009. Please let me know 
if this is inconvenient for you or your WG.

Kind regards,

Addison (for I18N)

Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.

[1] http://lists.w3.org/Archives/Public/public-i18n-core/2009AprJun/0023.html
[2] http://www.w3.org/2009/04/29-core-minutes.html 

RE: Widgets 1.0 Packaging and Configuration: I18N comments...

[Phillips, Addison]

Hi Marcos,

(chair hat OFF)

I share your concern about the processing model, which is why I asked to see 
the document. I think having the design right is key to making the spec 
successful.

I'll take a look at your documents below and send comments along. What you're 
struggling with here is not unusual and, in fact, there are different views on 
the best methodology and approach. See, for example, the myriad (competing) 
ways of localizing a J2EE application :-).

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: Marcos Caceres [mailto:marc...@opera.com]
> Sent: Friday, April 03, 2009 8:03 AM
> To: Phillips, Addison
> Cc: public-i18n-c...@w3.org; public-webapps@w3.org
> Subject: Re: Widgets 1.0 Packaging and Configuration: I18N
> comments...
> 
> Hi Addison,
> 
> On Fri, Apr 3, 2009 at 4:38 PM, Phillips, Addison
>  wrote:
> > Hello Webapps,
> >
> > Thanks for the response. Is there is a new draft or editor's copy
> where these changes are made?
> 
> Yes, see [1]; but we are still working out the details. As this
> change
> caused some radical changes in the spec, I am still working out how
> to
> make the processing model work. I'm currently working on a separate
> document that outlines the complete solution for discussion [2]. I
> can
> send it to i18n for discussion once I'm done writing it. I would
> prefer to have consensus on a solution before I add anything else
> to
> the spec.
> 
> Kind regards,
> Marcos
> 
> [1] http://dev.w3.org/2006/waf/widgets/
> [2] (unfinished draft!)
> http://dev.w3.org/2006/waf/widgets/i18n.html
> --
> Marcos Caceres
> http://datadriven.com.au

RE: Widgets 1.0 Packaging and Configuration: I18N comments...

[Phillips, Addison]

Hello Webapps,

Thanks for the response. Is there is a new draft or editor's copy where these 
changes are made?

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -Original Message-
> From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core-
> requ...@w3.org] On Behalf Of Marcos Caceres
> Sent: Friday, April 03, 2009 2:34 AM
> To: public-i18n-c...@w3.org
> Cc: public-webapps@w3.org
> Subject: Re: Widgets 1.0 Packaging and Configuration: I18N
> comments...
> 
> Hi i18n core,
> 
> On Sun, Feb 22, 2009 at 11:28 PM, Marcos Caceres
>  wrote:
> > On Thu, Jan 29, 2009 at 10:56 PM, Phillips, Addison
>  wrote:
> >> 2. Section 7.4 (Widget) The various language bearing elements
> such as , , etc. are of the zero-or-one type.
> However, it is typically better to allow any number of these
> elements to occur, provided that none share the same xml:lang. This
> allows for localization (which is part of the point in allowing
> xml:lang on the element).
> >>
> >
> > We followed "Best Practice 12: Working with multilingual
> documents" in
> > Best Practices for XML Internationalization [1], where it says we
> > should have different documents for this kind of localization (to
> > achieve what you propose, we allow multiple configuration
> documents in
> > a widget).
> >
> > Does i18n core recommend we drop allowing multiple configuration
> > documents and use xml:lang in multiple elements in the manner
> > suggested above? We have built a lot infrastructure around the
> current
> > model in the spec, so if it's all the same we would prefer to
> keep it.
> >
> Given your feedback, in the packaging spec, we have moved to only
> using a single config.xml file located at the root of the widget.
> We
> have added the following rules, as per the example below. Assume
> the
> UA's locale is "en-us":
> 
> http://www.w3.org/ns/widgets";>
>
>   This element would be used.
>
> 
>
>   This element would be ignored because it is not
>   the first element of that has an xml:lang attribute
>   with the value "en".
>
> 
>
>   This element would be used if the user agent's
>   locale does not match any localized description
>   elements.
>
> 
> 
> Kind regards,
> Marcos
> 
> --
> Marcos Caceres
> http://datadriven.com.au

RE: [selectors-api] Selectors API I18N Review...

[Phillips, Addison]

Not having written it just yet... :-)

Assuming for a moment that CSS3 does not resolve the problem with Unicode 
normalization in selectors, users of selectors-api will be potentially 
surprised by the results in certain circumstances involving denormalized 
selectors. Implementers will also benefit by not getting stuck on test cases 
that involve normalization.

The text would probably be something like:

--
CSS3 Selectors do not provide for Unicode Normalization of either the selector 
expression or elements and text in the document tree being selected from. 
Queries and content must use a consistent character sequence in order for the 
selection to work properly. Some systems do not use the recommended Unicode 
Normalization Form C (NFC) for input or for data storage, and this is 
especially true for certain languages that customarily use Unicode combining 
characters. This may lead to selectors that are visually-and-semantically 
equivalent to parts of the tree not producing an expected match. For more 
information see:

  CharMod-Norm
  Unicode Annex #15 
--

Does that help?

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: Lachlan Hunt [mailto:lachlan.h...@lachy.id.au]
> Sent: Friday, January 30, 2009 3:16 PM
> To: Phillips, Addison
> Cc: public-webapps@w3.org; public-i18n-c...@w3.org
> Subject: Re: [selectors-api] Selectors API I18N Review...
> 
> Phillips, Addison wrote:
> > However, I18N feels that our two WGs can construct a useful,
> > informative, small, and relatively-painless bit of text to allow
> you
> > to proceed. Please let us know if you think this an appropriate
> way
> > to address this issue or if we can assist in any way to help you
> guys
> > out.
> 
> I'm willing to consider any proposal that the i18n WG comes up with.
> But in the mean time, it would useful if you could clarify the
> issue for
> me by providing a rough indication of what kind of information you
> intend the not to convey, and the audience (i.e. authors,
> implementers,
> other?) that it intends to benefit.  This will then allow me to
> more
> easily evaluate and potentially tweak the proposal when it comes.
> 
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/

RE: [selectors-api] Selectors API I18N Review...

[Phillips, Addison]

Hello Lachlan and Webapps-WG,

In our most recent teleconference [1], the Internationalization Core WG 
discussed the issue with normalization in Selectors-API. I'm sure you're 
already aware of the rapidly growing thread about normalization in CSS3 that 
resulted from our comments. Obviously this hasn't been resolved yet.

In our call, I was delegated to write to your WG officially endorsing my 
previous comments (below), as well as to propose to our WG a "health warning" 
such as I suggested. Obviously, if CSS-WG addresses normalization this may 
affect the outcome of our discussion with webapps. However, I18N feels that our 
two WGs can construct a useful, informative, small, and relatively-painless bit 
of text to allow you to proceed. Please let us know if you think this an 
appropriate way to address this issue or if we can assist in any way to help 
you guys out.

Kind Regards,

Addison

[1] http://www.w3.org/2009/01/28-core-minutes.html#action06

Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core-
> requ...@w3.org] On Behalf Of Phillips, Addison
> Sent: Tuesday, January 27, 2009 10:40 AM
> To: Lachlan Hunt
> Cc: public-webapps@w3.org; public-i18n-c...@w3.org
> Subject: RE: [selectors-api] Selectors API I18N Review...
> 
> (This is a personal response)
> 
> Hi Lachlan,
> 
> I didn't expect any other response from you, really.
> 
> At a minimum, I think we would expect a health warning or warnings
> in the API spec, since Selectors themselves don't address the issue.
> Our WG could recommend some appropriate text that is not too dire-
> looking.
> 
> 
> > While I understand that the
> > CSSWG have not yet adequately addressed the i18n issues in their
> > spec, there's nothing I can do to resolve that.
> 
> I recognize that. For reasons I won't go into here, I note that
> lack of maturity in CSS3 doesn't block your advancement. But
> advancing your document without the issue being resolved might lead
> to a "de facto" standard that is hard to overturn/undo.
> 
> > I could not define any normalisation in this spec without
> > indirectly
> > affecting how selectors work in other specs that use them, like
> CSS.
> 
> I agree. But my concern looks something like:
> 
> - You publish; various interoperable implementations are created
> which do not address Unicode normalization. Normalization is not
> addressed, since CSS3 hasn't dealt with it yet.
> 
> - CSS3 later decides to address normalization. One of two outcomes
> is possible:
> 
>a. Defining normalization breaks the extant implementations;
> tough luck for the implementers.
>b. Everyone pretends that normalization isn't somehow important;
> tough luck for users.
> 
> We've been living in "world (b)" for some time now. The situation
> is becoming less pretty as more languages that use combining marks
> and compatibility forms come into common usage on the Web. So, as I
> said, I think it likely that our WG will want to help you advance
> in some useful (non-blocking) way. Our next meeting is tomorrow, so
> look for a formal response from us shortly.
> 
> Kind Regards,
> 
> Addison
> 
> Addison Phillips
> Globalization Architect -- Lab126
> Chair -- W3C Internationalization WG
> 
> Internationalization is not a feature.
> It is an architecture.
> 
> 
> > -Original Message-
> > From: Lachlan Hunt [mailto:lachlan.h...@lachy.id.au]
> > Sent: Tuesday, January 27, 2009 9:39 AM
> > To: Phillips, Addison
> > Cc: public-webapps@w3.org; public-i18n-c...@w3.org
> > Subject: Re: [selectors-api] Selectors API I18N Review...
> >
> > Phillips, Addison wrote:
> > > I am writing on behalf of the I18N Core WG who discussed the
> > > Selectors API WD in our call of 3 December [1].
> > >
> > > We reviewed the Selectors API working draft. In reviewing this
> > draft,
> > > we did not find any internationalization issues in the text of
> > the
> > > document. However, we would like to point out that the CSS3
> > Selectors
> > > themselves have outstanding internationalization comments not
> > > addressed in the current version of that document [4] and which
> > would
> > > (we think) impact anyone who were to implement the Selectors
> API.
> > Our
> > > comments on CSS3 Selectors are located at [2]. We also note
> that
> > > Unicode Normalization is not treated anywhere in this draft o

Widgets 1.0 Packaging and Configuration: I18N comments...

[Phillips, Addison]

Dear Webapps WG,

The Internationalization Core WG has reviewed the following document: 
http://www.w3.org/TR/2008/WD-widgets-20081222/

Here are our comments:

1. In section 7, starting in 7.3 and encompassing each of the text bearing 
elements that follow, "xml:lang" is defined as an attribute (good!), but the 
definition refers to "basic language range". I don't believe this is what is 
intended. The value of xml:lang is a language tag. Ranges are used for 
selecting which tagged item to display. For example, an item tagged as  might be selected for display in cases where the default locale 
is "pt-BR". In that example, "pt-BR" is the range and "pt" is the value (tag) 
matching it.

2. Section 7.4 (Widget) The various language bearing elements such as , 
, etc. are of the zero-or-one type. However, it is typically 
better to allow any number of these elements to occur, provided that none share 
the same xml:lang. This allows for localization (which is part of the point in 
allowing xml:lang on the element).

3. Section 7.11 (content element). The charset attribute "assumes" UTF-8 if 
charset is not present. Note that if the encoding isn't UTF-8, this can almost 
always be detected reliably and an error can be generated (or some other 
fallback assumed). Probably the best pattern would be:

  - if charset is present, use that encoding
  - if charset is absent, check if it is UTF-8
  - if not UTF-8, assume Cp437 (or ISO 8859-1 if that's more appropriate)

4. Section 7.15 (ITS tags). Thank you for including ITS support and support for 
Bidi in particular.

Kind Regards (for I18N),

Addison

Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.

RE: [selectors-api] Selectors API I18N Review...

[Phillips, Addison]

(This is a personal response)

Hi Lachlan,

I didn't expect any other response from you, really.

At a minimum, I think we would expect a health warning or warnings in the API 
spec, since Selectors themselves don't address the issue. Our WG could 
recommend some appropriate text that is not too dire-looking.


> While I understand that the
> CSSWG have not yet adequately addressed the i18n issues in their
> spec, there's nothing I can do to resolve that.

I recognize that. For reasons I won't go into here, I note that lack of 
maturity in CSS3 doesn't block your advancement. But advancing your document 
without the issue being resolved might lead to a "de facto" standard that is 
hard to overturn/undo.
 
> I could not define any normalisation in this spec without
> indirectly
> affecting how selectors work in other specs that use them, like CSS.

I agree. But my concern looks something like:

- You publish; various interoperable implementations are created which do not 
address Unicode normalization. Normalization is not addressed, since CSS3 
hasn't dealt with it yet.

- CSS3 later decides to address normalization. One of two outcomes is possible:

   a. Defining normalization breaks the extant implementations; tough luck for 
the implementers.
   b. Everyone pretends that normalization isn't somehow important; tough luck 
for users.

We've been living in "world (b)" for some time now. The situation is becoming 
less pretty as more languages that use combining marks and compatibility forms 
come into common usage on the Web. So, as I said, I think it likely that our WG 
will want to help you advance in some useful (non-blocking) way. Our next 
meeting is tomorrow, so look for a formal response from us shortly.

Kind Regards,

Addison

Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: Lachlan Hunt [mailto:lachlan.h...@lachy.id.au]
> Sent: Tuesday, January 27, 2009 9:39 AM
> To: Phillips, Addison
> Cc: public-webapps@w3.org; public-i18n-c...@w3.org
> Subject: Re: [selectors-api] Selectors API I18N Review...
> 
> Phillips, Addison wrote:
> > I am writing on behalf of the I18N Core WG who discussed the
> > Selectors API WD in our call of 3 December [1].
> >
> > We reviewed the Selectors API working draft. In reviewing this
> draft,
> > we did not find any internationalization issues in the text of
> the
> > document. However, we would like to point out that the CSS3
> Selectors
> > themselves have outstanding internationalization comments not
> > addressed in the current version of that document [4] and which
> would
> > (we think) impact anyone who were to implement the Selectors API.
> Our
> > comments on CSS3 Selectors are located at [2]. We also note that
> > Unicode Normalization is not treated anywhere in this draft or in
> > CSS3 Selectors.
> 
> I'm not sure how I can address this issue.  While I understand that
> the
> CSSWG have not yet adequately addressed the i18n issues in their
> spec,
> there's nothing I can do to resolve that.
> 
> Since this API defers all processing requirements for selectors to
> the
> selectors spec (with the exception of trimming whitespace), it is
> the
> responsibility of selectors to deal with Unicode normalisation
> issues.
> I could not define any normalisation in this spec without
> indirectly
> affecting how selectors work in other specs that use them, like CSS.
> 
> > We are concerned that changes in CSS3 might impact implementation
> of
> > Selectors API and/or the text thereof and think our concerns
> probably
> > should be addressed before Selectors API advances to the next
> level
> > of maturity.
> 
> I do not believe the limitations of Selectors can have a direct
> impact
> implementation of this API.
> 
> This is the last issue I need to address before asking to have this
> spec
> proceed to CR, so I would like to be able to resolve it as quickly
> and
> as easily as possible.  If you have any proposals as to how exactly
> I
> can address it, I will certainly try and do so.
> 
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/

[selectors-api] Selectors API I18N Review...

[Phillips, Addison]

Dear Webapps WG,

I am writing on behalf of the I18N Core WG who discussed the Selectors API WD 
in our call of 3 December [1].

We reviewed the Selectors API working draft. In reviewing this draft, we did 
not find any internationalization issues in the text of the document. However, 
we would like to point out that the CSS3 Selectors themselves have outstanding 
internationalization comments not addressed in the current version of that 
document [4] and which would (we think) impact anyone who were to implement the 
Selectors API. Our comments on CSS3 Selectors are located at [2]. We also note 
that Unicode Normalization is not treated anywhere in this draft or in CSS3 
Selectors.

Please note that members of the WG also found two minor editorial issues [3]

We are concerned that changes in CSS3 might impact implementation of Selectors 
API and/or the text thereof and think our concerns probably should be addressed 
before Selectors API advances to the next level of maturity.

Regards (for I18N Core),

Addison

[1] http://www.w3.org/2008/12/03-core-minutes.html
[2] http://www.w3.org/International/reviews/0601-css3-selectors/ 
[3] http://lists.w3.org/Archives/Member/member-i18n-core/2008Dec/0006.html 
[4] http://www.w3.org/TR/css3-selectors/ aka 
http://www.w3.org/TR/2005/WD-css3-selectors-20051215 

Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization Core WG

Internationalization is not a feature.
It is an architecture.

RE: Widget Requirements feedback

[Phillips, Addison]

Hi,

I have just now reviewed all of your responses again and am satisfied (within 
the limits of what you can reasonably do, especially wrt the Zip limitations 
:-)). Thanks for working with us on this.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: Marcos Caceres [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 14, 2008 12:19 PM
> To: Felix Sasaki
> Subject: Re: Widget Requirements feedback
> 
> Hi Felix,
> Any update on getting approval from the i18n-wg on the Widgets Reqs
> changes? Our second LC period is now over and we would really
> appreciate i18n's response so we can progress the document forward.
> Kind regards,
> Marcos
> 

FW: Widgets i18n feedback

[Phillips, Addison]

Hi,

This note is on behalf of the I18N Core WG. The comments (below) that I sent to 
members of your WG previously have been endorsed by the I18N Core WG [1], with 
the following additional comments:

1. In my comment #3 below, we would strongly prefer the second suggested 
paragraph (MUST rather than SHOULD).

2. In my comment #15 below, we feel that it would be best if the charset 
parameter were required (MUST) and think that it should at least be strongly 
recommended (via the SHOULD keyword).

Finally, (this comment is personal and not yet endorsed by I18N-WG), I note 
that the text in [2] still has a few flaws (this is "Step 6"), as it is 
confusing and doesn't really describe the lookup algorithm cleanly. There first 
two paragraphs are fine, but the remainder I would suggest changing to read 
(notes on changes follow //):

--
The algorithm to determine the base URI and widget locale are as follows:

   1. If the lang-priority-list is empty, or null, or i-default, or contains a 
single *, or is a sequence of items that only contain the * character, then 
terminate this algorithm and attempt to locate the configuration document. 
// deleted the 'default' keyword
   2. For each range in the lang-priority-list:
 a. If this range is a single *, then terminate this algorithm and 
attempt to locate the configuration document. 
// dropped "and this is the first subtag in the l-p-l"
 b. Else if this range begins with the subtag '*', then skip this range 
and, skipping all the steps below, repeat this step 2. 
 c. Else if this range contains a subtag "*", remove the "*" and its 
preceding hyphen and continue. For example, "en-*-US" becomes "en-US".
// skip ranges that start with *, which are indeterminate
 d. Case-insensitively compare the range to each file name field for 
each file entry that is a folder in the widget resource.
i. If they match:
   1. Let widget locale be the name of the folder that matched the 
current range in lowercase form.
   2. Let base URI be an absolute URI reference to this same folder.
   3. Terminate this algorithm and attempt to locate the 
configuration document
ii. Else, remove the last subtag of the range and repeat this step 
2d. For example, if the range is currently "en-US", make the range "en".
   3. If no match is made, attempt to locate the configuration document.

For example, if the range is "en-AU" and a match is made on file entry whose 
name is "en-au/config.xml", then base URI would be 
"widget://f81d4fae-7dec-11d0-a765-00a0c91e6bf6/en-au", and the widget locale 
would be "en-au".

For example, if the language priority list is "de-CH,fr-CH,it-CH" and folders 
included "de", "fr-FR" , and "IT", then the folder "de" would be matched, then 
base URI would be "widget://f81d4fae-7dec-11d0-a765-00a0c91e6bf6/de"and the 
widget locale would be "de".


--



[1] http://www.w3.org/2008/07/23-core-minutes.html#item04
[2] http://dev.w3.org/2006/waf/widgets/#widget12


Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization Core WG

Internationalization is not a feature.
It is an architecture.


-Original Message-
From: Phillips, Addison 
Sent: Thursday, July 10, 2008 2:02 PM
To: [EMAIL PROTECTED]
Cc: Marcos Caceres; Arthur Barstow; Felix Sasaki; [EMAIL PROTECTED]
Subject: RE: Widgets i18n feedback

Hi,

My personal comments on the Widgets specs located at [1] follow. I have copied 
a few members of the WebApps WG on this message so they can see progress; these 
comments will be a Topic in our next teleconference, for consideration as the 
Internationalization WG's official comments. 

Comments follow.

First, the requirements document:

1. In the introduction we see the (much better) comment:

--
As argued by the Widget Landscape  document, there is currently no formally 
standardized way to author, package, digitally sign and internationalize a 
widget resource for distribution and deployment on the Web.
--

The widget-land document focuses on localization of widgets, which is 
important. This document should provide a solution to the above and this should 
be referred to as "localization". Internationalization remains a problem 
because JavaScript has no locale facet. Internationalized formatting and 
processing is only possible as long as one is happy with the default system 
locale and formats on the host platform. Note: this is usually less of a 
problem for widgets than for AJAX style interactions in a Web page, since most 
widgets are perceived as applications running locally, whereas most Web 
properties manage the user language/locale themselves and need a locale in JS 
to "do the right thing".

2.