Re: [widgets] Removed LocalizableString interface from Widgets API

On 19 Jan 2011, at 18:39, Marcos Caceres wrote:

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

I'm glad I took the time to implement the i18n code for Apache Wookie. I may not see any immediate benefits, but it didn't take a *lot* of work, and if down the line it improves our impact further down the line...

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

The folder localization stuff we implemented in one filter class.

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

I'm working on an EU education project at the moment, where we'll be using widgets with schools in about 15 countries using a common "app store". Just distributing loads of single-language widgets is a non-starter. I think once we get going with that we'll be more like 80% of the widgets we use will have to be multilingual.

I think if Widgets didn't have an i18n+i10n model, we'd have had to use something else, or budget in time to develop our own spec :-(

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

I agree its complex, and might be off-putting to some implementers of runtimes. However its easy enough for widget authors to grasp. I think thats the right balance to strike for long term adoption.
> 
>> But as I said, if we split the specs into pieces I'm happy!

I'm kind of agnostic on that one. Might be OK, might be confusing...
> 
> 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 
>