“It is difficult to translate something that you have never used before, functionalities that the translation team is not familiar with or English words that can be understood in several ways.”

His tool allows a localizer to add tags to each string so that when the localizer builds Firefox locally, they can see the translation with a tag in the UI.  If the translation seems incorrect in the context, the localizer can use the tag to find the file that needs adjustment.  See the screen shot below and check out his post for more information.

He will be blogging about his project on a regular basis, but he asked me to post the following initially to describe the idea:

During my internship at Mozilla last year, I developed a Silme-based “compare-locales” version. It is a command-line only tool, that requires from the user to have experience in working with a console. Well – we all know that a text-interface is not necessarily a user’s first-choice, so Axel came up with a great idea to develop a user-friendly graphical front-end for it.

Being back at my University, one part of my major is to work on a project, which may be done in cooperation with external companies. This project is officially scheduled for the term directly after the internship – that is, the chance to move Axel’s idea from the ‘ideabox’ to the ‘real’ world.  I see it as a great opportunity to continue my work on Mozilla L10n tools and my major at the same time.   Everything went quickly: Axel defined the project and its details, which was then accepted by my professor as an official university project. Together with my fellow computer science students, namely Adam Kowalewski and Florian Schloegl, we created a project team. And…

What exactly are we working on?

Calling the project just a “graphical interface for compare-locales” would underestimate the objectives we have set for it. It will be an extension for the Komodo Edit & Komodo IDE developer-editor/IDE applications, which are based on Mozilla technologies, that will help with the daily work of holding Mozilla localizations up-to-date. Starting with pulling Mercurial repositories, comparing the changes, showing that changes to the user directly in the work files, …, ending with helping during the translation process (e.g. translation-suggestions, syntax highlighting) and committing the changes back to a repository – everything in just one tool.

We named the extension “Koala”, which stands for “Komodo Advanced Localization Addon”.

More information will be available soon on http://koala.mozdev.org .

To accomplish the project, we have a September, 15 (2009 of course ) deadline. But you will hear of us sooner. Stay tuned.

Recently, Romi responded to a Google Summer of Code idea I had posted about helping to enhance Mozilla’s dashboard.  The l10n-drivers knew that this project was a bit of an imperative, so we decided to take on development within our team before we had any guarantee from GSoC if our proposal would be accepted.  (Some blog post about the dashboard vision and progress are coming from me and Axel.)  Given the amount of ambiguity on the resources Mozilla would commit to the idea, the GSoC proposal was rejected.

But, from the ashes came an idea to do a similar summer of code style project within Mozilla.  What if we could redirect Romi to do another experimental project that would have some benefit to the localization community?  Could Romi contribute to Silme by working on an implementation?  In the past, we’ve supported some of our tool authors with funding and development resources.  It turns out that Narro, another tool used by many of our localization teams, seemed like a good fit for the experiment.  Voila, a new proposal took shape.

I am pleased to announce that Romi will be working to integrate Silme, a library of localization scripts created by Gandalf, into Narro.  With Silme integration, we should be able to get exports of translated strings from Narro that are file-type independent (because Silme does that nicely) and can be used by the localizers and l10n-drivers to smooth out any commit bugs when it comes time to push changes back to the l10n code repositories.

Why is this important?

I’ve blogged in the past about the uniqueness of Mozilla’s DTD and property file types.  Our file structure and file types can create conflicts with the output people who choose to localize with tools send to us.  With Silme integration, we’ll have something that maps a bit more nicely to DTD and property files with less conflict.  You can read more about Silme on Gandalf’s blog, including this wiki page that describes what features we hope to add in the 0.7 release.

The early challenge for Romi’s project is going to be embedding a Python interpreter into Narro’s PHP code base  He researched a bit about PECL and will blog soon about his findings.  If you can provide any ideas on how to do this, Romi would love to hear your remarks.  We also have some stretch goals to hit if Silme gets integrated into Narro, and Romi will continue to blog about his progress, and those goals, over the next couple months.  Please welcome Romi when his first post to Planet appears and provide any advice you might have.

For an example, let’s take a look at French locale’s page.  Here you’ll see a section titled “Missing strings.” and another named “Strings identical to English.”  At the bottom is a link to the French translations of the strings in the fr main.lang in SVN.  At this page, a localizer has a basic snapshot of the state of their team’s web l10n.

I see some quick and direct benefits:

1. Localizers can now see very specifically what l10n strings need examination
2. New localizaiton teams who have finished localizing the Firefox product can see the the web localization tasks ahead
3. Mozilla improves its communication regarding what specifically needs to be accomplished for a version to become official

This is just another starting point.  We’ll have to work on unifying all of the recent improvements and forthcoming changes we’ll be seeing over the next couple weeks and months.  But, please find your locale of interest to see what needs to be investigated and possibly translated.

