Re: [widgets] Removed LocalizableString interface from Widgets API
On Fri, 21 Jan 2011 19:32:57 +0100, timeless timel...@gmail.com wrote: a nokia maps application uses json for localization and could be easily ported to the widget format. On Fri, Jan 21, 2011 at 9:09 PM, Charles McCathieNevile cha...@opera.com wrote: Could you automatically port it? The structure is: html/mapplets/component/i18n/locales ~8k per locale per component html/mapplets/stuff [2.5mb] html/medos/i18n/locales ~64k per locale, ~1mb for however many locales total html/medos/images/stuff ~680k html/index.html ~948k html/ [6.2mb inclusive] the index.html file uses relative refs, so yeah, it'd probably be possible for *someone* - *not* me to automatically port it. I really don't have time to do this. It should be possible for anyone w/ an n900 to look at /usr/share/nokia-maps and investigate it. the fact that each component is using its own subdirectory thing is moderately annoying, but fixing the include paths wouldn't be too painful for an automated tool. fwiw, my understanding is that nokia-maps works more or less the same way on maps.ovi.com, which means someone feeling adventurous could probably try to do it from there, but since i like my product, i'd request someone be nice and buy an n900 instead of slurping ovi maps ;-).
Re: Breaking up the widget specs? Re: [widgets] Removed LocalizableString interface from Widgets API
On Jan 20, 2011, at 22:10 , Marcos Caceres wrote: On 1/20/11 6:48 PM, Arthur Barstow wrote: If people have spare time for the widgets specs, it seems like that time would be better spent moving the existing specs forward. Agree. Just testing the waters to see if any other members were interested. If no one else is interested, and there are no resources available, then this is a non-starter and we press on with what we got. Ditto. In this question I'm actually more interested in what people who haven't implemented widgets think. -- Robin Berjon - http://berjon.com/
Re: [widgets] Removed LocalizableString interface from Widgets API
On 1/21/11 11:48 AM, Robin Berjon wrote: On Jan 19, 2011, at 19:39 , Marcos Caceres wrote: On 1/17/11 1:56 PM, Robin Berjon wrote: Nothing in P+C is super-hard to implement, but the l12n parts account for most of the complexity, I've only implemented the i18n stuff in Javascript, but I didn't find it particularly hard (relative to anything else). I say this because when implementing it is is both what took longest and what had the most bugs. It was also the part that required the most spec-reading. To be extremely clear: I'm certainly not shooting at i18n. I18n is a core requirement for any W3C product. I'm thinking about the specific localisation mechanism that we have specified (removing it does not prevent i18n in any way). True. But the alternative was no i18n model at all, right? No, I think that we can be more fine-grained here. There are essentially two mechanisms at work. One is used to select values in the config.xml file, the other is used to select resources in the widget. The former is useful in that it's the only way one has to ship a multilingual widget that can show a different name and description when integrated with the system. It's also the easiest bit (I found). The latter, however, does not really match how I've seen localisation done elsewhere, is more painful, more error-prone, and less useful. I don't see how you can make these claims (which are relative to which model exactly)? does wigeon support any of the i18n model at all? I've had a brief look at the source and the logs from the project and I can't find your code for i18n stuff. I'm sure you've probably done it (or tried it), I just couldn't find it. If there are better solutions, I would like to see a list of them so we can discuss them properly. We worked for over a year with the i18n WG and I would be extremely surprised if those guys didn't know all the pit falls of each model. I also discussed the model with our localization team at Opera and they were supportive of the model. I don't think that copying the same HTML in multiple directories just to change the language (if you're writing an application) is a good approach. One is far more likely to want to have a single structure (to avoid having to change it multiple times) and replace tokens inside of it to localise. That's absolutely fine too, if that is the model one chooses to use. The model is flexible enough to support both approaches by design. The spec does not force a developer to use the i18n model if they don't want to: a developer opts into the model by explicitly putting stuff into the /locales/ folder. Otherwise, one can do whatever he or she chooses. There is nothing stopping one from using a custom API or a script that contains the key-value pairs for look-up (or whatever). The key was to provide that flexibility and not lock anyone in, but to have one fallback that is simple and has been shown to work (what we currently have). That's the part that I'm most concerned about. But as I said, if we split the specs into pieces I'm happy! The point of splitting the specs would be to allow us to explore/standardize alternatives without breaking current runtimes and content. Let me make this absolutely clear: this is not an exercise to discard the current solution. Splitting the specs would be a way to further the reach of widgets and improve their adoption in the market. That's exactly what I'm saying. Would we get more implementations with that approach? Maybe. I'm putting the call out for feedback here. App stores that don't inter-operate are cropping up from major browser vendors, which use packaging formats (Zip + signature) and metadata formats (JSON or XML) that closely resemble W3C widgets. I think we can all agree that it would be beneficial to the Web community to get convergence on these technologies in the form of an open standards at the W3C.
Re: [widgets] Removed LocalizableString interface from Widgets API
note that you don't *need* to duplicate html files. the format allows for one to have json based localizations. a nokia maps application uses json for localization and could be easily ported to the widget format. i can't do it publicly because i don't own/manage the code.
Re: [widgets] Removed LocalizableString interface from Widgets API
On Fri, 21 Jan 2011 19:32:57 +0100, timeless timel...@gmail.com wrote: note that you don't *need* to duplicate html files. the format allows for one to have json based localizations. a nokia maps application uses json for localization and could be easily ported to the widget format. Could you automatically port it? I agree with Marcos that it is very valuable to automatically be able to move a localised app from one environment (e.g. app store, or dev toolkit) to another and know how the localisation works... cheers Chaals -- 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: [widgets] Removed LocalizableString interface from Widgets API
On 19 Jan 2011, at 18:39, Marcos Caceres wrote: On 1/17/11 1:56 PM, Robin Berjon wrote: On Jan 11, 2011, at 08:24 , Marcos Caceres wrote: On 1/10/11 4:28 PM, Robin Berjon wrote: I would argue that it's not particularly complicated to implement, and we are seeing it used in Opera extensions: we have extensions in 15 languages as of today in our catalog [0]. Nothing in P+C is super-hard to implement, but the l12n parts account for most of the complexity, I've only implemented the i18n stuff in Javascript, but I didn't find it particularly hard (relative to anything else). Opera devs implemented the i18n stuff in a couple of days. The parts that took a long time were the processing model and annoying XML issues not related to the i18n model. I guess complexity is relative, particularly if the implementer sees little return on investment in implementing the feature (then by complexity you really mean I can't be arsed doing it now because I don't *believe* people will use it... bit of a self-fulfilling prophecy: no one uses the thing that was never implemented). I'm glad I took the time to implement the i18n code for Apache Wookie. I may not see any immediate benefits, but it didn't take a *lot* of work, and if down the line it improves our impact further down the line... and the primary reason why such an implementation is more than just reading a Zip archive plus a little extra processing. True. But the alternative was no i18n model at all, right? Then we would be in the situation where there would not be any interoperable i18n solution (everyone would roll their own, or an API). Not having a formal i18n solution has several risks and consequences: * The i18n solutions would not be reusable (or simply fragmented). * The i18n solution could be done wrongly [1] (assuming our is correct given the amount of guidance from the i18n WG). * Catalogs would not be able to present localize content (or inform end-users if their language is supported). * User agents could not find the right bits of localized content to display in widget managers. Yes, the current solution adds complexity - but the benefits have clearly, in Opera's case, outweighed the costs. For developers, we also greatly simplified the XML PC i18n solution by not using ITS and simply relying on what XML already provided. WRT folder-based localization, it closely matches the i18n models used in software development (and was part of most widget platforms when we did the original landscape analysis for widgets; we were just following what was best practice at the time). So, it's not like we introduced anything weird. The folder localization stuff we implemented in one filter class. TOTAL (all languages): 335 of which 74 use another language (20% of the catalog). 20% is fairly significant and certainly indicative of actual usage. To put into perspective, we have had over 4 million downloads of extensions since launch. If it's only 20% then I maintain that it's not enough to justify the feature. We have a 20/80 situation here, when we'd want an 80/20 :) It's not realistic to expect every developer to cover 80% of languages - so I don't understand your argument. A significant number of Europeans know on average 2 languages and some content simply does not make sense to be localized. From [0]: 56% of citizens in the EU Member States are able to hold a conversation in one language apart from their mother tongue... Notwithstanding, a minority speaking either an official EU language other than the state language or a non-European language as their mother tongue is recorded in every country polled. The fact that developers are making an effort to cover 20% of languages cannot be understated or cast off by the arbitrary 80/20 rule. From [0]: With respect to the goal for every EU citizen to have knowledge of two languages in addition to their mother tongue, 28% of the respondents state that they speak two foreign languages well enough to have a conversation. This is especially the case in Luxembourg (92%), the Netherlands (75%) and Slovenia (71%). 11% of the respondents indicate that they master at least three languages apart from their mother tongue. Having the 20% of developers shows that, in fact, developers *do* care about localizing content and they do understand that they are delivering their content to a multilingual environment (if it was 28%, then we would be at the EU average). Opera has done virtually no promotion of the i18n model (developers just picked it up and ran with it), and I firmly believe once we educate developers on how easy the model is to use, we will see even higher numbers of developers making use of it. I'm working on an EU education project at the moment, where we'll be using widgets with schools in about 15 countries using a common app store. Just distributing loads of single-language
Re: [widgets] Removed LocalizableString interface from Widgets API
On 1/17/11 1:56 PM, Robin Berjon wrote: On Jan 11, 2011, at 08:24 , Marcos Caceres wrote: On 1/10/11 4:28 PM, Robin Berjon wrote: I would argue that it's not particularly complicated to implement, and we are seeing it used in Opera extensions: we have extensions in 15 languages as of today in our catalog [0]. Nothing in P+C is super-hard to implement, but the l12n parts account for most of the complexity, I've only implemented the i18n stuff in Javascript, but I didn't find it particularly hard (relative to anything else). Opera devs implemented the i18n stuff in a couple of days. The parts that took a long time were the processing model and annoying XML issues not related to the i18n model. I guess complexity is relative, particularly if the implementer sees little return on investment in implementing the feature (then by complexity you really mean I can't be arsed doing it now because I don't *believe* people will use it... bit of a self-fulfilling prophecy: no one uses the thing that was never implemented). and the primary reason why such an implementation is more than just reading a Zip archive plus a little extra processing. True. But the alternative was no i18n model at all, right? Then we would be in the situation where there would not be any interoperable i18n solution (everyone would roll their own, or an API). Not having a formal i18n solution has several risks and consequences: * The i18n solutions would not be reusable (or simply fragmented). * The i18n solution could be done wrongly [1] (assuming our is correct given the amount of guidance from the i18n WG). * Catalogs would not be able to present localize content (or inform end-users if their language is supported). * User agents could not find the right bits of localized content to display in widget managers. Yes, the current solution adds complexity - but the benefits have clearly, in Opera's case, outweighed the costs. For developers, we also greatly simplified the XML PC i18n solution by not using ITS and simply relying on what XML already provided. WRT folder-based localization, it closely matches the i18n models used in software development (and was part of most widget platforms when we did the original landscape analysis for widgets; we were just following what was best practice at the time). So, it's not like we introduced anything weird. TOTAL (all languages): 335 of which 74 use another language (20% of the catalog). 20% is fairly significant and certainly indicative of actual usage. To put into perspective, we have had over 4 million downloads of extensions since launch. If it's only 20% then I maintain that it's not enough to justify the feature. We have a 20/80 situation here, when we'd want an 80/20 :) It's not realistic to expect every developer to cover 80% of languages - so I don't understand your argument. A significant number of Europeans know on average 2 languages and some content simply does not make sense to be localized. From [0]: 56% of citizens in the EU Member States are able to hold a conversation in one language apart from their mother tongue... Notwithstanding, a minority speaking either an official EU language other than the state language or a non-European language as their mother tongue is recorded in every country polled. The fact that developers are making an effort to cover 20% of languages cannot be understated or cast off by the arbitrary 80/20 rule. From [0]: With respect to the goal for every EU citizen to have knowledge of two languages in addition to their mother tongue, 28% of the respondents state that they speak two foreign languages well enough to have a conversation. This is especially the case in Luxembourg (92%), the Netherlands (75%) and Slovenia (71%). 11% of the respondents indicate that they master at least three languages apart from their mother tongue. Having the 20% of developers shows that, in fact, developers *do* care about localizing content and they do understand that they are delivering their content to a multilingual environment (if it was 28%, then we would be at the EU average). Opera has done virtually no promotion of the i18n model (developers just picked it up and ran with it), and I firmly believe once we educate developers on how easy the model is to use, we will see even higher numbers of developers making use of it. It's evident that the i18n model is usable by runtimes, widget galleries, and developers. It's usable, it's just excessive complexity to value IMHO. I think the central question is how would you have done it differently (keeping to the current constraint that is XML)? Which leads to... But as I said, if we split the specs into pieces I'm happy! The point of splitting the specs would be to allow us to explore/standardize alternatives without breaking current runtimes and content. Let me make this absolutely clear: this is not an exercise to discard the current
Re: [widgets] Removed LocalizableString interface from Widgets API
On Jan 10, 2011, at 15:33 , Marcos Caceres wrote: On 1/10/11 2:27 PM, Arthur Barstow wrote: Hi Marcos - have you checked with the I18N Core WG? My recollection is this functionality was added to the Widgets API spec based on their LC comments. I'll contact them soon for further discussion on use cases. If a strong case is made for requiring this functionality now, then I will add it again. How about removing localisation from all widget specs? -- Robin Berjon - http://berjon.com/
Re: [widgets] Removed LocalizableString interface from Widgets API
On 1/10/11 3:39 PM, Robin Berjon wrote: On Jan 10, 2011, at 15:33 , Marcos Caceres wrote: On 1/10/11 2:27 PM, Arthur Barstow wrote: Hi Marcos - have you checked with the I18N Core WG? My recollection is this functionality was added to the Widgets API spec based on their LC comments. I'll contact them soon for further discussion on use cases. If a strong case is made for requiring this functionality now, then I will add it again. How about removing localisation from all widget specs? We make good use of the localization stuff in Opera Extensions (we have a lot of dual language extensions in our extensions catalog). In both our extensions catalog and in the runtime, we extract and show localized content based on the PC i18n model - and we do this effectively. So, I am not in favor of dumping i18n support all together given that we have spent a great deal of time implementing it, documenting it, telling devs to use it, etc. I would be happier if we could break up the Widget PC spec into: * Packaging (zip only requirements) * XML Configuration for widgets * XML Localization and Folder-based Localization This would allow implementers to cherry pick (as they are currently doing in the market): there are a few specifications and implementations that build on Widgets, but don't require i18n support. Also, other members in this WG have raised concerns about the i18n model used by widgets as an impediment to adoption of the specifications [1]. Kind regards, Marcos [1] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0159.html
Re: [widgets] Removed LocalizableString interface from Widgets API
On Jan 10, 2011, at 16:00 , Marcos Caceres wrote: I would be happier if we could break up the Widget PC spec into: * Packaging (zip only requirements) * XML Configuration for widgets * XML Localization and Folder-based Localization I could live with that. It's not that I'm against l12n, I just don't think that it needs to be part of the standard given its complexity cost and likely actual usage. -- Robin Berjon - http://berjon.com/
Re: [widgets] Removed LocalizableString interface from Widgets API
On 1/10/11 4:28 PM, Robin Berjon wrote: On Jan 10, 2011, at 16:00 , Marcos Caceres wrote: I would be happier if we could break up the Widget PC spec into: * Packaging (zip only requirements) * XML Configuration for widgets * XML Localization and Folder-based Localization I could live with that. It's not that I'm against l12n, I just don't think that it needs to be part of the standard given its complexity cost and likely actual usage. I would argue that it's not particularly complicated to implement, and we are seeing it used in Opera extensions: we have extensions in 15 languages as of today in our catalog [0]. Here is a breakdown (these are not exclusive to one language, most use English and some other language - and please be mindful our catalog is very new): English: 262 Russian: 33 Polish: 16 German: 5 Japanese: 3 Turkish: 3 Slovak: 2 Portuguese: 2 Italian: 2 Norwegian: 2 Spanish: 1 Belarusian: 1 Czech: 1 Hungarian: 1 Northern Sami: 1 TOTAL (all languages): 335 of which 74 use another language (20% of the catalog). 20% is fairly significant and certainly indicative of actual usage. To put into perspective, we have had over 4 million downloads of extensions since launch. Most of those use 2 languages in the same widget, and some up to 3. For example [1]: widget xmlns=http://www.w3.org/ns/widgets; version=2.3-D name xml:lang=enAutoComplete/name name xml:lang=ruAutoComplete（Автозаполнение）/name name xml:lang=jaAutoComplete（自動入力補完）/name description xml:lang=enProvides the Autocomplete for the text input box./description description xml:lang=ruОбеспечивает автозаполнения для текстового поля ввода./description description xml:lang=jaテキストフォームに自動入力補完機能を提供し ます。/description /widget It's evident that the i18n model is usable by runtimes, widget galleries, and developers. [0] http://www.operaextensions.com [1] https://addons.opera.com/addons/extensions/details/autocomplete/2.3-D/
Re: [widgets] Removed LocalizableString interface from Widgets API
On Wed, 05 Jan 2011 12:39:05 +0100, Marcos Caceres marc...@opera.com wrote: I have removed LocalizableString interface from the Widgets API specification because no one has proposed any use cases for it. The purpose of the interface was to allow a developer to interrogate an attribute of the widget object to find out what language that attribute may be written in (if such information was declared via xml:lang in the widget's configuration document). You can't directly query the xml:lang attribute? cheers -- 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: [widgets] Removed LocalizableString interface from Widgets API
On 1/5/11 1:47 PM, Charles McCathieNevile wrote: On Wed, 05 Jan 2011 12:39:05 +0100, Marcos Caceres marc...@opera.com wrote: I have removed LocalizableString interface from the Widgets API specification because no one has proposed any use cases for it. The purpose of the interface was to allow a developer to interrogate an attribute of the widget object to find out what language that attribute may be written in (if such information was declared via xml:lang in the widget's configuration document). You can't directly query the xml:lang attribute? No, there is currently no means to get at the config.xml document.
