I have been lucky enough to be invited to MozCamp Europe in Berlin last week-end and enjoyed the meeting very much on every aspect: have a better insight of what is cooking in Mozilla headquarters, discover amazing projects, having fun together, but above all I am glad I met people in real life and in some cases have an interesting discussion about addons localization on BabelZilla.
First of all, I was very glad to meet our good old Jürgen Berg aka Fenian. It was the first time we met in real life, though we have been working and communicating together on a daily basis for 6 years. I also met for the first time Lakrits who is at the moment our top contributor translating for Swedish, the old-timer teo who is translating for Polish, was pleased to meet again George (aka Sonickydon) from Greece and some others whose face and nick are now familiar to me. I really hope we shall have another occasion to meet other BabelZillians in the future.

Talking about addons localization

A significant number of various sessions were focussing on addons and localization at this MozCamp, which is but justified, considering addons are crucial for the browser, whether they are for old desktop or for mobile which is now major battlefield for Mozilla.
Among various sessions, I attended this very interesting one about the way Jetpacks would be localized in the future. As JSON was a candidate for file format, it seems the community discussion lead to some other localizer-friendly choice. We shall see how our own system can parse this kind of files, but it seems rather easy to handle.
I also gave a short presentation about the current state and issues on BabelZilla and what our goals for next steps are.
You can have slides here. There were a couple of questions and a very grateful Ken Barbalace (the developer of the Classic Compact Options extension), then it was time to leave room for Adofex, (demo) which can be the next step for BabelZilla, replacing gradually our good old WTS. Don’t be afraid, transition will be scheduled smoothly, some key features we currently enjoy on BabelZilla are still to be ported or implemented on Adofex, but hey Tim will develop his already smart tool to be tested and used on BabelZilla, so that you the user community, whether you are newcomers or old-timers, can provide useful feedback and help us create the best possible system together. Also, he would be glad to receive your feedback on the talk and the teams organization.
Tim will soon post here and explain what the interest of Adofex is for Babelzilla and which will be his next step on development. Stay tuned!

Please give a test (it will last less than 2 minutes I promise). This is a beta feature, you can upload as many times as you like since there is no connection to our usual database.

You are welcome to try on this test page.
Test page is no longer available.

A caution though: you will see yourself logged in as ‘BZ_System’. Do not be alarmed and think someone has taken over your account; just log out and log in as yourself again afterwards!

We will be pleased to receive feedback, bug notification, interesting suggestions and requests.

Thanks to Mozilla Labs awesome hackers, we can now enjoy restartless extensions à la Jetpack, and sure this is a cool feature.
One of the most recent extensions of this kind from the Prospector series, is Query Stats. I noticed there are some interface strings bundled in an innerHTML to be found in the bootstrap.js file

Some strings nested in JavaScript code

Now my question is: how are we supposed to localize such an addon?

Is it worth doing it?

Yes, I know: Jetpacks and restartless addons have a very limited number of interface strings or no interface string at all, and Prospector series are mostly experimental, targeting the power user (though I suppose the more mainstream they are, the more useful data they can bring), so i18n may not seem necessary.
I would simply object that restartless addons will probably have a growing success in addons developers community, which is good. But restartless addons with important interface will surface (to me even limited interface is important, but this is another question).

No JavaScript, thanks

Here in BabelZilla we are processing typically .dtd and .properties files, html and xhtml too. But we are definitely not willing to have javascript files uploaded. Moreover we want to lower the entry barrier to translation and we don’t want to ask translators to slalom between javascript functions and variables and translate only strings in code without affecting the syntax.

The right moment?

One little flaw in development makes things more difficult afterwards: localization issues almost always came second as an annoying appendix for real core dev. Localization rises technical issues that should be taken into account right from the beginning of the devlopment process, otherwise it makes things much more complicated (think of the smart and tremendous localization efforts on Ubiquity in the past).

Who can help?

