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 > >
smime.p7s
Description: S/MIME cryptographic signature
