- From: Robin Berjon <robin@berjon.com>
- Date: Fri, 21 Jan 2011 11:48:19 +0100
- To: Marcos Caceres <marcosc@opera.com>
- Cc: public-webapps WG <public-webapps@w3.org>
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 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 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? -- Robin Berjon - http://berjon.com/
Received on Friday, 21 January 2011 10:48:48 UTC