So I would suggest it is due time to think about i18n (hey l20n welcome too!) for this new and promising generation of addons.
Fortunately, and that is why I really love the Mozilla community, there are always brilliant minds who are one step ahead in development and conceive projects that tend to answer questions even before anyone think of asking them

-Please let us know.

On July 30th, 2005, when together with early helpful enthousiasts, we (Giuliano, Jürgen, Luana and I) started this project, we just imagined it could be a useful meeting point for extension developers and translators.
We received such a tremendous response from the community of volunteer translators around the world that we were compelled to push our project constantly forward.
There have been about 900 extensions under translation on BabelZilla up to now, for more than 90 languages.
We are very proud to give individuals and teams worldwide the opportunity  to bring their contribution to one competitive advantage of Mozilla apps : extensibility.
Thanks to each and every translator past and present for the time and work spent on the translation game.
We hope you enjoy BabelZilla, we know it is still very far from the perfect site and service we are all dreaming of, but hey we shall try to make it better together with you.
In one of the very early posts on the newborn site you could read

BabelZilla is online, but there is still much work to do.

Well, 5 years later, a lot has been done but we have still much work to do together: develop language team translation, find new translators, fix annoyances and bugs of the WTS, make the interface more user-friendly, find graphic artists contributors, support new extension formats, provide more documentation and guidance…
Join BabelZilla !

TransVision Is Good For Me

Well it should be good for you too

I have been using this tool for more than one year now, I think you can find it fun and useful, so I just want to share some of my personal experience here.

What is TransVision

With this glossary tool you can get a Vision of all Mozilla apps Translations for your language. It lets you dig very easily into the huge database of already existing translations.

This online service is brought to you courtesy of Frenchmozilla leader Philippe Dessante who likes playing with algorithms and scripts and explains here what is under the hood.

It is so simple and intuitive that you can see and understand immediately what it is about:

• go to this page
• click on your language letter-code (hey you should know it if your are a translator )
• drop an English string in the search box instead of the default word, click on Search and see what happens

Yes this is just simple: path to original entity, en-US string, and translation. As a translator, I am sure you appreciate to have translation in context

How I use it

Translation

That is obviously the main use I make of TransVision. I have always MozTran entry in my context menu. MozTran is a simple extension I have made to use TransVision, you can enjoy it whatever language you use (thanks to Captain Caveman‘s code for automatic language detection). Just select, right-click and choose MozTran, the results page opens a new tab.

You can get MozTran on this page.

As an alternative, you can use a searchplugin.
Philippe Dessantes made one for each lang to be grabbed here on this searchplugins page !

Of course I use it on a daily basis to translate extensions but it is also very quick and efficient whenever there is some update on the Mozilla apps repository and one translator is wondering “Hey, we have to translate again this f***ing privacy policy string, I can’t remember what we chose last time…?”. The answer is just one click away.

Typo and errors chasing

