[widgets] Widgets i18n feedback

Comments on the Widgets specs from Addison Phillips of the I18N Core  
WG ...

Begin forwarded message:

> From: "ext Phillips, Addison" <addison@amazon.com>
> Date: July 10, 2008 5:01:50 PM EDT
> To: "public-i18n-core-comments@w3.org" <public-i18n-core@w3.org>
> Cc: Marcos Caceres <marcosscaceres@gmail.com>, Arthur Barstow  
> <Art.Barstow@nokia.com>, Felix Sasaki <fsasaki@w3.org>,  
> "mike@w3.org" <mike@w3.org>
> 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. [R5] "For example, addressing a resource via an IRI (e.g. new  
> Image('../images/pane.png'))."
>
> The use of IRI here is good to see.
>
> 3. [R6] Multilingual Resource Names. The current text is not really  
> as strong as I'd like it to be (as you probably would suspect). I'm  
> also not sure that it's quite correct. The current text reads:
>
> --
> A conforming specification SHOULD recommend a packaging format that  
> is suitable for multilingual contexts, giving authors the ability  
> to name files and directories using characters from the Unicode  
> character repertoire; in such a case, a conforming specification  
> SHOULD recommend the UTF-8 encoding.
> --
>
> Keeping the same "strength" of requirement, I would probably phrase  
> this as:
>
> --
> A conforming specification SHOULD recommend a packaging format that  
> allows for non-ASCII characters in file and directory names,  
> allowing authors to create widgets suitable for various cultures  
> and languages, as well as multilingual contexts. The packaging  
> format MUST either provide for a declaration of the character  
> encoding used or specify what it is. The UTF-8 character encoding  
> SHOULD be either the default (if multiple encodings are allowed) or  
> sole encoding used.
> --
>
> It would be far better to strongly require encoding support:
>
> --
> A conforming specification MUST declare the character encoding of  
> file and directory names used in the packaging format and SHOULD  
> use the UTF-8 character encoding. If the UTF-8 encoding is not  
> used, the specific encoding MUST either be specified by the  
> packaging format or be specifiable in the package itself. Since  
> packaged widgets are widely distributed, variation in character  
> encoding between different platforms or configurations may render a  
> widget with non-ASCII resources inoperable or otherwise degrade the  
> user experience unless a comment character encoding is used.
> --
>
> 4. [R7] Internationalization guidelines. Really this should be  
> "localization guidelines", since internationalization support is  
> not really dealt with anywhere.
>
> 5. [R14] Authorship and Widget Metadata. Note that the author's  
> name, email, and organization can all be non-ASCII values.
>
> Next document: [1a]
>
> 6. "File and Folder names". This section contains the following text:
>
> --
> Author requirements: The zip relative path must be encoded as  
> either [CP437] or [UTF-8]. Encoding the file name field using  
> [UTF-8] is recommended. If the zip relative path is encoded using  
> [UTF-8], then the general purpose bit 11 of the local file header  
> must  be set to 1, otherwise it must be set to 0.
> --
>
> This is good (and addresses my comment 3).
>
> 7. (same section). The text says:
>
> --
> Author requirements: It is recommended that authors keep their path  
> lengths below 255 characters. Having excessively long path names  
> (eg. over 120 characters) can also result in interoperability  
> issues on some operating systems.
> --
>
> I'm pretty sure you do not mean "characters" here. You probably  
> mean "bytes", since that is the limitation on some operating  
> environments. In a multibyte encoding, such as UTF-8, this means  
> that there may be fewer than 255 characters in a 255 byte sequence  
> (as few as 63 in the worst case). Please use the word "bytes" here  
> if that is what is meant and include a note along the lines of:  
> "Note that a character can require more than one byte to encode,  
> making the length of the path in characters less than 255."
>
> 8. [non-i18n] I think you mean to s/260/255 in this note:
>
> Note for implementers: as this specification does not put a  
> restriction on path length, implementers need to be prepared to  
> deal with path lengths longer than 260 characters.
>
> 9. [non-i18n] The "valid zip relative path" ABNF is flawed. It has  
> a production called 'ascii-chars', but both utf8-chars and cp437- 
> chars use 'ascii-range' instead.
>
> 10. Section 6. The example has no language attributes, non-ASCII,  
> or IRI-style values. Probably this example is fine, but it is  
> always nice to see examples that use international capabilities.
>
> 11. "Attribute Values and Types". Put quotes around the example  
> numbers to make clear where they are. Some cultures use comma as a  
> decimal separator and it will be clearer what your examples are if  
> you do this.
>
> 12. "URI attribute" You specify BOTH URI and IRI here. And you  
> specify path as being strictly URI (3986). But elsewhere you  
> consistently use the term IRI. Even more confusingly, the word  
> "token" doesn't even appear in 3986 and appears only once (in  
> another context) in 3987. I think you should specify the specific  
> format, preferably IRI.
>
> 13. The "name" and "description" elements (6.5, 6.6). Here are  
> human readable strings with no xml:lang. You should allow an  
> xml:lang on these elements. Ideally, you should permit multiple  
> descriptions (at least) in multiple languages. These elements are  
> often displayed in widget management environments (before the  
> widget is invoked or running).
>
> 14. The "author" element (and its attributes) (6.7) The uri and  
> email attributes should both be of the IRI-flavor, although non- 
> ASCII email names are currently controversial.
>
> 15. The "content" element (6.11) The default 'type' is "text/html"  
> with no charset. It would be better if the default included a  
> charset. The 'src' attribute uses the word "URI", where you should  
> say "IRI".
>
> 16. Section 7. "widget locale". This is specified as:
>
> --
> widget Locale
>     The system locale as an RFC3066 language code (eg. en-us)
> --
>
> This should say "The system locale as a BCP 47 language tag (e.g.  
> en-US or zh-Hant-TW)"
>
> 17. In this same section, "rules for getting text content": I  
> notice that any bidi markup will be removed.
>
> 18. General observation: there is no way to set base directionality  
> (for bidi text) on any of the description/name/etc. elements or for  
> the widget overall. This may make some bidi languages (Arabic,  
> Hebrew, Urdu, etc.) work poorly in a widget.
>
> ===
>
> That's it for now.
>
>
> Best Regards,
>
> Addison
>
>
> [1] http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/
>     [a] http://www.w3.org/TR/widgets/
>
>
> Addison Phillips
> Globalization Architect -- Lab126
>
> Internationalization is not a feature.
> It is an architecture.
>
>> -----Original Message-----
>> From: Michael(tm) Smith [mailto:mike@w3.org]
>> Sent: Wednesday, July 09, 2008 8:10 PM
>> To: Phillips, Addison; Addison Phillips
>> Cc: Marcos Caceres; Arthur Barstow; Felix Sasaki
>> Subject: Re: Widgets i18n feedback
>>
>> Addison,
>>
>> We really need to get your input on this by the week of July 28 at
>> the latest.
>>
>>   --Mike
>>
>> Marcos Caceres <marcosscaceres@gmail.com>, 2008-07-01 11:41 +1000:
>>
>>> Hi Addison,
>>> I'm just wondering if you could give us an ETA on the i18n input
>> for the
>>> Widget spec?
>>> Kind regards,
>>> Marcos
>>
>> --
>> Michael(tm) Smith
>> http://people.w3.org/mike/
>> http://sideshowbarker.net/