On Mon, 17 Jan 2011 13:56:43 +0100, Robin Berjon <ro...@berjon.com> wrote:
On Jan 11, 2011, at 08:24 , Marcos Caceres wrote:
On 1/10/11 4:28 PM, Robin Berjon wrote:
On Jan 10, 2011, at 16:00 , Marcos Caceres wrote:
I would be happier if we could break up the Widget P&C spec into:
* Packaging (zip only requirements) * XML Configuration for
widgets * XML Localization and Folder-based Localization
I could live with that. It's not that I'm against l12n, I just don't
think that it needs to be part of the standard given its complexity
cost and likely actual usage.
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, and the primary reason why such an
implementation is more than just reading a Zip archive plus a little
extra processing.
Well, that depends on how you define "a little more".
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 :)
For i18n I would suggest that 20% is actually a pretty good number for a
new system, and that if we ever get 80% it would be amazing. How many
developers of something as simple as extensions are multilingual in the
first place?.
A quick search on most popular extensions (which get better highlighting)
today shows that of the top 50, 9 are localised to two or three languages
with those localisations also being in the top 50.
Looking at the newest 50, the proportion is 13/50 which suggests that it's
an increasing trend. About a third of extensions added since Marcos
counted are localised - still not 80%, but not bad. Given that there are
also non-localised extensions written in different languages to do the
same thing, I think this is
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.
If it gets 1/3 usage over a longer term, I would suggest that it's
actually very valuable.
But as I said, if we split the specs into pieces I'm happy!
Well, that resolves the issue through administrative trickery. But I think
it would be a shame if something that offers so much to i18n gets left
behind by enough implementors to seriously impact interoperability and
therefore the cost of localisation for developers.
cheers
Chaals
--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera: http://www.opera.com
