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.

Received on Friday, 21 January 2011 12:02:39 UTC