My main contribution to the Frenchmozilla Team (apart from telling nonsense on #frenchmoz irc chan) is to annoy translation leaders with filing translation bugs (see my bug list on frenchmozilla Bugzilla)
I would say a solid 80% of the translation bugs I submitted were found with TransVision. here are some typical cases

mispelling

I either enter an English string in the searchbox or intentionally enter a mistyped French word (eg. déclareation,étiquté instead of déclaration, étiqueté).
I have but to read at my convenience and see where things are wrong in the fr column. Note that it is easy to check that no such typo was made when you find your language part (2nd part of the page) is just void.

missing translations

TransVision helps greatly to see where missing bits are. Here is a recent example where obviously the French part is abnormally short.

missing translation bits

translations that need to be reworded

It is much easier to browse visually a result page and read sentences to check their meaning/grammatical validity than to browse one file with a text editor or wait for strange sentences to catch your attention in the interface of a Mozilla application when using it: depending on your personal usage, it may well happen you will never come across certain strings. With TransVision you can concentrate on your language strings without being distracted by code or layout environment.

one typo means more typos of the same kind

Suppose I found a mispelled word, I re-inject it all at once in the searchbox so as to see if the little error was repeated, hence bugfixing is more systematic. Though French translation is close to professional quality, accidents may happen

Consistency checking

That is where TransVision tool is more useful than a standard all-purpose glossary.

Here we have access to all user interface for Mozilla application, hence we can have a consistent Mozilla interface. It is very important…

- for the application(s) user

- for the extensions user

…to find the same features named with the same words and sentences!

There is one special tool to be used for that, you can find it at the bottom of the TransVision page

It helps you detect when same strings (with or without same entity names) have different translations

You have just to choose which “modules” to compare. Here I choose “browser” and “mail” for Italian…

and in the output I can see sometimes different choices for the same strings (it may or may not be necessary to adjust)

More to discover

I am sure you can discover by yourself some interesting features (eg. search with regular expression or wildcard), but now it is up to you to experiment and tell everyone what usage of this tool you found, what additional features you would like to have (use this wiki page) and which bugs need to be fixed.
Comments welcome

Locale statistics

Add-on statistics pages are now capable of listing the total number of daily users by locale. Awesome.

Take a look at my stats for Flagfox, as an example:

Flagfox stats as of this posting

This means that extension developers are now armed with the data to actually request specific localizations that their users would use but currently do not have.

This new set of statistics is available by selecting “Locale” in the drop down menu on the left. The other new feature in there is the ability to break down downloads by method, which too is quite helpful. Note that while statistics tracking is available for all add-ons, the page must be set to “public” mode by the developer to be accessible by others.

Locale completeness checks

The AMO add-on validator now has a test to automatically check for incomplete locales. (see announcement)

L10n validation

On upload of an extension file to AMO, the add-on validator will now warn you if it has missing or untranslated strings. You can also (re)check your files via the “Validation” column in the “Versions and Files” view in the developer control panel. (files checked before this test was added need to be rechecked manually to see new results) Logged in non-developer users are also free to upload XPIs to check here.

Of course, as with some of the other warnings in this thing, please remember, it’s only a warning. Don’t worry too much about rejection from AMO merely for having some untranslated strings. Flagfox, for example, has 1807 “unmodified translations” in 18 different locales. Granted, I’m a special case here with hundreds of different country names that need to be localized, quite a few of which use the same word as in English. (if you package correctly it all gets compressed out nicely in the end so it doesn’t waste installer size) So just keep in mind that your mileage may vary.

Many thanks to AMO for these very nice and useful new features.

What are contents.rdf files?

Junk from a bygone era. When writing a Mozilla extension you need to tell the application where and what your extension’s files are. Since Firefox 1.5 (Gecko 1.8) it’s been a simple matter of writing a chrome.manifest file, but before that there were contents.rdf files. You needed a contents.rdf file for your overlays and another one for each locale. An example:

<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:chrome="http://www.mozilla.org/rdf/chrome#">

  <RDF:Seq about="urn:mozilla:package:root">
      <RDF:li resource="urn:mozilla:package:myext"/>
  </RDF:Seq>

  <RDF:Description about="urn:mozilla:package:myext" chrome:name="myext"/>

  <RDF:Seq about="urn:mozilla:overlays">
   <RDF:li resource="chrome://browser/content/browser.xul"/>
   <RDF:li resource="chrome://navigator/content/navigator.xul"/>
  </RDF:Seq>

  <RDF:Seq about="chrome://navigator/content/navigator.xul">
    <RDF:li>chrome://myext/content/overlay.xul</RDF:li>
  </RDF:Seq>
  <RDF:Seq about="chrome://browser/content/browser.xul">
    <RDF:li>chrome://myext/content/overlay.xul</RDF:li>
  </RDF:Seq>
</RDF:RDF>

and for each locale, a different version of:

<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:chrome="http://www.mozilla.org/rdf/chrome#">

    <RDF:Seq about="urn:mozilla:locale:root">
        <RDF:li resource="urn:mozilla:locale:en-US"/>
    </RDF:Seq>

    <RDF:Description about="urn:mozilla:locale:en-US" chrome:name="en-US">
        <chrome:packages>
            <RDF:Seq about="urn:mozilla:locale:en-US:packages">
                <RDF:li resource="urn:mozilla:locale:en-US:myext"/>
            </RDF:Seq>
        </chrome:packages>
    </RDF:Description>
</RDF:RDF>

It’s a mess. These days you do the same thing in a chrome.manifest file with one line for each locale and overlay, instead of dozens and dozens of files of RDF gobbledygook all over the place.

Great. It was replaced 4 years ago…

Not quite. SeaMonkey 1.x still uses install.js scripts and this whole archaic system. Its engine is extremely out of date. If you want your extension to support SeaMonkey 1.x, you’ll need to write your own god-awful install script (what, do it automatically? you must be joking) and dozens of different contents.rdf files. Each locale will have its own contents.rdf and will probably scare your translators. It’s a mess that most extension developers don’t want to write or maintain, but… there is hope: SeaMonkey 2. After years of rewrites, the so-called “Toolkit Transition” brings the SeaMonkey code base into the modern world with support for all the sane extension stuffs you’re used to in other Mozilla applications. You can write one extension that works in both Firefox and SeaMonkey without having to do too much special. SeaMonkey 2 should be released soon, so we will finally be able to retire this kludge. There might be some other obscure application out there that still uses these, but I think it has almost entirely gone the way of the dodo at this point.

Why do I care?

Again, it’s a mess. It’s added complexity that is long since obsolete and hasn’t been recommended since Firefox 1.0. Furthermore, for Firefox 3.6 (Gecko 1.9.2) the entire functionality has been removed.

If you’re an extension developer:

If you’re still in the stone age and relying on this system for chrome registration in newer applications then you’ll need to switch to a chrome.manifest for your extension to work in Firefox 3.6 and later. It’s not hard. Firefox 1.5 or later will even make one for you if you install an old extension into it. You can leave it in to support really old applications and it won’t hurt anything if you’re also using a chrome.manifest, but eventually you’re going to want to clean it up and get with the program.

If you’re just stringing along your install.js and contents.rdf files for SeaMonkey 1.x support, then it’s time to start thinking about dropping it. SeaMonkey 1.1 is almost 3 years old now. SeaMonkey 2.0 will be out soon and it’s lightyears ahead of its predecessor in many areas. Many extension developers have already started dropping SeaMonkey 1.x support in favor of 2.0 and you’ll probably also want to do so at some point.

If you’re an extension user:

With various major upgrades and the death of install.js and contents.rdf, writing extensions for SeaMonkey is no longer ugly. More and more Firefox and Thunderbird extensions can be expected to gain SeaMonkey support in the future because developers won’t have to handle things too drastically differently anymore.

If you’re an extension translator:

If one of your localizations still has a contents.rdf file for you to “translate” (i.e. change all the instances of “en-US” to your locale’s ID), feel free to point the extension’s developer here. Translators were never intended to have to deal with these things in the first place. All it does is add confusion and a rather unneeded extra hoop to jump through.

> my point is : share simple observations on what makes a contributors’ community succeed or not, and have your feedback since you are all community leaders ore active members on various levels. I don’t pretend to deliver new solutions, just want to share questions.

1. Give them the tools, they build a cathedral

The first thing that comes to my mind when thinking of BabelZilla is the huge initial disproportion between
- the simple tool we have put online : it is but an online translation system after all, though it has grown with various features since 3 years, the basic idea gained almost instant success.
- and the tremendous work contributors from all over the world made out of it (currently we host more than 700 extensions and 80 languages have active translators.)
What it proves I think is: there is a very strong desire to contribute on this kind of  project, and if people are not provided with adequate tools, this potential energy may be lost for the community.
The key is : the tool we provide to the contributors must be at contributor’s level,
which is supposed to be : not higher than the technical level of an advanced user. BabelZilla translators are sometimes real nerds, sometimes developers, but most of the time they are just translators willing to contribute with what they know best, that is :« language », most of them don’t care much with
javascript and xul.
 Same thing can be said about Narro, which is a very smart tool. I like narro very much, Alexandru has implemented smart features that we have not on BabelZilla to ease translator’s work. The difference that still makes BabelZilla a good place to be is that our Web Translation System is closely linked to a site with forums where translators and developers can communicate easily.
Here I am glad to quote one bit from Alexandru, the guy who created narro :
« Narro really lowers the entry barrier to the software translation world by using a simple, intuitive interface »
I do share this view of making contributions as easy as possible. The simple idea I come to is : if we want more numerous  Mozilla contributors, they must be given access to efficient tools on one click.
Let me rephrase it this way: where are the mainstream-level tools Mozilla offers to potential contributors?

2. A virtual community is just a virtual community

BabelZilla is not completely the marvellous community it should be. Of course we have various bugs on our system (as an admin I am the main bug really), but the main problem is: the awesome community of translators is not here to stay long, and is never big enough to make permanent teams. We have a a quick turnover that makes maintaining translations rather difficult sometimes.
We cannot blame young contributing people to have various changing interests, from going to the movies with girlfriend to getting a real job for a living.
So we have sometimes problems like this one

 This translator friends has no time left now to maintain his long list of translations. Who can take them over ?
Note that he has been contributing for 3 years, we also have contributors for one month only.
Hence these questions

- what could be done to try and get more stable and more permanent contributors ? On Babelzilla, apart from a user status promotion to moderator or admin, we have very few to offer. We have not even Tshirts to offer to major contributors, as opposed to Mozilla community organizing events with beer flowing.

My questions : What is your response as community leaders to the problem of transient contributors ? How do you make them permanent contributors ?

3. All you need is teams

Let’s suppose we have great simple tools and a stable dedicated community.
Now every community on BabelZilla is not at the same level of commitment.
Some are numerous and organized, this is the case for German erweiterungen team for instance, others would like very much to be organized as teams but are almost all by themselves, this is the case for the Greek main contributor. Our friend George Fiotakis, who is also indulging in translation of Mozilla apps and sumo pages.
I rememeber when in Barcelona Seth asked to various l10n communities to introduce themselves, a certain number of them were a two-people team only. This is clearly an issue for me. I know that at some top-level of contribution, responsabilities can only go to one or two persons in charge. But these dedicated individuals are likely to be overheating with work.
I remember before annoying the French mozilla people with my repeated bug reports, I did not know how they worked nor how many they were. I figured out there was a big team of 30 guys managing with translation and support and spreading the good message… What I discovered is that the orchestra may be a one-man-band. Sure French Mozilla has perhaps 30 contributors and probably more, but really active ones are less. And all in all, there is only one guy (Cedric) who does all the major job on localization.
What happens if one guy is suddenly not available when there is a major release to push ? (let’s suppose Cedric broke his dsl box or rain is falling in his kitchen as it frequently happens). Is there sufficient human ressource to get the job done ? I will say yes for the French Team, probably, but I am curious to know how the other teams organize to share the work.
My question for this point is:
How is the balance in your teams between people who are really in charge and people who can take over responsabilities in case it is necessary ?

4. Quality is an ever pending question

On BabelZilla we strongly recommend double-check testing and proofreading. We wish no translation is set as released before being reviewed by some other guy than its main translator.
 
But as registration is free, we have no real control on whatever can be translated for more so many languages. So we must to a certain extend be confident and cross our fingers.  
On Babelzilla French team we have the habit of mutual proofreading on a dedicated forum.
What is slightly a relief is when someone rings the bell with « hey I am a trained Russian translator and I can tell you that translation for that extension is reallly poor google automatic translation, please register me as main translator for it so that I make it a decent one ».
So when there is a significant number of people per language most of the problems can be solved before public release.

Anyway, errors and typos happen, all the time, whatever double-check you manage to process. Last year I have been reporting about a hundred valid bugs on French translation of Mozilla apps, though the translation is excellent, Cedric is really a very good translator, very demanding with himself, but he is doomed to make errors, though minor, as everyone of us.  All we can do is try and limit the number of imperfections.

Testing, proofreading, setting a dedicated bugzilla, again all the tools must be there but they are of no use if there is no human. I know you are running ophisticated tools such as litmus, windmill, whatever… How many people are really active on testing Mozilla products in your community ?

5. Guidance of newcomers should be a full-time job

Here I come to a problem I have noticed both on BabelZilla and Frenchmoz. My main line is still : how to increase the number or active contributors in our community ?
Let’s say there are two very different groups in a contributor’s community

one is a very limited number of trained contributors, people with experience and know-how and high level of involvment
the other is a pretty large number of volunteers eager to do anything for the community

Two problems
- the gap between the two groups is too important, you can ask an enthousiast newcomer to translate a paragraph or two in a sumo page, but you cannot tell him to push a patch in a mercurial stuff.
– the time and energy of contributors of the first group are completely absorbed by the good work they do. Guys like Cedric, even though he is open to questions, has definitely not time enough to guide a newbie and make a real effective contributor out of him/her.

The obvious solution should be to have an intermediate group of people completely dedicated to initiation and guidance of newcomers, let’s call them tutors (?)
Of course, I supose it is pretty difficult to find out tutors that would have
– knowledge enough to be peers of the first group
- patience and time enough to help new contributors
My idea is : if we want more active contributors, some people must clear the way for them.
My questions are :  Do you think of guidance as a real mission? Have you this kind of guiding people in your community? How could they be found out?

6. Early users are final users

One interesting side effect I discovered on BabelZilla is that translators are not just translators. They are interested in what they translate and most of the time they do test the extensions and report what they notice, ranging from « this dialog window should be resizeable to let my language be fully displayed » to « you
should add this feature, it would be cool », or « I clicked the icon on statusbar in vain. Does not work for me ». They are so to say the early final users for extensions, and I know they are valuable support for extension developers.
So I wonder if there could not be something valuable to be taken from early users as first mainstream testers.

I know that in every community there is a a certain amount of people
who like to test an test again new products or features, they are keen on nightly builds and have fun with pre-release and the kind.  But are they numerous enough ? How can we make the early users basis much larger ?
I don’t speak here of experienced geeks that can open a bug and submit a patch, and take their pizzas while performing a litmus test, I am speaking of your grandma.
Let’s suppose everything is checked ok on code and running fine. There is still a huge feedback to grasp for Mozilla.
For instance let’s test how the interface is used, let’s hear what people say when they do not find the awesome bar so awsesome, when they are confused at the idea of geolocation, when they don’t feel like using words typed on a keyboard , when they cannot find their bookmarks any longer, when they simply don’t understand the fucking certificate manager and so on.
Testing code is coder’s job, testing user interface should be user’s one.
And don’t tell me it is enough for end-users to click on a button to fill the metrics. How could Mozilla communities be empowered with feedback from mainstream users?

7. There is no codehacking and localization, there is development

In the field of extension development, there are still strong resistance to the idea of early and complete localization, and I am proud to be the guy who sucks, having sent many messages to extension developers so that they add locale support to their extensions, and in many an occasion just sending them a version with added locale support.
Last year we have been having an interesting experience with Komodo editor. Davide Ficano proposed to make locale versions, and we began this huge work, to discover gradually that a huge amount of strings
were still hardcoded. We began to submit patches to Komodo repo, then waited. But as soon as the localization patch landed, development was going on, and much to our disappointment we discovered there were new strings added in code in teh latest version, so I had to patch again. At the moment, I am still uncertain whether I should not have a look and detect string nested in javascript or xml.

Just another example : the winner of the Extend Firefox Contest for 2008 was Pencil, a very good extension. But this valuable extension is currently released without any locale support. All the interface is hardcoded, English-only. I don’t understand how this extension was the winner if the idea of the contest is to use innovative extensions as promotion tools for Firefox.
The new jetpack extensions that helps to make a new style of extensions without xul is pushing interface strings in html. That is no good because it is not easily localizable. Jetpack devlopment team should manage right now with the problem of localization, unless the whole thing is due to fail, just like the progress of Ubiquity is really slowed down because localization problem was no taken in consideration right from conception, and now it is a pain in the ass.

I am aware developers minds cannot be changed in a minute, and in their
minds development of code is high priority, but I would still advocate for early localization of any software product. Development should be one, and include localization from scratch.

8. Sharing knowledge is good, sharing mistakes maybe even better.

My experience on BabelZilla is rather funny. Giuliano here maybe remembers that I was given admin status at the very beginning though I had not the least technical knowledge, I hardly knew what moderating a forum was. So I discovered the few I know just doing it month after month. Now that I can draw some conclusions of this experience, I realize that I was unable to learn by imitation (which is my usual way of learning) because what we were doing was new to some extend. So I indulged myself on learning with error / correction process. I found it was maybe a good idea to be proud of one’s mistakes, so I opensourced my list of Goofymistakes, in the idea of
making newcomers at ease with problems. They may see what a goofy guy I am and say : well after all, it is no problem if I make mistakes myself, let’s go ahead. We have people who have a sort of complex, who would never move unless they are sure they do the right thing. I want these people to relax.
making people aware that errors are nothing, correction is crucial. This applies to language spelling, to codehacking as well I suppose.
My question/suggestion is: why could not we  guide people into Mozilla products with an addition to already existing guidelines that would be: enter some keywords describing your problem in this searchbox and dig into the huge database of Mozilla users mistakes/probs/errors with the way to cope with them.
Or even better: end-users should be invited to tell what is going wrong in their own natural language, put that in the searchbox and expect significant results.
That is exactly what I am doing when I have a problem with my Ubuntu. I google a short sentence and get Ubuntu users fourms answers to my problems. On the French side we have geckozone forums, but I think there is a need for automatic answers to common problems, the task of Mozilla contributors on the forums would be less important.

9. Funny things should be done seriously and serious things…

Though I still find translation of extensions a funny game, I tend to think now extensions are serious stuff. Even amateur ones are very significant.
Extensions are the way people customize their Mozilla software.
So what I would say to extension developers is: you are not bringing code to the users, you are giving them acccess to a personal experience. Therefore, be careful and communicate.
A great number of extensions are simply missing this point, so they are useless. They lack documentation dramatically. Extensions should be really more user-friendly. Extensions have rarely a Help page, rarely an howto page, the interface is not always explicit enough, and when messages exist, they can be very cryptic to the final user.
My proposition is: let’s tell the developers they should learn how to communicate in a natural language (technolang is not). A user-friendly app is a well-documented one.
AMO reviewers should be more harsh on poor interface. When you have installed an extension and you must find out how and where to trigger it, it is no good.

10. Localization matters. All over.

I know you are all convinced of that, and most dedicated to this cause. We also know it is still a long way to go.
On BabelZilla I also have learned that localization matters even though you are at the far-end of the globe. We have seen sometimes translators localizing for languages that were not yet officially released for the main apps tehmselves. This is the hint of a strong desire to have control on one’s application in one’s language.
Some propositions to make a global world of extensions more localized:
have it as a rule for amo reviewers that a minimum en-US subfolder is highly recommended « No extension released without localization please! »
have the possibility for translors to directly suggest metadata on amo extension page (as recently discussed with Cedric)
Each time a new language for Firefox is available, a set of the ten most popular extensions should be available for this language too. Extensions should be promoted on the very download page more explicitly.