Re: [widgets] Packaging Configuration 1.0 pre-CfC comments
On Mon, Dec 15, 2008 at 10:08 AM, SUZANNE Benoit RD-SIRP-ISS benoit.suza...@orange-ftgroup.com wrote: In vista sidebar also, the root folder is used without any specific intermediate folder name, and this can become very messy. For this reason I would advocate for the intermediate folder. I think we should push for the i18n naming as, even if it sounds a bit geeky, it is becoming a standard in the javascript frameworks, and using something else will introduce confusion. Can you please point me which frameworks are using i18n as a folder to contain localized content? -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Packaging Configuration 1.0 pre-CfC comments
Hi Marcos, On 12.12.2008 19.58, ext Marcos Caceres marcosscace...@gmail.com wrote: If people want to suggest a different name for the localized folder, I'm Ok with that. I'll codify this into the spec today. Seems that the z in the string 'localized' personally insults my fellow Australian countrymen and the whole of the British nation. To avoid further offense, I've used the string i18n as the name of the container of localized content instead. So now we get: i18n/en/, i18n/pt/, i18n/es-ar/ and so on... Hopefully this does not offend any other groups and defuses this international crisis:) I was going to point that out, but you beat me to it... Somehow I knew the 'z' was going to be a problem. :) Personally, however, I think 'i18n' is not so great, as it is just too clever, and makes people do a double take. You mentioned that Apple and Yahoo widgets use 'resources', although based on [1] I don't see that happening (in Dashboard widgets the language specific directories are at the root level; in Mac OS X native apps they are in 'Contents/Resources' inside the bundle). Anyway I don't see a big problem there, because these are files used by widgets after all, they're just organized in directories by language tag. If not 'resources', here are more suggestions: 'res', 'global', 'lang', 'languages', 'local', 'locales'. --Jere [1] http://developer.apple.com/documentation/appleapplications/conceptual/Dashbo ard_ProgTopics/Articles/Localization.html
Re: [widgets] Packaging Configuration 1.0 pre-CfC comments
In vista sidebar also, the root folder is used without any specific intermediate folder name, and this can become very messy. For this reason I would advocate for the intermediate folder. I think we should push for the i18n naming as, even if it sounds a bit geeky, it is becoming a standard in the javascript frameworks, and using something else will introduce confusion. Benoit Suzanne benoit.suza...@orange-ftgroup.com From: Jere Kapyaho jere.kapy...@nokia.com Date: Mon, 15 Dec 2008 10:32:10 +0200 To: Marcos CACERES marcosscace...@gmail.com, public-webapps public-webapps@w3.org Subject: Re: [widgets] Packaging Configuration 1.0 pre-CfC comments Resent-From: public-webapps@w3.org Resent-Date: Mon, 15 Dec 2008 08:33:18 + Hi Marcos, On 12.12.2008 19.58, ext Marcos Caceres marcosscace...@gmail.com wrote: If people want to suggest a different name for the localized folder, I'm Ok with that. I'll codify this into the spec today. Seems that the z in the string 'localized' personally insults my fellow Australian countrymen and the whole of the British nation. To avoid further offense, I've used the string i18n as the name of the container of localized content instead. So now we get: i18n/en/, i18n/pt/, i18n/es-ar/ and so on... Hopefully this does not offend any other groups and defuses this international crisis:) I was going to point that out, but you beat me to it... Somehow I knew the 'z' was going to be a problem. :) Personally, however, I think 'i18n' is not so great, as it is just too clever, and makes people do a double take. You mentioned that Apple and Yahoo widgets use 'resources', although based on [1] I don't see that happening (in Dashboard widgets the language specific directories are at the root level; in Mac OS X native apps they are in 'Contents/Resources' inside the bundle). Anyway I don't see a big problem there, because these are files used by widgets after all, they're just organized in directories by language tag. If not 'resources', here are more suggestions: 'res', 'global', 'lang', 'languages', 'local', 'locales'. --Jere [1] http://developer.apple.com/documentation/appleapplications/conceptual/Dashbo ard_ProgTopics/Articles/Localization.html
[widgets] Packaging Configuration 1.0 pre-CfC comments
Hi Marcos, finally I got the chance to read the Widgets 1.0 Packaging Configuration spec. Great work there; please accept some comments based on the Editor's Draft 7 December 2008 version, up at [1]. 5.3 Zip Relative Paths The ABNF needs some polishing: - Rule names like cp437 vs. cp437-chars, utf8-range vs. utf8-chars, ascii-range vs. ascii-chars. - ABNF rules are case-insensitive as per RFC 5234 [2]; does this affect the Language-Tag rule in any way? - delimiter should be %x2F or just / for readability - In cp437-chars, should say %x80-FF (and no semicolon) - s/is define in/is defined in/ 5.4 Reserved characters - Minor issue with the table of reserved characters: the Unicode code points column would be better labeled Unicode character and be made the first column. The CP437 column is redundant, IMHO. The column Character representation could be just Representation or Representative glyph. - Are filenames of ZIP entries case-sensitive or not? The ZIP spec does not seem to say (or I missed it), but the PC spec has several recommendations about case. 6.4 Content localization - Note that since localized folders now must reside in the root of the widget package, they pollute the root namespace, and it is possible to (more or less accidentally) have a normal folder whose name is a valid BCP47 language tag. In essence, all valid BCP47 language tags would have to be treated as reserved. Should the localized folders instead be placed one level down from the root, inside folder 'X', where 'X' is a suitable reserved name like 'resources'? - If there ever is a case of the WUA having to iterate all the localized folders, I think it's going to be difficult or impossible to find them all. We had this problem in JSR 238 [3], and ended up having a metadata entry that lists the supported locales. It can be generated by a widget packaging tool. Not ideal, but beats a combinatorial explosion... :) Or maybe you envision that the lang-priority-list removes the need to iterate? 6.5 Start file and Default Start Files See Step X for instructions of how to find the default start file. -- here X should probably be 9. 8. Steps for Processing a Widget Resource Step 6 - Determine the base folder and widget locale - Algorithm step 2.d.i.2 seems to be missing something (Let base folder .). - Algorithm step 2.d.ii refers to this step 2.4. References - ZIP file spec: seems to be revised from time to time, would it be good to freeze the reference to a particular version? - Might want to fill in the HTTP, URI, ABNF etc. references before formal publication. BTW, did you already get someone to volunteer to do it? I'll help if not too late. - Make all the URIs also links (like BCP47). Hope this helps. Best regards, Jere [1] http://dev.w3.org/2006/waf/widgets/ [2] http://tools.ietf.org/rfc/rfc5234.txt [3] http://jcp.org/en/jsr/detail?id=238 -- Jere Käpyaho ([EMAIL PROTECTED]) Specialist, Developer Platforms Standardization Devices RD, Nokia Corporation
Re: [widgets] Packaging Configuration 1.0 pre-CfC comments
Hi Jere, On Wed, Dec 10, 2008 at 12:47 PM, Jere Kapyaho [EMAIL PROTECTED] wrote: Hi Marcos, finally I got the chance to read the Widgets 1.0 Packaging Configuration spec. Great work there; please accept some comments based on the Editor's Draft 7 December 2008 version, up at [1]. 5.3 Zip Relative Paths The ABNF needs some polishing: - Rule names like cp437 vs. cp437-chars, utf8-range vs. utf8-chars, ascii-range vs. ascii-chars. Fixed. - ABNF rules are case-insensitive as per RFC 5234 [2]; does this affect the Language-Tag rule in any way? No, they are also case insensitive. - delimiter should be %x2F or just / for readability used /. - In cp437-chars, should say %x80-FF (and no semicolon) fixed. - s/is define in/is defined in/ fixed. 5.4 Reserved characters - Minor issue with the table of reserved characters: the Unicode code points Fixed. column would be better labeled Unicode character and be made the first column. Fixed. The CP437 column is redundant, IMHO. Right. dropped it. The column Character representation could be just Representation or Representative glyph. Used Representative glyph. - Are filenames of ZIP entries case-sensitive or not? The ZIP spec does not seem to say (or I missed it), but the PC spec has several recommendations about case. I think they are case insensitive. So, if you have two file entries with the same file name (say a and A) inside a zip file, upon decompression, one will override each other. This is also a problem on operating systems that are case insensitive. 6.4 Content localization - Note that since localized folders now must reside in the root of the widget package, they pollute the root namespace, and it is possible to (more or less accidentally) have a normal folder whose name is a valid BCP47 language tag. In essence, all valid BCP47 language tags would have to be treated as reserved. Should the localized folders instead be placed one level down from the root, inside folder 'X', where 'X' is a suitable reserved name like 'resources'? I don't think this is necessary. We should maybe add a conformance checker behavior to warn authors about this. - If there ever is a case of the WUA having to iterate all the localized folders, I think it's going to be difficult or impossible to find them all. Is this a problem with the way the algorithm in the spec is written? or is this a problem with with BCP47? We had this problem in JSR 238 [3], and ended up having a metadata entry that lists the supported locales. It can be generated by a widget packaging tool. Not ideal, but beats a combinatorial explosion... :) Or maybe you envision that the lang-priority-list removes the need to iterate? If the problem is with strangely formed langauge tags, I wonder if conformance checkers will help there? 6.5 Start file and Default Start Files See Step X for instructions of how to find the default start file. -- here X should probably be 9. Fixed. 8. Steps for Processing a Widget Resource Step 6 - Determine the base folder and widget locale - Algorithm step 2.d.i.2 seems to be missing something (Let base folder .). Ok, it's now Let base folder be the name of the folder that matched the current range. - Algorithm step 2.d.ii refers to this step 2.4. fixed. Should have been 2.d References - ZIP file spec: seems to be revised from time to time, would it be good to freeze the reference to a particular version? Agreed. We will probably freeze on 6.3.1. - Might want to fill in the HTTP, URI, ABNF etc. references before formal publication. BTW, did you already get someone to volunteer to do it? I'll help if not too late. I haven't had anyone volunteer (though Mohamed Zergaoui sent in some comments regarding what needed fixing[1]). I would _really_ appreciate any help you can give me! - Make all the URIs also links (like BCP47). Will do. Kind regards, Marcos [1] http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0436.html -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Packaging Configuration 1.0 pre-CfC comments
Hi Marcos, On 10.12.2008 18.40, ext Marcos Caceres [EMAIL PROTECTED] wrote: - If there ever is a case of the WUA having to iterate all the localized folders, I think it's going to be difficult or impossible to find them all. Is this a problem with the way the algorithm in the spec is written? or is this a problem with with BCP47? Neither, really. This could turn out to be mostly a non-issue specifically because BCP47 was designed to be parsed with just formal understanding. All subtags can be identified by length and position, so you just need to iterate all the folder names and check if they could be formally valid language tags. This could still give you false positives (directories with a name that is a valid language tag, but which are not 'localized folders'), which is why I suggested placing them one level down from the root. You still need to check, but not all top-level dirs. But if you think this is rare enough not to worry about, then I'll probably agree. :) --Jere