Thanks, Pascal.

He envisions hierarchical facets as a way to display the shipping information for our locales and I want to see his sketch of that.

I began to think that we might use this technique to organize the information on Mozilla’s localization dashboard more effectively.

Axel passed me this example, which I really liked.  I began daydreaming of something like this as a way to display the content on our dashboard.

Where I see…

…the “subject” section in this example, we could present “product” or “localization”…

…the “format” section, our dashboard would display whatever we didn’t choose in the “subject” section…

…opportunities for new sections (not seen in the example), we could display open bugs that could link to Pascal’s web-parts dashboard page, tracking bugs for finishing a localization, or Stas’s web services bugs.

…a real chance to daydream, we might display a fourth section showing remaining untranslated strings in a locale.

What other sections could we add?

Here’s a link to their Firefox extension.

You don’t have to speak Hindi, Marathi, Sanskrit, Nepali, Konkani, Sindhi, Kashmiri, Bengali, Gujarati, Punjabi, Tamil, Telugu, Oriya, Assamese, Kannada, Malayalam, Arabic or Urdu to see how cool or powerful this is.  But, if you do speak one of those 18 languages, now you’ve got a tool to help create content your constituents can read.  And, that’s thanks to Lipikaar.

I’m blogging about projects like Lipikaar and Heredict because I want to see how we can impact the web in new markets.  Localization is just one small piece.  With website evangelism and the ability to create content, users will start to see dramatic increases in what’s available to them on Firefox and on the Web more generally.

Please help spread this project around if you are in India or speak one of the languages listed above.

At the start, we did some initial introductions while we got ourselves technically situated.  During that initial go-round, we found that nearly 100% of the participants in the room had coding experience with C++, JS, HTML, XML, CSS, and more.  All used Firefox with several extensions.  A few had developed add-ons.  The audience had some great initial questions, teeing us up for an extra special afternoon.  Here is what took place:

*  Pascal Finette did an online Skype chat discussing the Mozilla Labs concept series
*  I spoke about Mozilla community and L10n
*  Arun gave a presentation with lots of demos on SVG, HTML 5, OGG video formatting

Frankly, I was blown away by Arun’s presentation.  This guy is good.  As a member of the Developer Relations team, he really showed excellent demos to this audience.  My favorite was probably an OGG formatted video with SVG and CSS overlayed.  The reaction by the audience, if I remember correctly, was a gentle “Oooohhhh!”.  The combination of his showing his excellent demos, explaining the technology, drawing laughs (when a man was shouting outside and Arun somehow thought he was getting heckled), and driving interaction with the audience really made the crowd squeeze the most out of the 2 hours he presented. Obviously they were impressed and I won’t be surprised to hear from Arun that a number of the developers emailed him to find out how to participate.

I focused on l10n and community development.  After I finished, one request I had for Mohak and his team was to use the Mozilla Community Sites project for Mozilla Camp Delhi.  Given all the excitement, I hope they’ll use the MCS to set up a point for community development and interaction here in Delhi.  I also handed out a number of cards to people who hope to look at and contribute to Silme.

In closing, the first event in India was a big success.  I am not sure we could have anticipated such enthusiasm or curiosity in Mozilla.  If you attended the event, please comment on my blog.  Tell me who you are, what you do, and how you want to get involved.  I’ve linked below to many of the topics I mentioned in my presentation and will post the slides soon.

Special thanks to Mohak for his efforts.  Well done!

http://contribute.mozilla.org
http://wiki.braniecki.net/Silme
http://diary.braniecki.net/tag/mct/

February 6 – 9:  FOSDEM in Brussels with many European localizers and open source developers
February 10 – 11:  Delhi, India for MozDelhi Camp
February 12 – 13:  Kanpur, India for FOSSkriti at ITT Kanpur
February 14 – 15:  Pune, India for GNUify
February 18 – 21:  Beijing, China with a big community event on Saturday, February 21 at the Mozilla office

On my journey through the subcontinent, I will be joined by fellow Mozillan, Arun Ranganathan.  When I separate from Arun, I’ll go to our China office in Beijing to visit Li Gong and the team and to present to the community there.

During our presentations, we will demo several tools for developers and localizers to use to expand their impact, build new community, and drive more mainstream adoption of Mozilla ideas.  It will be a breakneck pace and we are staying with friends along the way in hope to make this trip as leveraged as possible.  Many thanks to Shashank (FOSSkriti) and Harshad (GNUify) for providing me and Arun both transportation and accommodation at their respective conference locations.

My presentation has four sections, designed for easy plug-and-play, depending on the audience.  Here is what I plan to discuss on the quest.

