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.
