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 P&C 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 solution. Splitting the specs would be a way to
further the reach of widgets and improve their adoption in the market.
This is not to say that widgets in their current form have not been
successful: there are bunch of awesome products out there based on
widgets (Try Opera Extensions today!:)). However, some solutions we
adopted early have proved unfashionable (XML instead of JSON), and some
decisions are justifiably problematic (XML Digital Signatures and its
reliance on XML Canonicalization, which in retrospect was a horrific
choice).
[0] http://ec.europa.eu/public_opinion/archives/ebs/ebs_243_sum_en.pdf
[1]
http://search.cpan.org/dist/Locale-Maketext/lib/Locale/Maketext/TPJ13.pod#A_Localization_Horror_Story:_It_Could_Happen_To_You
