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 !

More usability features

Philippe Dessantes recently made some improvements on his TransVision tool (more about TransVision) that make it more efficient for us.

• In the “Duplicates” tool the two translations of the same string are now in columns near to each other, so we can more easily compare them at a glance.

• Searched terms are easier to spot in the results page, they are now displayed in red

• … as well as the Mozilla “module” where they have been found (1st left-hand side column)

• There is now an option to search for a whole word/string only

• We can now search for entity name/property key. For example you can list every item which includes “accesskey” or “tooltiptext”

• TransVision Glossary with same options is now available as a Web service, you can get a JSON file of the output (see this example)

- Thank you Philippe!

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.

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

Hello MASA would you please introduce yourself?

Hey, my name’s Jake; I’m 18 year old student working for GameSpotting! Networks, a small independent contracting firm that I started.

MASA's avatar on BabelZilla

My work day is spent writing and reviewing code, writing bug fixes, dealing with users and some PR work. My programming time is spent mostly in coding time in XUL and JS, but I also do a bit of PHP, HTML and the like (it’s a fairly long list). I’ve done C++ work before (not so much now) and I aspire to earn my degree for a career as a Video Game developer.

As for hobbies: I like hanging out, talking, coding, building, playing with my buds on Xbox Live, writing scripts, acting, and doing work on my machinima* series, Mindless Intentions.

*For those playing at home, machinima is a corruption (or a portmanteau) between the words machine and cinema. It means to use video game characters instead of live actors to make movies.

You are the developer of various extensions, how did it all begin ?

Well, I tried Firefox after a debate at the old NSider forums (Nintendo of America’s Official Forums) and I liked how I could block ads and edit pages (before Greasemonkey there was an extension called R.I.P [I used that]).

I first started coding (I guess you can call it that) was when I wanted a feature in Firefox that wasn’t available for Windows machines (but it was on Linux). The feature I wanted so badly was to be able to middle click the Go button and have the url load in a tab, coincidentally, I called it Go Middle Click to New Tab (yes, the name is pretty ugly). I never released it (because it never worked) and stopped developing extensions for awhile.

Much much much later, I got a contract with OpenDNS (via a blog post looking for Firefox developers) to make PhishTank SiteChecker (I actually came up with this name). It was my first serious (ie: not something simple like a sidebar) extension and I did okay on it, finishing a working beta in less than 4 hours (THAT’S RIGHT: 4 HOURS [I work fast]).

The job got me a couple more contracts from KarmaSphere, Ratepoint and a few others. As well as the CEO of OpenDNS offered me a job at one point.

What made you start developing for Thunderbird?

Much later, I started using Thunderbird because Outlook stopped working and I didn’t want to bother fixing it. I had used Thunderbird before and thought it looked bad (because then, I thought everything that didn’t look like Outlook was bad) and uninstalled it. I had no idea I could use other themes (like the awesome own theme) instead of the default.

When I started using Thunderbird, I was pretty disappointed with both Thunderbird’s poor web handling when used with RSS feeds. But that’s where ThunderBrowse comes in.