1. Mozilla and Community overview, using localization efforts to illustrate the breadth of Mozilla’s community contribution.  I’ll present some interesting Firefox 3.1 localization participation statistics, including new languages since FF 3.0.
2. New Community tools, demoing Mozilla Community Sites project
3. Improving localization tools, recapping Verbatim, demoing Silme, and discussing new ideas
4. Where do we go next?  L20n demos

I’ll post the slides when they are ready.  They are still in pieces and demos are still being finalized.

https://wiki.mozilla.org/L20n

The introduction from that page is particularly helpful in describing l20n.  It opens with the following:

“L20n is the codename for a localization architecture taking existing approaches one step further. The name stands for l10n 2. The architecture is laid out with Mozilla applications in mind, but should be applicable to other areas as well. As for Mozilla, Mozilla 2 will give us a chance to implement significant changes in our l10n architecture, and this is one attempt to do that.”

It may come as no surprise, but Axel is mostly responsible for this TERRIFIC introduction and write up.  The wiki covers:

• Features
• Background
• Control Flow
• Design
• Examples and
• FAQ

I really suggest everyone take some time to read through this wiki to get a better sense of what l20n is and how to contribute.  Rather than try to rewrite something that is already superb, I highly suggest reading the background document linked to above (and again just now).

Let’s give a taste of just what l20n might be one day.  Here is some sample code from Axel that helps with plural forms:

<plural: (n) -> {n != 1}>

/**
 * Complex string
 * @param: beers
 */
<axel: "Axel had ${beers}i ${axel.bottles[plural(beers)]}s of beer." bottles: ["bottle", "bottles"]>

And the translation by a localizer:

<plural: (n) -> {n != 1}>

/**
 * Complex string
 * @param: beers
 */
<axel: "Axel hat ${beers}i ${axel.bottles[plural(beers)]}s Bier getrunken."
 bottles: ["Flasche", "Flaschen"]>

The nice thing here is that the code is flexible to provide for multiple plural forms.  Ping if you have a question.

Some really excellent demos are on the Examples link from above.  I will link to a few I liked here:

• Plural demo (just above)
• Declension demo

These are great because they show the power and flexibility of the code with a straightforward UI to go along.

There is so much fun to be had with l20n, I hope you take the time to go through this wiki, comment on it, blog about it, email me, etc.  We are not ready to implement l20n, but we are certainly ready to discuss.

Thank you to Axel and Gandalf for helping me with these posts.  Most of what I write is simply me learning new things and then rewriting.  I hope you can play along and get involved in the next generation of Mozilla l10n.

In some languages, words can have multiple forms depending on context.  What if the word for tab could be written as tab, tabs, tab(x), or [prefix]-tab where each form might be used depending on what a developer hopes to communicate.

Here is an example:

<!ENTITY tabsOpen1 “You have %1 tab open”>
<!ENTITY tabsOpen2 “You have %1 tabs open”>

In English, the UI is relaying to the end-user that he or she may have one tab open or more than one tab open.  Using Polish again, we can see that there are multiple forms depending on the context:  one kartę; two, three or four karty; or zero or five or more kart. In fact, the Polish grammar rule is much more complex than my explanation and I am sure I am missing all the rules, but you get the point.

See below:

<!ENTITY tabsOpen1 “Masz %1 kartę otwartą“>
<!ENTITY tabsOpen2 “Masz %1 karty otwarte“>
<!ENTITY tabsOpen3 “Masz %1 kart otwartych“>

See the problem?  Option three can and will never be used because the code only provides for 1 tab or [x] tabs.  So, Polish localizers are forced to create an artificial form like ” otwórz kart: %1″.  Once again, this is not really a pattern of natural spoken Polish.  It reads more as a representation of the database or something.

Challenge 4:  Localization in the broader sense

Sometimes in our UI, colors, icons, spacing allocated to certain words like “Firefox”, and more are hard-coded, limiting the ability for a localizer to change them to make more sense or work well in their localizations.  If those elements are not hard-coded, they can still be hard to change.  In those cases, a localizer can file a bug asking a developer to provide more options.

For instance, let’s say a developer uses the colors red and green to indicate success or failure when a user submits a password.  These colors might not mean anything in certain localizations.  A bug is then filed and a developer works to extend the options available to that localizer so it is more meaningful.  But this can be laborious, and is definitely not scalable.  Moreover, this new exception forces all other localizations to translate a new entity, even though it may not have the same level of importance (if any at all) in their home language.

Other issues to think about include languages that use right-to-left writing or languages that present their characters vertically rather than horizontally.  The examples are numerous and we can go through all of them, but I think you get my point.  Feel free to add your examples to the comments section of this post.

Next time, I’ll present a small piece of what could be the next generation of l10n.  You might think of it as Localization 2.0 or L20n.