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 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

Received on Wednesday, 19 January 2011 18:40:15 UTC