ThunderBrowse (originally called URLBar for Thunderbird) started out as a crude elementary extension that I made (to be first) after I read a post on LifeHacker about changing your start page in Thunderbird. I played around with the concept and made an extension do the same. I believe the very first version (not released) actually loaded pages by changing the start page url back and forth (not a good idea). The whole backstory to ThunderBrowse can be easily found via GS! Networks case study (http://gamespottingnetworks.com/thunderbrowse).

Do you consider extension creation as a “funny playground” or do you consider extensions should be treated with as much seriousness (clean and smart code, usability, etc…) as the apps themselves ?

Extension creation is serious business! Very few extensions that were made to be funny have lasted very long. I make my extensions normally for some profit involved or because I wanted something and no one else has made it yet.

To me, extensions must provide something helpful or meaningful to a user. Usability is a huge benefit to an addon and can bring the author great success.

What would you say about the problem of beginning extension development? Did you find tools or code snippets or tutorials that helped? What would you suggest to a beginner?

Near the beginning of development, I’ll create a subfolder in my main “widgets” folder on my desktop. Inside the folder is an extension “template” that includes a few tools I wrote for easier testing and deployment. My most important advice to a beginner is to ask questions. To ask is to learn. MozillaZine and the official Mozilla IRC channels are a great place for this.

However, sometimes people won’t be able to answer your question. This means you either need to rephrase that question, or no one has even thought of trying it before (as was the case with ThunderBrowse).

Your Thunderbrowse extension can be seen as a kind of bridge between Thunderbird and the Web, which is more than a funny extension but somewhat of an evolution for the app itself. Don’t you consider that the ability to browse from inside Thunderbird should be a feature available as native in the application ? Do you have contacts with Thunderbird (or Messaging) development team ? What is their policy towards extensions ? (do they consider they want to have a sleeker and lighter application, so leave extra features to extensions, or do they intend to include some of the most useful bits ?)

Thunderbird doesn't have popups

That’s because it is a bridge between Thunderbird and websites

To the surprise of most users, I actually don’t believe browsing should be a part of Thunderbird. As much as it would be a cool feature, I don’t think it should be added. We would just be getting another SeaMonkey. Except it’s prettier and not as outdated (last time I used SeaMonkey was in 2007). A lot of users love ThunderBrowse for two reasons:

1. It greatly improves the RSS features in Thunderbird (something that has been lacking since Thunderbird started)
2. It’s also a great browser to check up on websites, activate accounts, post comments, whatever within your mail client.

I actually don’t use the RSS features in Thunderbird (I did at one point but stopped). I prefer FeedDemon but that’s a different story.

Quite a few people on the Thunderbird Development team are aware of ThunderBrowse and I think a few actually use it. I do get to talk to them a lot over IRC about some bugs that would benefit extension developers (Message to all Thunderbird extension developers: Guess what? The Thunderbird dev team is actually REALLY interested in what other devs think, so if you are having problems with development or have an idea to make it easier, tell it to them).

A couple of times I’ve been asked my opinion on a few ideas by the dev team, some of which have influenced some key development points. People are starting to accept the fact that browsing can be done in Thunderbird.

It used to be that I would go into the IRC room and say: “I’m having a problem with meta redirects (this is just an example). They don’t go where they are supposed to.” The response would typically be: “Thunderbird doesn’t do browsing.” Now they respond: “Well, you made the browser, figure it out.”

I laugh every time.

Do you feel the whole localization process as a boring waste of time for developers who are more busy and excited with code development?

While localization is important, it does bring up quite a few issues that look better in a list:

1. Support: Many users will have some problem with some software at some point. There really isn’t much of a fix here other than to make the software as simplistic as possible. If a user has a problem, they will likely tell you in their native language (this used to happen a lot) and as much as I would like to help, I can’t get any further than what google translate tells me.
2. Testing: Before release, I have to cycle through every locale to make sure it works. I have to do this now ever since we had a problem with a few locales losing encoding
3. Releasing: Because everyone obviously have some sort of life outside of translating, you have to wait for each and every person to be done with their locales until you can release.

However, localization does outweigh the points above:

1. Usability: Everything is easier when it’s in your language. Localizing pretty much does this for you.
2. Success: Mozilla actually prefers extensions that have a lot/fair amount of locales (if you wanna get recommended, there’s a protip)
3. Cleaner: code won’t be cluttered with lots of string lines
4. It shows class: Personally, I think that an extension is better if it supports other languages. It shows to me that you are determined to help the user in anyway that you can. I respect that.

Best thing to do? Have all your strings in your file to begin with, then one by one, move them over (this way you don’t run into any problems). There are a couple of extensions that are supposed to help out with this, but I’ve yet to use them.

What is your personal appreciation of what BabelZilla can bring to the localization process?

The best part of BabelZilla is that I can upload my extensions, write a new post in the forum thread, and somewhat forget about it until the locales are done. Some of my translators point out bugs that I’ve missed too, saving me the trouble of having to fix them in a later release. So that’s cool. If you are busy like I am, BabelZilla is a LIFE SAVER.

Can you tell us what extensions you have in store for the future? Got anything cooking back at the Lab?

NO! IS SECRET!

Other than delicious food, no not really. I’ve been spending most of my time on ThunderBrowse, trying to make it the best it can be so I can use it for my high school graduation requirements.

But if I were to tell you my secret development projects, they wouldn’t be secret, would they?

I guess not…

Glad we agree.

Thank you for your time.

Hey, no problem.

Quickfolders is a pretty smart extension for Thunderbird. You can find on its dedicated AMO page everything you need to know about its features and usage. If you browse the comments, you will see many satisfied users. Some of them are not completely convinced, but the developer manages to answer every time with great care.

options dialog

Also, if you give a quick test to the extension, you will see there are many options available and the Help dialog is verbose enough to provide useful tips and howtos. Excellent work.

The only thing is…
this interesting extension is available in English only

- Don’t worry, old Goofy, we shall translate it just now, I hear you saying, translators friends from BabelZilla.

- mmmh no. Because there is no locale support in this extension
That is : every string is hardcoded in a .xul or a .js file, there is NO locale subfolder, everything in the content

So once again I added what had to be added (with the help of the great Externalize extension by my friend Davide Ficano ), and once again I sent a message with my modified version to the developer, with my usual invitation message to BabelZilla, since it is much easier to translate now, with all the strings in the locale/en-US subfolder.

The problem now is: I am reaching externalize strings process #251 in less than 3 years.

It means that extensions are (still) released without a decent locale support.

I don’t blame developers who may ignore the localization process.
I don’t blame AMO volunteer reviewers who do an tremendous work and use several quality/security tests.

I am just wondering:

WHY is it not compulsory to have a minimum (en-US or another locale) locale support in an extension to be allowed to release it on AMO?

Please, AMO Commander in Chief, add “Have a locale support” to the list of requirements!

After two hour

I am almost sure you will be quicker than me, just take 5 minutes to complete it whatever your country and language is !

mmmh what do they mean by “- Other browser” ??

Here are some shots of the nice people who were in Barcelona Mozilla Camp

On the background the great Chris Hofmann, Mozilla Engeneering Director, is taking the mike, while on the foreground a young wizz web designer is shaping the future, creating the GUID for a new funky Mozilla app (codename: moZebra). Hey this is the burning edge!

A great moment was when I met some folks I never had a chance to meet before in real life. First in the morning was Georges, aka Sonickydon, our Greek major contributor and a very kind person…

Sonickydon

At last I met the incredible “lazy old man” Joooliiiaaaan ! Giuliano Masseroni, from Mozilla Italia, is The Man Who Had The Idea of BabelZilla and launched the project along with Jürgen. It was a pleasure to see him along with Simone (Underpass) and Francesco (Flod) from the Italian crew.

jooliaan and me

The Italian crew is also working at night at the Sal café, on the beach!

On the second day of the meeting, after various schedule changes, I delivered a little speech on BabelZilla during 20 minutes.

Here is the slideshow I used (Open Office presentation format) welcome2bz_19b
You can also browse my notes to get along with the slides and the online format (Google doc)

Now here is Pau Tomàs, a cool Catalan extension developer to whom I made some years ago the first locale support for his very handy gTranslate extension.

I really like his freaky look, I was probably just like that some 35 years ago . Times are not a-changin’, kids!

Time for serious discussion between Tristan Nitot (Mozilla Europe prez) and Aza Raskin, the wizz guy who is developing Ubiquity.

Here we have Jan Odvarko (right) from Firebug development team. Please translators, remember Firebug needs your work , just join here on BZ !

Dozens of photos can be browsed here

Here are other image thumbnails to click, provided by Sonickydon

(if you want to add images here, just give the link or send them as attachment)

Blogposts about the Mozilla Camp to be found on European Mozilla Community Blog, on William’s Blog, Tristan Nitot’s one, among others…

It is a smart and powerful Web Development tool. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page. Sure it is mainly a geek-oriented tool
Grab it on AMO -Learn more in documentation

Who is maintaining this extension?

Joe Hewitt was the original creator but it is a whole development team now! Just recently Jan Odvarko decided to manage the localization process relying on BabelZilla. He is very welcome .

Localize it!

We remember  in the past the question of localizing Firebug was controversial, various coders, though being Chinese or Spanish,  prefer to have it in English, and surely very specific technical terms must definitely not be translated. But we believe that the overall interface messages should be delivered in the user language. It is free choice then for developers to switch to en-US only if they feel like doing it (Quick Locale Switcher extension is very quick and efficient to change your language). Note also that some developers would prefer to stick to en-US interface because of the poor quality of the translation for their language. This is clearly a challenge for BabelZilla translators!

Firebug on BabelZilla: translators required!

There are currently 32 localizations for Firebug on the WTS, but only part of them are ready-to-use and set to “released”.  Some translators are missing in action for a long time, others are too busy to update at the moment… hey we are volunteers after all!

But now we call old and new forces to join efforts :

• If you are a former translator, already registered, and still willing to maintain your translation, please do your best to update within a decent delay. Keep on doing the good job!
• If you are a registered translator but for whatever reason not wishing to maintain your translation, send a PM to an admin to let us know and try if possible to find someone to take over, in your language forum on BabelZilla or by whatever other means. Thanks a lot!
• If you are new to BabelZilla and willing to start translation for your language, just register at the bottom of this page and do it!

It is a gecko engine propelled xulrunner. A quick look at the source code will tell you it is extensible just like other gecko-engined apps. Mr Glazman already conceived one Diavolo extension for his blazing new editor.

So we can expect one day to host some extensions to translate for this exciting new bird.

The logo is quite impressive, no doubt web designers will grab code fiercely with BlueGriffon claws!

logo for BlueGriffon (TM)