Planet Mozilla L10N

Language can be very difficult to capture within software localization. Each natural language in the world evolves at its own pace and in its own unique way, creating vibrant and rich means of expression. Sadly, simple static string translation is often ill-equipped to properly accommodate gender, conjugation, plural, or case changes required within the language by changing string variables and other run-time string composition issues. This is why we created L20n.

We’re super happy to announce that we’ve released an amazing tool to help localizers, engineers, and localization tool developers learn and practice L20n themselves! l20n.org contains a real-time text editor that allows you to edit L20n code and visually see how it impacts localization. The real-time editor is part of the “Learn” section of l20n.org dedicated to walk you through what L20n has to offer, feature by feature, and give you a chance to try these features out in real-time.

L20n is a localization framework (comprised of a pseudo-programming language) meant to transfer the ability to localize software using the fullness of any language from the developer to the localizer. L20n empowers localizers to be more independent of source language developers and have more control and flexibility in localizing software according to their native language’s demands.

l20n.org is live and running now! Go give it a try! Not only is it live, but its hosted on github for you to fork and contribute to. Enjoy testing out L20n!

May 17, 2013 09:40 PM

Speed & memory:

• Fixed: 805241 - JS: Merge the new baseline compiler.
• Fixed: 804676 - JS: Remove dependence of Ion compilation on ScriptAnalysis::analyzeTypes.
• Fixed: 825928 - Graphics: Layers refactoring.
• Fixed: 865546 - Graphics: Large scaled images in SVG's cause choppy scrolling.
• Fixed: 854803 - Graphics: Images on slow network continously use 1 full core.
• Fixed: 600307 - Rewrite and cleanup DOMStorage code.
• Fixed: 566746 - Form history should use asynchronous storage API.
• Fixed: 697377 - Form Autocomplete should use asynchronous storage API.

For more, read Taras's Snappy blog and MemShrink blog posts.

New web technologies:

• Fixed: 765780 - Enable plugins and JavaScript in designMode.

For more, read Firefox 23 for developers.

Security & privacy:

• Fixed: 838692 - Don't allow navigating named targets from sandboxed iframes.
• Fixed: 549697 - Add click-to-play plugin UI to the addon manager.
• Fixed: 834836 - Turn on pref to block mixed active content.

Other notable fixes:

• Fixed: 858538 - Download-attribute kills WebSocket connections.
• Fixed: 560072 - Object.getOwnPropertyDescriptor throws for many DOM objects.
• Fixed: 485149 - Using box-shadow on a <fieldset> with <legend> does not follow box shape.
• Fixed: 857820 - Drop only blink effect from text-decoration: blink; and completely remove <blink> element.
• Fixed: 369180 - Proxy Authentication required while typing Search String.
• Fixed: 649216 - Remove unnecessary delay when clicking tab close buttons sequentially.
• Fixed: 636564 - [Mac] Lion-style floating scrollbars.

Sources:

• @FirefoxNightly on Twitter
• All 4828 changes between FIREFOX_AURORA_22_BASE and FIREFOX_AURORA_23_BASE

May 15, 2013 02:25 AM

April 08, 2013 08:41 PM

April 03, 2013 10:13 PM

Today we’re very pleased to announce the addition of three new locales to the Firefox Aurora channel: Azerbaijani (az), Burmese (my), and Sakha (sah).

Azerbaijani (az), also known as Azeri, is primarily spoken in Iran, Azerbaijan, Turkey, Armenia, Georgia, Russia, Afghanistan, Iraq, Turkmenistan, and Syria. Ethnologue reports that there are approximately 25,000,000 native Azerbaijani speakers. To help their localization of Firefox move to the Release channel, join the Azerbaijani l10n team.

Burmese (my), also known as Myanmar, is primarily spoken in Burma/Myanmar, Thailand, Malaysia, and Singapore. Ethnoloque reports that there were approximately 32,000,000 native speakers of Burmese in 2000. To help their localization of Firefox move to the Release channel, join the Burmese l10n team.

Sakha (sah), also known as Yakut, is spoken primarily in the Sakha Republic of the Russian Federation. Ethnologue reports that there were approximately 450,000 native Sakha speakers in 2010.

Congratulations to these teams! We look forward to seeing their hard work on the Release channel soon.

March 13, 2013 05:44 PM

February 19, 2013 06:53 PM

Let me share some recent revelations I had. It all started with the infamous Berlin airport. Not the nice one in Tegel, but the BBI desaster. The one we’ve thought we’d open last year, and now we don’t know which year.

Part of the newscoverage here in Germany was all about how they didn’t do any risk analysis, and are doomed, and how that other project for the Olympics in London did do risk analysis, and got in under budget, ahead of time.

So what’s good for the Olympics can’t be bad for Firefox, and I started figuring out the math behind our risk to ship Firefox, at a given time, with loads of localizations. How likely is it that we’ll make it?

Interestingly enough, the same algorithm can also be applied to a set of features that are scheduled for a particular Firefox release. Locales, features, blockers, product-managers, developers, all the same thing :-). Any bucket of N things trying to make a single deadline have similar risks. And the same cure. So bear with me. I’ll sprinkle graphs as we go to illustrate. They’ll link to a site that I’ve set up to play with the numbers, reproducing the shown graphs.

The setup is like this: Every single item (localization, for exampe) has a risk, and I’m assuming the same risk across the board. I’m trying to do that N times, and I’m interested in how likely I’ll get all of them. And then I evaluate the impact of different amounts of freeze cycles. If you’re like me, and don’t believe any statistics unless they’re done by throwing dices, check out the dices demo.

Anyway, let’s start with 20% risk per locale, no freeze, and up to 100 locales.

Ouch. We’re crossing 50-50 at 3 items already, and anything at scale is a pretty flat zero-chance. Why’s that? What we’re seeing is an exponential decay, the base being 80%, and the power being how often we do that. This is revelation one I had this week.

How can we help this? If only our teams would fail less often? Feel free to play with the numbers, like setting the successrate from 80% to 90%. Better, but the system at large still doesn’t scale. To fight an exponential risk, we need a cure that’s exponential.

Turns out freezes are just that. And that’d be revelation two I had this week. Let’s add some 5 additional frozen development cycles.

Oh hai. At small scales, even just one frozen cycle kills risks. Three features without freeze have a 50-50 chance, but with just one freeze cycle we’re already at 88%, which is better than the risk of each individual feature. At large scales like we’re having in l10n, 2 freezes control the risk to mostly linear, 3 freezes being pretty solid. If I’m less confident and go down to 70% per locale, 4 or 5 cycles create a winning strategy. In other words, for a base risk of 20-30%, 4-5 freeze cycles make the problem for a localized release scale.

It’s actually intuitive that freezes are (kinda) exponentially good. The math is a tad more complicated, but simplified, if your per-item success rate is 70%, you only have to solve your problem for 30% of your items in the next cycle, and for 9% in the second cycle. Thus, you’re fighting scale with scale. You can see this in action on the dices demo, which plays through this each time you “throw” the dices.

Now onwards to my third revelation while looking at this data. Features and blockers are just like localizations. Going in to the rapid release cycle with Firefox 5 etc, we’ve made two rules:

• Feature-freeze and string-freeze are on migration day from central to aurora
• Features not making the freeze take the next train

That worked fine for a while, but since then, mozilla has grown as an organization. We’ve also built out dependencies inside our organization that make us want particular features in particular releases. That’s actually a good situation to be in. It’s good that people care, and it’s good that we’re working on things that have organizational context.

But this changed the risks in our release cycle. We started off having a single risk of exponential scale after the migration date (l10n). Today, we have features going in to the cycle, and localizations thereof. At this point, having feature-freeze and string-freeze being the same thing becomes a risk for the release cycle at large. We should think about how to separate the two to mitigate the risk for each effectively, and ship awesome and localized software.

I learned quite a bit looking at our risks, I hope I could share some of that.

February 15, 2013 03:26 PM

January 28, 2013 04:23 AM

Testing and getting feedback about a localization’s linguistic quality is critical to delivering a browser that will meet users’ needs. We want to attract people in any region to the world’s best browser by making sure that it is the best localized browser available. The language availability and feedback mechanisms vary according to the language’s current status.

At Mozilla, we release Firefox desktop localizations in two ways: through language packs (also known as langpacks) and official builds. Before a language hops on the rapid release train to be distributed as an official build, it is distributed through the Firefox add-ons manager (AMO) as a langpack. L10n teams will update these langpacks as they progress with their l10n efforts. Users in that region (or users whose preferred language is found as a langpack instead of an official build) can download, install, and give feedback on the langpack’s linguistic quality all on the langpack’s AMO page. Here’s a list of all of the current localizations distributed as langpacks.

Official localized builds of Firefox desktop can be found here. These localizations have been technically evaluated by passing rigorous technical reviews. Although they’re on the rapid release train, these Mozilla l10n teams still benefit greatly from receiving feedback from their users. The best way users can provide feedback on a localization’s linguistic quality is to download and install the localized Firefox Aurora build and begin using it as their default browser. As users see translation errors they can log them in Firefox Input, located in the toolbar under Help > Submit Feedback. The Mozilla l10n team responsible for that localization can see their users’ feedback and then make corrections as needed.

Giving feedback is simple and can take as little time as 1-3 minutes to do. If you haven’t already downloaded and installed your language’s Firefox Aurora build or langpack, go for it! Your Mozilla l10n team will be grateful for your help.

January 23, 2013 11:06 PM

We work on two different cycles at Mozilla: a quarterly cycle (this is being posted in Q1) and a six week rapid release cycle. On a quarterly basis, the l10n drivers are responsible for setting goals for the progress they’d like to make on facilitating the localizer’s ability to get involved, the number of new locales we’d like to add to the shipping line-up, and the number of locales who, for one reason or another, have fallen behind and we’d like to help catch up. We attempt to make these goals based on what we assume to know about the l10n teams we’re working with, however, we’ve seen that we often don’t have enough visibility to accurately predict the number of new locales we’ll add to the shipping list or the number of locales that can catch up in a quarter. As you can imagine, these goals aren’t always met by the end of the quarter, largely because they don’t take into account the localizer’s schedule, commitment level, technical experience, or the l10n team’s goals. Well, we’d like to change that

This quarter, along with the l10n team health evaluations, we’d like to encourage all l10n teams to start setting quarterly goals with us and publishing them on their l10n team wiki page under this heading:

===Team quarterly goals===

What type of goals would a l10n team set?

Here’s an example of a l10n team’s quarterly goals:

===Team quarterly goals===
* Sign off on Firefox Beta channel by week 2 of cycle.
* Add Fennec to project's list and set goal for which release to ship 
fully localized Fennec.
* Catch up on Firefox Aurora backlog. Be ready to sign off and ship 
up-to-date localized Firefox desktop at version 22.
* Recruit 2 new localizers-in-training.
* Make sure all team members have profiles in Mozillians directory and 
are in both the l10n and l10n:[locale-code] groups.

How will this help my team?

Planning and goal setting not only help you and your team to be more organized and successful, but it allows you to identify areas where new contributors could pick up tasks and join the group. By publishing these goals on your team wiki pages, we’re able to see your efforts and help where we can. Plus, it helps us identify what excites and motivates you as a team. Maybe [insert motivator here, like competition, SWAG, events, accomplishment, etc.] makes your team excited to localize and proud to be part of Mozilla. Your transparent goals will help us to see that and respond in a more personalized manner to your needs.

Need help with goal setting?

If your team needs help setting goals, please reach out. I’m happy to help you focus your efforts and make goals that will improve your efforts. You can also explore the l10n teams directory and see what goals other teams have set and see if they also apply to you.

January 04, 2013 10:08 PM

Everyone is eager to get their hands on Firefox OS in their own language. Since Firefox OS will land in the Brazilian market first, localization is a very high priority. Some l10n teams have already hit the ground running with localizing Gaia. If you take a look at the Firefox OS project on Pootle, you’ll see that Fulah, Scottish Gaelic, and Welsh are already at 100% complete!

Of course we don’t want to stop there; we want everyone to be able to localize Gaia! But where do you start? What tool do you use? How can you test your work in Gaia? Those are the questions that we’re working on answering. In the next few months, we’ll be working on adapting the existing documentation to a wider audience and to our l10n documentation information model. We’ll also be updating it’s content. With this in place, anyone will be able to come in and localize Gaia into their own language!

If you have or are currently localizing Gaia and have already experimented with answering these questions, please get in touch with me (jbeatty [at] mozilla [dot] org) and I’ll be sure to add your experience and learning to the new Gaia l10n documentation.

December 12, 2012 08:32 PM

Good news, everyone! Gaia is now string-frozen. This means no more string changes nor additions. From now on, all bugs with l10n impact should have the late-l10n keyword and a review request on :stas.

The purpose of the string freeze is to stabilize the UI and give localizers time to work on and test the translations. Small changes to the English copy like typo fixes, grammar and (sometimes) style are usually fine to make even after a string freeze, but bigger ones will need to be reviewed for impact on localizations. Usually, it’s a matter of fixing en-US and breaking all other locales at the same time. Obviously, that’s something we’d like to avoid.

What’s new?

Both bucket 1 apps and bucket 2 apps are now string-frozen. We followed the style guidelines written by Josh and Matej and fixed many typos and inconsistencies in the UI. Most of these changes were English-only and the identifiers didn’t change.

You can see the diff in Mercurial or a summary of changes by Scoobidiver.

I finally added the possibility to localize manifest files. In each app’s folder you will find a manifest.properties file (see all). The strings there are responsible for the name of apps displayed on the homescreen and in the card view.

Lastly, some bucket 1 string-freeze breaking changes were hard to avoid. The affected apps are: browser, camera, clock, comms/contacts, comms/dialer, gallery, sms, video.

Here are the total stats as of today:

• 1828 strings, or
• 6091 words.

If your locale was green or almost green before this update, you’ll likely be at around 55-60% today.

Follow the instructions on the L10n:B2G wikipage to get started. The English files are in https://hg.mozilla.org/gaia-l10n/en-US/.

When are the translations due?

The deadline is December 17^th.

What’s next?

We’re making a lot of progress on producing nightly device and desktop builds. See the tracking bug 766962 and its dependencies, and also read the Testing section below.

There are still a few remaining late-l10n bugs, mostly related to legal, that didn’t make the string freeze and that we will want to fix in the near future (and thus, we will need to break the string freeze for them).

• Bug 814814: Don’t hardcode “Firefox” nor “Firefox OS”
• Bug 811677: Turn “Licensing” item into “Legal Information”
• Bug 802908: Change Settings > Help & Feedback feedback links

(You may also want to follow the l12y bugs which don’t have direct impact on translations, but are important to Gaia’s localizability.)

The roadmap

The roadmap for the next 1 or 2 weeks is as follows:

• localized desktop builds,
• a few more late additions listed above,
• more locales added to the build: bn-IN, gu, km, ne-NP, si, th, vi.

In the next few months we will be also focusing on localization of support articles, the marketplace and payment workflows, in-product pages and the dev hub at the marketplace.

Testing with the desktop builds

I know some of the localizers use the default desktop builds (with 4 locales enabled) and then follow the instructions on the wiki (DEBUG=1 make etc.) to test your localizations. If you’re one of them, then I have some news for you.

The good & the very good

The annoying bug which hindered testing on Linux has been fixed and has now landed on central, aurora and beta! This means that there should be no more need of my custom b2g builds.

Even better news: we’re making excellent progress on producing official localized builds. If you’re interested, follow these two bugs:

• Bug 812836: Set up nightly multilocale B2G desktop builds for l10n testing

• Bug 812829: Create Gaia build config to create multilocale profiles

It looks like we might be able to get those builds going next week!

The bad

The perf is better, and we’re about to start doing localized nightlies? What’s not to like?

Unfortunately, there’s currently a bug which breaks profiles made with DEBUG=1. I’m not 100% what’s the root cause, but I’m suspecting bug 802976 and bug 813900.

The workaround

If you run into the black screen bug mentioned above, you could try doing your l10n testing in Firefox, instead of a b2g desktop build.

Follow all the testing instructions on the wiki like you’d normally would. However, instead of running the b2g-bin binary with -profile, run Firefox. For instance:

/usr/bin/firefox -profile gaia/profile

A browser window will open and it will be black. This is a known issue. Just open a new tab and go to about:config. Look for intl.accept_languages and prepend your locale code to its value. So if you’re Polish, you’d do:

intl.accept_languages           pl, en-US, en

Then, browse to any app, for example:

http://browser.gaiamobile.org:8080/

And voilá! Use the Responsive Design Mode (Tools → Web Developer) to adjust the size of the viewport. You can even use the Inspector and try out different translations on the fly!

This is what running Gaia in Firefox might look like:

Discussion

Come to the mozilla.dev.l10n newsgroup if you have questions!

November 23, 2012 10:59 PM

November 19, 2012 11:33 PM

November 19, 2012 11:32 PM

• CSI:Mozilla / CrashKill:
  Filed a bug on sending an identifier with app crashes in B2G.
  Also filed a Flash beta crash.
  Discussed release channels for B2G and Socorro requirements.
  And we needed another Socorro data backfill, unfortunately.
  Added highlighting of the latest minor version of every Flash branch to the Flash hang overview reports.
  Also adjusted the limit values for the "Are We Stable Yet?" dashboard and converted some style attributes to classes in my reports.
  Had a long discussion with bjacob on getting new fields into Socorro data. We should find a way to make it easy to get new fields added in a way that (at least custom) reports can be generated against them, without using the mess that "App Notes" are right now.
  Followed the recent Flash crash spike.
  Did more monitoring of tracking+ crash bugs for 17.
  As usual, watched new/rising crashes, caring that bugs are filed where needed, and made sure my custom reports keep working well.
• Web Apps:
  Fixed some glitches in the improvements to the Mandelbrot app, but there seems to still be an issue with appCache - on my otoro device, I don't see the main index.html getting refreshed and so the app stops working.
  I also did quite a few updates to Lantea Maps, but now the map tiles seem to not load when appCache is active. Somehow I have a feeling that our techniques for offline apps are not working as well as they should.
• Various Discussions/Topics:
  B2G testing, Marketplace URL and branding strategies, etc.

November 14, 2012 02:25 PM

November 05, 2012 04:08 PM

• CSI:Mozilla / CrashKill:
  Filed a bug on an extreme spike in Flash crashes this week, apparently related to Zynga games.
  Also filed another bug on another aggregation data backfill needed in Socorro due to another late metrics data push.
  Monitored tracking+ crash bugs for 17, so we get the best stability we can in this release.
  Kept following the developments in B2G crash reporting, things seem to be moving forward nicely now.
  Did some maintenance on my custom reports.
  As usual, watched new/rising crashes, caring that bugs are filed where needed, and made sure my custom reports keep working well.
• German L10ns:
  Reviewed Firefox mobile and desktop localizations for the 18 cycle, and more Firefox OS strings.
  Tried fixing a hard to understand phrase in German SeaMonkey and fixed another small bug there as well.
  Checked in the sandstone theme for planet.mozilla.de - thanks to Jan for putting it together!
• Themes:
  Put some more finishing touches on the 2.14 version of my themes, esp. LCARStrek adaptiations for Social API support in Firefox.
• Web Apps:
  Worked on some improvements esp. for the Mandelbrot app, so it can save prefs (still need to figure out loading them in a quasi-sync mode) and have more of the settings the add-on version also has. Also started off the DB I'll need for bookmarks, even if there's no implementation of bookmarks yet.
• Various Discussions/Topics:
  B2G testing, B2G geolocation, platform meeting format, etc.

October 30, 2012 08:50 PM

• Create a central repository of common L20n files.
• Too much coding, localizers are not software engineers.
• Creatie a library of commonly used language macros for those who are not interested/able to create their own but still want to use L20n.
• GALA and others interested in helping to develop and standardize L20n.

• Go backwards: in an admin panel, the Pontoon could be able to show where the string displays in the interface (Adobe was doing something similar by md5-hashing strings).
• Character styles should be manageable when preforming in-context editing. Perhaps on the fly rendering of HTML added to the translated string.

• Both sessions received a lot of questions and interest. For our tools session, we had a Q&A session of about 30 minutes. We learned that this is apparently unusual for a LocWorld session. This session was considered one of the most engaging sessions of the whole conference.
• A room moderator and conference program scheduler for LocWorld wants to institute an open source track for next year.
• There are some industry publications and research firms interested in adding the Mozilla & open source perspective to their publications. We’ll have more to tell you about that in the future.
• Several amazing organizations have expressed interest in contributing and collaborating with Mozilla and our l10n teams. Some of these are Translators without Borders, Amazon, and some language services providers (LSPs).
• Overheard in the audience about Pontoon and L20n: “This is the future of l10n!”
• The official theme of the event was ‘mobile,’ but all you could hear people talk about was crowdsourcing and community localization

October 25, 2012 09:10 PM

• CSI:Mozilla / CrashKill:
  Went through all the tracking+ crash bugs for 17, 18 and 19 that are not fixed in those "trains" right now, and cared that they are updated and patches get uplifted where possible.
  Kept tracking B2G crash reporting, the things we need are all moving forward right now.
  Tested reporting of content crashes from B2G phones.
  Did some small patches to keep my custom reports working well.
  Had some discussions on possible Socorro improvements.
  Filed a bug on better signatures for aborts.
  As usual, watched new/rising crashes, caring that bugs are filed where needed, and made sure my custom reports keep working well.
• Various Discussions/Topics:
  B2G testing, Italy workshop, plugin crashes and URLs, Linux OMTC, click-to-play blocklisting, web app submissions, B2G L10n, etc.

October 25, 2012 02:09 PM

• CSI:Mozilla / CrashKill:
  I created another patch for updating correlation versions and pushed for getting it shipped in the same week to fit the Firefox code uplifts.
  Filed a bug for backfilling Socorro data once again after a late ADU push.
  Again more talk and driving to move B2G crash reporting forward on multiple fronts, a number of pieces did, completing what we need for v1 is now underway.
  Added display and linking of tracking bugs to the arewestableyet.com dashboard.
  Made my report somewhat more robust against errors.
  As usual, watched new/rising crashes, caring that bugs are filed where needed, and made sure my custom reports keep working well.
• German L10n:
  Synched Nightly and Aurora for the 18 channel.
• Various Discussions/Topics:
  OMTC for Linux, All kinds of B2G testing, Italy workshop, etc.

October 18, 2012 11:33 PM

• CSI:Mozilla / CrashKill:
  More talk and driving to move B2G crash reporting forward on multiple fronts: crash annotations, content crash reporting, UX implementation, about:crashes.
  Started following bugs on making B2G use less memory, which reduces the probability of out-of-memory crashes.
  Tracking stability of Firefox 16 for desktop and Android in preparation of the release.
  Following the progress and fix to the large crash issue we had on CyanogenMod 10.
  Tried to push for a fix for wrong daily crash numbers for Android on Socorro.
  Switched arewestableyet.com dashboard to displaying Flash crashes and hangs per 100 ADU.
  As usual, watched new/rising crashes, caring that bugs are filed where needed, and made sure my custom reports keep working well.
• German L10n:
  Reviewed Firefox for Android 17 L10n, some fixes for de as well as a first German Firefox OS L10n.
  Updated suite and core L10n on trunk in preparation of the uplift to Aurora.
  Updated the German dictionary add-ons to be installable without a Firefox restart and incorporate the newest upstream dictionary files.
• Web Apps:
  Added OpenGeoServer Aerial layer to Lantea Maps, corrected the copyright notices for multiple layers, and added DOM full screen support to that app.
• Themes:
  Put some finishing touches on the 2.13 versions of EarlyBlue and LCARStrek, matching the Mozilla 16 train, and uploaded those. They're waiting for AMO approval now.
• Various Discussions/Topics:
  OMTC for Linux, icon sizes on Gaia, Flash stability, Vidyo stability, Italy workshop, etc.

October 09, 2012 08:14 PM

We’re happy to announce that we’re adding new localizations towith the release of Firefox 16 desktop.

The Kazakh (kk) and Acholi (ach) teams have been working tirelessly to produce the world’s first ever Kazakh and Acholi versions of Firefox desktop for native speakers of the languages wordwide. According to our friends at Wikipedia, there are more than an estimated 10 million native Kazakh speakers and 1.22 native Acholi speakers around the world. Native Kazakh speakers can be found in Kazakhstan, China, Mongolia, Afghanistan, Tajikistan, Turkey, Turkmenistan, Ukraine, Uzbekistan, Russia, and Iran. Native Acholi speakers can be found in Uganda and South Sudan. Thanks to these teams and their efforts, more than 11.22 million native Kazakh and Acholi speakers can now enjoy the option to browse the Web with Firefox 16. The release of a these Firefox desktop localizations brings our total number of regularly shipped languages to 80. Congratulations to the Kazakh and Acholi l10n teams!

We also want to thank all of our l10n teams for their consistent, dedicated efforts to bring the latest innovations of the web to the people of their regions.

See all the different language versions at https://www.mozilla.org/en-US/firefox/all.html.

October 09, 2012 02:36 PM

There are a bunch of new teams out there who have been waiting on progress. Sorry for the wait, but here’s what you’ve been waiting for.

We changed a few things around releasing new localizations. Many things did not change, but I’ll start off with the new.

We’ve redone the process points from review request to being on the rapid release cycle. The purpose was to put less emphasis on the bugs and the technical details, and more emphasis on the l10n dashboard.

We hope to get to a point where localizers are working on the aurora branch on each cycle, and the contribution gets wider testing on beta, and then seamlessly goes to release. We want to have most things lined up before going into aurora and having aurora ready in one 6 week period. Then migrate to beta, get wider testing, and on the same version go to final, if the community review passes.

To do that we did the following:

• dropped the requirements to have new contributors do search engine patches, etc. We’ll need your input on what services to hook up, but Milos will do the technical implementation. We also call these “productization bugs”.
• be more crisp on what’s required on the web site. Sure, you can do more, but we’ll set you up with what’s required, and nothing more.

And again, we put your team page front and center. That’s where you find what’s up to do, in the initial phase and beyond as we move from one cycle to the next.

Things that did not change:

• We still only start taking your contributions upstream if they’re close to done. We don’t have a setup where we can take the first 20% and then care or not.
• The tooling story is as difficult as before. Right now, narro is tougher than the locamotion (Pootle) setup, but none are without serious caveats.

The next batch of localizations we’re taking is going to ride along Firefox 18, coming on to Aurora next week.

October 05, 2012 07:31 PM

Part of a series similar to the Awesome L10n Communities series where individual contributors are spotlighted for their efforts.

Started with Mozilla project: Firefox
Nationality: Senegalese/Mauritanian
Languages: Fulah (Pulaar-Fulfulde), Wolof, Arabic, Soninke, French, English, Spanish, survival Italian
Background: I studied Applied Linguistics, Language  Teaching Methodology, Translation and CALL (Computer Assisted Language Learning) at Moray House College in Edinburgh, Scotland.

My team and I have been involved in Fulah translation and localization as well as promoting the language on the Internet (www.pulaagu.com). In 2009, I led the Fulah teams on the 100 locales program and successfully completed the work for locales for Fulah_sn, Fulah_mr, and Fulah_gn. I also created most Fulah terminology for ICT, especially Firefox terminology.  Fulah is not a well-resourced language and almost everything had to be created from scratch. But we have implemented a method of creating terminology that respects consistency and coherence.

I started translating Joomla and other open source CMSs. Then I discovered Tuxpaint and started translation with PoEdit. In 2009 I completed the Fulah part of the “locales for 100 African languages” project. I was also involved in translation of Pootle’s basic terminology and Pootle server into Fulah.

Our biggest achievement yet is the localization of Firefox in Fulah which is released this summer (2012).

I have worked extensively on font creation, keyboard layouts creation and I am planning to build a  physical “pan-Senegalese/Mauritanian” keyboard usable to type Fulah,  Wolof, Soninke, Sereer. I speak, read and write English, French, Fulah (Pulaar-Fulfulde) Mauritanian Arabic, and Wolof. I read and write Spanish, some Italian and Arabic.

I like web and graphics design and when I have time, I write news articles for my website in Fulah (www.pulaagu.com), the first website ever in the Fulah language and the most visited. I use the Internet daily as administrator of two websites and a community blog and my personal blog, all of these dedicated to the Fulah language and culture.

Role in L10n community:
Fulah localisation team lead and major contributor (95% of Firefox). SUMO contributor and KB l10n. Created most of Fulah Internet and IT terminology from scratch.

Projects you’re currently working on:
Firefox, SUMO KB, “50 videos for mastering Firefox in Fulah”, Firefox OS localization (unofficially).

I usually say I have been a localizer ever since because as a kid (from 8/9), I used to translate letters written in French for Fulah speakers who are illiterate. But I started the Firefox project with ANLOC (African Network for Localization). After successfully completing the localization of many other projects like TuxPaint, Abiword, Virtaal and Pootle, Dwayne Bailey from Translate.org.za proposed to localize Firefox. We could not believe it since I have always been a true believer in open source but also a user of Firefox since early releases.

I was not afraid of big projects, so I tried to get a few people from Fulah communities together to start working, but many were either not motivated or have not enough knowledge of IT. Since 95% of IT related terminology had yet to be created, I thought I would start the work and show people that nothing is impossible. It is only when the first early screenshots of the Firefox interface in Fulah were published that many joined. Dwayne created language packs so we could test our Firefox locally, and that has definitely triggered major interest in the Fulah community.

As I mentioned earlier, we had a real chance to have Dwayne Bailey helping out should we have any issues to deal with, and it is Dwayne who runs and manages the Pootle server we are using for the localization work. Pootle has fantastic built-in features for checking errors, bugs and other terminology related issues. With the translation memory, it is a lot easier to manage terminology consistency and Pootle does that really well.

So I would say that Dwayne’s help has been crucial and I learned a lot from him and also Friedel Wolff, one of the authors of Virtaal.

Fulah has a huge contributor potential because we are very “language conscious” people. Many Fulah people living in those twenty countries have strong feelings about being a Fulah, and the language is what makes us feel we belong the same people, although we are nationals of many countries.

Unfortunately, the Internet is the only way we can communicate and that is not yet considered as “real.” You have to meet people in person, convince them to work as volunteers, then train them to use all these tools. Recruiting is quite easy, but most who are really fluent in Fulah are not necessarily motivated to spend hours working for free! Or they just cannot access the Internet at home or maybe just don’t have a personal computer.

I am planning a number of l10n workshops in France, Senegal, Mali and Mauritania to trains SUMO volunteers. Most of the potential and actual contributors live in Africa. So it is not very efficient to just use email as it is too “unreal” and distant to get people to really feel they are involved. I hope Mozilla will help achieve this. Basically, contributors are there but you have to reach out to them in a more humanized manner to motivate them even more.

Usually those who are involved already know me from other contributions to Fulah digitization, codification and promotion. So it is usually an honor for them when I contact them to ask them to work for Firefox. But again in my culture, you really need to meet people to establish a real contact and show them you are there to help, train, and support.

But I must say it is very hard to get people to work for free when they are struggling to make ends meet. So [I try] to have a personal relationship with them, [which usually leads to us] becoming friends. I call them quite often and not only to talk about contributing. That is the best way of having them around even when they are not really contributing.

But the most efficient way of mentoring them is to show them that they can do things and that they should not be afraid of all these tech terms they are not very familiar with. They can call me, invite me to talk on Skype, or post on my Facebook wall.

Since people are working as volunteers, you need to constantly make them feel they are actually making a difference no matter how much they contribute.

I think my personal motivation helped me a good deal in going ahead with the Mozilla project. So to keep motivation at a satisfactory level, it is important to adopt a effective strategy to make the work less tedious. As for Fulah, I could certainly not have been so successful [had I] not used Pootle server and Virtaal (translation editor).

Since Virtaal is an offline editor, I used it for translating .po files then checking errors offline before uploading to the server (Pootle). Then we can use Pootle to make the usual checks. So Pootle and Virtaal are really efficient tools that allow you to adopt a workflow that makes the task less scary.

As a team lead, I worked very hard to complete the biggest files to motivate others. So being the biggest contributor is also a good way of boosting others’ motivation.
Finally, in any type of work, being organized is a key strategy. When you start a huge project like Firefox l10n, you live in doubt whether you are fit for the job or not. You think you will never finish and soon wonder if it is worth carrying on something that will never end. What I believe is you have to fit the project into your everyday life.

• Start with biggest files/folders (things become easier and easier…).
• Work at regular times.
• Discuss issues on a daily basis with other contributors.
• Use a mailing list to communicate daily.
• If you can, meet on Skype regularly and encourage each other.
• After release, translate updates the day you are notified, don’t postpone.

These are just what worked for me and I hope it will help others to start, complete or update their localization. And I one day, I got this message from Milos Dinic:

Thanks folks,
I just want to say we’re happy how things are evolving and that Fulah is one of the very few locales that we’re releasing in one train (started in aurora with Firefox 14, moved to beta in Firefox 14, and releasing in Firefox 14).
So, yes, we’re releasing Firefox in Fulah in this cycle, and I’ll close the tracking bug past the release (July 14).
Keep up the good work!

These are the most beautiful words I have heard recently and I was speechless when I read that jaw-dropping news that drove me to tears.

Since we have completed Firefox with such efficiency, my objective this year and in 2013 is to hold talks and organize workshops in Africa to recruit dozens of contributors  and spread the word about Firefox and Mozilla products.

I’d like to do so by attending major cultural events like the Blues du Fleuve festival which is organized by Senegalese world music superstar Baaba Maal, humanitarian activist and Global Ambassador for OXFAM (www.baabamaal.tv) or the Water Festival in the same region.

Good question! Firefox OS!! Localization for Firefox OS is something that I am ready for and jsut too excited about. You know for a people that are divided into 20 countries, life is the web and the web in African is mobile, and mobile it will remain. So Mozilla you know what’s next now…

1.  Because of my commitment to making Fulah a fully digitized language, many call me “tear wiper.”
2. At the age of eight, I walked 5 kilometers (there and back) a day to go to school from my uncle’s home (did that for 2 years). On Saturdays, another 11 kilometers back to my parents’ village where there were only 2 classrooms! And back on Sunday to my uncle’s who lived “only” 5 km away from my school.
3. I am a weird ambidextrous (left and right handed) but I am also able to write in both directions with either hands. That’s not all: I can write simultaneously with both hands, in opposite directions but it has to be the same text!
4. I am a freelance journalist writing news articles in Fulah for my website www.pulaagu.com.
5. I am a veteran Flight Simulator enthusiast and have been flying hardcore for many years. Just love aeronautics, flying, planes, airports, etc.

October 03, 2012 05:23 PM

• CSI:Mozilla / CrashKill:
  Sending Gecko crashes on B2G now works in a first stage! I submitted a few crashes myself in testing the system.
  I continued to talk with people about getting further steps (see tracking bug), including a discussion with dbolter, who is helping with driving this.
  Had some discussions on wireframes for the B2G crash reporting UI.
  Discussed crash annotations for B2G with Hub.
  Filed a bug on missing Socorro data one day.
  Also filed bugs on enablid "by build date" reports for Android and about missing aggregated data on recent Nightly crashes for Android in some views.
  Removed some outdated versions from my reports, including most of Fennec XUL.
  Also created some commandline overrides so I can regenerate data for reports more easily.
  As usual, watched new/rising crashes, caring that bugs are filed where needed, and made sure my custom reports keep working well.
• German L10n:
  Done some reviews for German L10n work.
  Synched core, suite and Chatzilla L10n with trunk.
• Web Apps:
  Added a TODO for Lantea Maps so both myself and potential contributors know what needs to be worked on.
• Various Discussions/Topics:
  B2G Geolocation problems (now solved), B2G crashes when setting wallpaper, etc.

October 03, 2012 05:09 PM

Good news, everyone! The first string freeze for Gaia is now in effect.

Thanks for waiting patiently as we polished the final wording. Read on to find all the answers you might have about how to jump straight into the work.

Which apps are string-frozen?

This is the first string freeze (there will be a second one in October) and the list of apps that you can start working on (the “bucket 1”) is as follows:

• Apps

  • Browser
  • Camera
  • Clock
  • Communications/Contacts
  • Communications/Dialer
  • FM Radio
  • Gallery
  • Music
  • SMS
  • Video

• System - Keyboard

See https://wiki.mozilla.org/L10n:B2G for details.

How many strings are there?

It’s 366 strings, with a total of 868 words. Not so many :)

How much time do we have?

You have until October 26th to complete this batch.

Where are the files?

The files live in Mercurial in the special gaia-l10n hierarchy. One unusual change from the regular Firefox workflow is that the en-US files can also be found in gaia-l10n. Remember to clone via SSH, for instance:

hg clone ssh://hg.mozilla.org/gaia-l10n/pl

You can use compare-dirs (pip install compare-locales will get you compare-dirs, too) to see the stats.

Some locales will see some strings localized, taken from the git repository. If you’re one of those locales, please review all the existing translations carefully.

This is important! If you worked on Gaia l10n before the string freeze, please make sure your translations are up-to-date. English strings may have changed!

What about the dashboard?

You can see the compare-locales output on your locale’s team dashboard (the example I linked to is for Polish). (We’ll make it look nicer.)

If you can’t see Gaia in there, sign up on the community-gaia-list etherpad and we will hook your locale up.

Sign off when you’re done and have tested your work.

How to test my localization?

Use a desktop build! See the quick & dirty instructions to get started. If they don’t work for you, email me or talk to me on IRC. With your help, I can make this HOWTO much more robust and accurate.

You might also want to check out my two blog posts: Running Boot to Gecko on your desktop and How to test localizability of Gaia system apps.

Going beyond Bucket 1

What else is in store? There will be a second string freeze, expect updates on the schedule. And we’ll also soon start the localization of the Gecko part of Firefox OS, taken from mozilla-aurora. Think netError.dtd, global.dtd, intl.properties etc. Most of that already exists in mobile/ so I don’t think there will be a lot of work there.

I’ll also post about the nightly builds once we start makig them.

Questions?

Impossible, I thought I covered everything! :)

Please do ask questions in the mozilla.dev.l10n thread or on IRC. This process is an interesting mix of old and new. There might be hiccups along the way, but my goal is to make it as smooth as possible. I’ll appreciate your feedback and ideas!

September 28, 2012 05:47 PM

• CSI:Mozilla / CrashKill:
  More testing of Firefox OS on my otoro and trying poking people so we get crash reporting working.
  That work on B2G crash reporting included a conference with UX and privacy teams on what the flow of crash reporting should be for users in a way that we respect their privacy (i.e. enable a really informed opt-out).
  Followed how the Socorro team fixed two bugs in their recent release and deployed those fixes fast, also helped testing that those worked.
  Filed a bug on getting more resilient against late ADU pushes again.
  Had some discussions on crashes with CyanogenMod.
  Added bug IDs to my topcrasher reports for ARMv6, Win8 and Mountain Lion.
  Watched data for the new Flash release coming up that week.
  As usual, watched new/rising crashes, caring that bugs are filed where needed, and made sure my custom reports keep working well.
• German L10n:
  Done some reviews for German L10n work.
  Synched core, suite and Chatzilla L10n with trunk.
• Web Apps:
  Made Lantea Maps available on GitHub, updated its screen shots on the Mozilla Marketplace, and did a blog post inviting contributions.
• Various Discussions/Topics:
  UA strings and hardware tokens, B2G wallpaper customization, Mozilla Dino head, etc.

September 27, 2012 11:31 PM

September 27, 2012 09:36 PM

Language packs are add-ons that you can install to add additional localizations to our desktop applications.

Starting with tomorrow’s nightly, and thus following the Firefox 18 train, language packs will be restartless. That was bug 677092, landed as 812d0ba83175.

To change your UI language, you just need to install a language pack, set your language (*), and open a new window. This also works for updates to an installed language pack. Opening a new window is the workaround for not having a reload button on the chrome window.

The actual patch turned out to be one line to make language packs restartless, and one line so that they don’t try to call in to bootstrap.js. I was optimistic that the chrome registry was already working, and rightfully so. There are no changes to the language packs themselves.

Tests were tricky, but Blair talked me through most of it, thanks for that.

(*) Language switching UI is bug 377881, which has a mock-up for those interested. Do not be scared, it only shows if you have language packs installed.

September 27, 2012 11:04 AM

L20n’s JS lib is getting test cases and better documentation to make the code easier to work with and understand.

The JavaScript implementation of L20n is composed of 4 main components:

• context (stas), which handles resource loading, locale fallback and provides an easy pulic API for getting translated strings by identifiers,
• parser (gandalf), which parses the resources downloaded by the context into an AST,
• compiler (stas), which takes the AST and makes it into JavaScript objects which the context can call to get translated strings,
• and finally, HTML bindings (gandalf), which extend HTMLDocument with a default L20n context capable of automatically loading resources specified via link elements.

At this point, we’re almost feature frozen for all of these four components. We’re fixing bugs and making sure the public API is consistent and understandable.

Last two weeks saw us working hard on the context part. We finished a major code refactoring and introduced a robust locale fallback, which I’ll blog about in a future post.

Testing with Mocha

Another important improvement introduced recently was the addition of a full-featured testing framework, Mocha. We’ve written over 200 test cases for the compiler and currently we’re creating more tests for other components. As an nice bonus, Mocha also gives us beautiful test coverage reports.

Mocha is based on node.js, so we had to make a few small modifications to the codebase in order to support it. For example, we make use of node-XMLHttpRequest to mimic the XHR interface available in the browser.

Project page on GitHub

We created a GitHub page to serve as the entry point for all of the docs that we’re writing. Check it out at l20n.github.com/l20n.js.

We use excellent Docco to generate documentation from the comments in the code. See the compiler docs for an example.

September 24, 2012 10:26 PM

The JavaScript implementation of L20n is composed of 4 main components:

• context (stas), which handles resource loading, locale fallback and provides an easy pulic API for getting translated strings by identifiers,
• parser (gandalf), which parses the resources downloaded by the context into an AST,
• compiler (stas), which takes the AST and makes it into JavaScript objects which the context can call to get translated strings,
• and finally, HTML bindings (gandalf), which extend HTMLDocument with a default L20n context capable of automatically loading resources specified via link elements.

At this point, we’re almost feature frozen for all of these four components. We’re fixing bugs and making sure the public API is consistent and understandable.

Last two weeks saw us working hard on the context part. We finished a major code refactoring and introduced a robust locale fallback, which I’ll blog about in a future post.

Testing with Mocha

Another important improvement introduced recently was the addition of a full-featured testing framework, Mocha. We’ve written over 200 test cases for the compiler and currently we’re creating more tests for other components. As an nice bonus, Mocha also gives us beautiful test coverage reports.

Mocha is based on node.js, so we had to make a few small modifications to the codebase in order to support it. For example, we make use of node-XMLHttpRequest to mimic the XHR interface available in the browser.

Project page on GitHub

We created a GitHub page to serve as the entry point for all of the docs that we’re writing. Check it out at l20n.github.com/l20n.js.

We use excellent Docco to generate documentation from the comments in the code. See the compiler docs for an example.

September 24, 2012 10:23 PM

I am very happy to announce that @mozilla_l10n is officially live!

Here’s what you can expect from following @mozilla_l10n:

• Event/deadline notifications and reminders,
• Public welcome to newcomers,
• Calls for participation in new projects,
• Recruitment calls for specific l10n team needing more members,
• Congratulations to specific contributors and communities for reaching various milestones,
• Brief updates to external sources about all of our l10n advancements and efforts.

In brief, this handle is for you! Let us know if there are specific announcements you’d like to be tweeted. Need more localizers? We’ll tweet about it! Having a l10n sprint to get your channels up-to-date? We’ll tweet about it!

If you’re a fellow tweeter, please follow us and encourage your fellow localizers to do the same.

September 21, 2012 04:38 PM

• CSI:Mozilla / CrashKill:
  I continued testing Firefox OS on my otoro and tried poking people so we get crash reporting working.
  Checked how crash reporting works after breakpad was turned on in device images - and found that they are generated but not sent as online detection had been backed out again.
  Had some conversations on further build-side steps to make B2G vcrash reporting useful.
  Tested the new "mobeta" release of Socorro on stage, watched it being deployed on production, and tested there again.
  Filed a bug on missing data after that deployment, and another one on incorrect daily numbers which I missed in stage testing and only discovered in production testing.
  Discussed adding Metro Firefox to Socorro.
  Commented on about:crashes for Firefox OS.
  As usual, watched new/rising crashes, caring that bugs are filed where needed, and made sure my custom reports keep working well.
• Various Discussions/Topics:
  MozCamp Warsaw, etc.

September 20, 2012 10:30 PM

As work on Gaia move forward, we are now getting ready to start the localization efforts. There will be two string freezes for Gaia, with two buckets of apps, each freezing at a different time.

The first string freeze is coming this Friday, September 21st.

We were able to stabilize 14 apps out of 20 that constitute Gaia. Some of the bigger apps, like Email, Calendar, Settings and System are not ready yet in terms of features and UI at this point, but we decided to seize the opportunity to start the localization early with apps that are stable and finished.

The first bucket of apps

The apps string-freezing this Friday, or the first bucket apps as we have dubbed them, represent around half of all the strings that will eventually be part of Gaia. In terms of numbers, we’re talking less than 400 strings freezing this Friday, and the remaining ~400 freezing sometime at the beginning of October.

You will have until October 26th to complete and test your translations. That’s 5 full weeks!

Increasing the participation

By opening up the localization effort to everyone, we’re creating a place for you to play. We want you to test localizability, come up with new vocabulary, grow the community and evangelize third-party webapp developers. Show the world that you’re interested!

That said, the first devices will be shipped in Latin America, and there is no guarantee that we will be able to ship your locale on the actual device anytime soon. This is important to understand and we want to set the expectations very clearly. (And yes, we have learned from the Fennec experience, thanks for asking :) )

What it’s going to look like

Thanks to the collaboration between the Gaia team (especially Kazé and Vivien), as well as the Releng team (John and Hal), we will be able to use our regular workflows and tools. The localization files (.properties) will be stored in Mercurial, in http://hg.mozilla.org/gaia-l10n/. Note that not all repositories have been created at this point, see bug 768373 and bug 792593 for details.

The localization dashboard will show compare-locales statistics for your locale, too.

Some of the string will need to be localized in Gecko, i.e. in mozilla-central or mozilla-aurora (think netError messages). Expect more updates about this soon.

We will be also working on getting localized builds out the door.

Stay tuned

I will post more details on Saturday, with the exact list of apps that are string-frozen, specific cloning instructions and a testing guide. For now, just stay tuned! It’s an exciting moment for Mozilla’s l10n community!

As always, feel free to post in mozilla.dev.l10n if you have questions, or ping us on IRC.

September 20, 2012 01:55 PM

September 18, 2012 10:16 PM

J'ai fait une petite vidéo de démo de l'utilisation du serveur web intégré dans PHP 5.4, vous la trouverez ici :

September 16, 2012 07:55 PM

• CSI:Mozilla / CrashKill:
  Did some testing of Firefox OS on my otoro device, saw that it has some crash issues right now but reports are not sent atm, went on to figure out what we need to do to get them working. I posted a summary of the current state and road forward to the stability list and Dietrich.
  Followed Socorro getting ready for the "mobeta" push to production.
  Also followed their next big step - rewriting the UI in django.
  Did some preparation for the MozCamp session I did with bsmedberg, and attended the event, of course.
  As usual, watched new/rising crashes, caring that bugs are filed where needed, and made sure my custom reports keep working well.
• Web Apps:
  Did some style improvements in both apps for really small screens, like the otoro one. Also tested the apps on Firefox OS, and was surprised how smoothly Lantea Maps works there already.
• Various Discussions/Topics:
  Trying to figure out how to get builds onto the otoro, mobilizing Mozilla at MozCamp Warsaw, etc.

September 12, 2012 08:20 PM

MozCamp EU 2012 is just around the corner and it just wouldn’t be MozCamp if the L10n Drivers didn’t host a variety of sessions dealing with current l10n topics.

As you may know, the MozCamp session format is being reinvented. Each session is now meant to be a workshop. This means that rather than having one person presenting on a topic while the audience listens, the presenter and audience focus on a clear, deliverable objective and produce something together. This new approach gives us a rare opportunity to get deeply involved in your localization effort.

In addition to the approved set of sessions, there will be breakout l10n sessions on Sunday morning in the common hang out area. Below you’ll find a list of both the approved sessions and the “impromptu” breakout sessions. Hope to see you there!

Approved sessions

• Pontoon
• Firefox L10n Under Rapid Release
• B2G Localization Workshop
• Onboarding New Localizers to Your Community
• Efficient Localization with Translate Toolkit

Breakout sessions

• Social Localization with Verbatim
• SUMO L10n Organization & Tools
• Localizing MDN

September 07, 2012 06:16 AM

• CSI:Mozilla / CrashKill:
  Continued keeping track of Flash 11.4 stats - uptake is quite slow for this one.
  Followed the progress on B2G crash reporting, noted another needed mozconfig change in the releng bug.
  Followed the landing of the Socorro update for correlation versions.
  Took care that my custom reports run for the new versions appearing this week.
  Created a report to run for per-OS/per-arch topcrashers.
  As usual, watched new/rising crashes, caring that bugs are filed where needed, and made sure my custom reports keep working well.
• German L10n:
  Did the uplift/merge of central and aurora for the Mozilla 17 cycle.
  Made sure venkman and ChatZilla are in the right states for both central and aurora.
• Themes:
  While the 2.12 versions of EarlyBlue and LCARStrek are public on AMO now, I started work on the 2.13 versions (and fixed a bug seem in Firefox's Clear History window).
• Various Discussions/Topics:
  Following my otoro being shipped, importance and success of stability efforts, Mozilla Marketplace, etc.

September 06, 2012 12:19 AM

For the longest time we have used an icon of a sphere made up of many of the world’s flags to identify the l10n program. With the change to the new One Mozilla theme on all mozill.org websites, we thought it was time to modernize and re-brand the program that puts users first, no matter where they are (or what language they speak).

Behold, the new icon for Mozilla l10n!

August 31, 2012 10:48 PM

August 29, 2012 05:05 AM

• CSI:Mozilla / CrashKill:
  Kept track of crash/hang stats regarding the Flash 11.4 release - looks like they improved on crashes somewhat, but not too much on hangs.
  Cared that another patch for correlation versions makes it into Socorro for release week.
  Stayed in the loop on getting B2G crash reporting up - basic Socorro support now landed, but channel/symbol corrections are needed to improve on that.
  Converted my device crash report to using the DB instead of CSVs, that means that now all my reports feed from PostgreSQL and are off the CSVs.
  Kept track of trunk crash regressions so we hopefully don't carry them into Aurora.
  Poked people about high-profile crashes in Firefox 15 for Android and managed to get them to push the fix into the last beta.
  Also poked people about another Android crash, which isn't new for 15, though, and will only be fixed in 16.
  Brought Naoki up to speed on B2G crash reporting and mobile crash developments in his absence.
  As usual, watched new/rising crashes, caring that bugs are filed where needed, and made sure my custom reports keep working well.
• German L10n:
  Reviewed the rest of L10n work for Firefox 16.
  Also brought core and SeaMonkey into sync with trunk in preparation of the uplift of 17 to Aurora.
• SeaMonkey:
  Tested the BananaBread demos in SeaMonkey and filed a bug on things not working there yet.
• Themes:
  Finished and uploaded the 2.12 versions of EarlyBlue and LCARStrek, matching the Mozilla 15 train, waiting on AMO approval now.
• Various Discussions/Topics:
  BananaBread demo and Linux, GitHub issue tracker vs. Bugzilla, WebRTC crash, etc.

August 28, 2012 05:42 PM

Yucatec Maya is spoken daily by nearly 700,000 people in the Southern Mexico. It’s a living language, descendant of the civilization of antiquity, which has stood for centuries, with a growing artistic production. It is also used in daily speech among the Spanish-speaking Mexicans who live in the states of Yucatán, Campeche and Quintana Roo.

Among the younger bilingual speakers (Mayan/Spanish), there is a growing interest in using digital tools in their mother tongue. Therefore Nacnati (an NGO formed by digital enthusiasts under the age of 30), the Mozilla Mexico chapter, Wikimedia Mexico and the National Commission for Development of Indigenous Peoples of the government of Mexico held a Mayan Translatón (translate-a-thon) in Merida, Yucatan, commemorating the International Day of Indigenous Peoples on August 9th. Among the group of 31 translators were anthropologists, lawyers, researchers, graduate students in Maya and even high school students from nearby boroughs, such as Peto, Tekax, Valladolid, Halachó and Muna.

During the Translatón, which occurred from 8 am to 6 pm, participants localized Mozilla Firefox, increased the articles of Yucatec Mayan Wikipedia — which is still at Wikimedia Incubator — and uploaded the first documents of the Google Endangered Languages project.

With this event, the event’s participants and sponsors began a very important activity for new and current generations of our Mayan communities. Articles have been added to Wikipedia, the Firefox browser in Maya will now be published sooner, and Maya linguists are uploading documents to the Google Endangered Languages project. But the highlight of the Mayan Translatón is that 31 mayan language advocates are committed to follow this initiative and repeat this activity for the next event.

Ko’one’ex! (Hooray! in maya.)

August 22, 2012 07:54 PM

• CSI:Mozilla / CrashKill:
  Followed Adobe ramp up the pace of 11.4 beta beta releases towards the final release of this version.
  Discussed bsmedberg's proposal to revamp hang reporting.
  Kept a closer eye on mobile stability while Naoki is away.
  Did some preliminary testing of a staged version of Socorro with rapid beta / by-build reporting support.
  Also there, tested additional fields appearing in UI for single crash reports.
  Replaced clunky handling of throttling in my explosiveness reports.
  Made some of the data gathering for my reports automatically know about new versions by just querying Socorro data and made crashes per build recognize ESR.
  As usual, watched new/rising crashes, caring that bugs are filed where needed, and made sure my custom reports keep working well.
• comm-central build system:
  Reviewed some ports of build system improvements.
• German L10n:
  Reviewed some L10n work on Mozilla-16-cycle builds of Thunderbird, Firefox for Android and Firefox for desktop.
• Themes:
  More work on the 2.12 versions of EarlyBlue and LCARStrek, matching the Mozilla 15 train.
• Various Discussions/Topics:
  BananaBread demo, Thunderbird crashes, DB sync issues, Google suggest on Android and privacy, etc.

August 22, 2012 04:39 PM

I’m an Indian living in Hanoi, Vietnam.
At mozilla, I’m a Community Manager (L10N), helping create, connect and support new localization teams around the world.

I’m a technologist, hacktivist and an artist. I’ve worked with various FLOSS project over the last 10 years, helping various business and non-project organisations adopt/leverage FLOSS software.

You can follow my personal blog here.

August 17, 2012 06:42 PM

• CSI:Mozilla / CrashKill:
  Flash continues to be a huge stability topic, followed new updates of 11.3 as well as the 11.4 beta versions, where Adobe fixed a high-ranking crash we saw in an earlier beta.
  In all that Flash talk, I found a slight detection issue in Socorro and created a patch to fix it.
  An even larger topic in that week was a crash that happened to people with Google as a homepage, related to their sports game doodles to celebrate some large sporting event on the UK's capital. I'm planning a separate post on this issue, but the relevant bug was found to have security implications, so I'll wait until we have a release out with the fix and the bug becomes public.
  I also stayed in contact with the Socorro team while they were working with IT to get their staging environment fixed and to push support for rapid betas to it.
  Together with Naoki, I investigated a rising mobile crash with quite old Android versions (Froyo).
  Weighed into design discussions of the B2G first run experience to make sure we include an info and opt-out for crash reporting.
  Coming out of those discussions, and talking to Ted about bandwidth concerns, I filed a bug on compressing reports based on his suggestions.
  Did some small updates to my pretty rough overview page for my custom reports.
  Also added a column with other affected versions to the Flash version topcrash report and made display of hang pair details a bit nicer.
  Had some conversations with aphadke on crash summary data.
  As usual, watched new/rising crashes, caring that bugs are filed where needed, and made sure my custom reports keep working well.
• Themes:
  While the 2.11 versions of EarlyBlue and LCARStrek were made public on AMO, worked on the first parts for the 2.12 versions matching the Mozilla 15 train.
• Various Discussions/Topics:
  B2G and FTP, Google suggest on Android and privacy, packaged apps and developer experience, bug fix verifications, build system changes and comm-central, etc.

August 16, 2012 11:10 PM

Enjoy this guest post from SUMO Community Manager, Rosana Ardila.

We have good news for our SUMO localizers: we will have some development time to enhance the SUMO l10n tools! We know that our tools were designed for the past release cycle, and now that we have a new Firefox version every 6 weeks we have many updates. I have talked to many of you and we know that we could do some things better. So please, give us your feedback and we will make the tools better for you.

Right now we have so many articles that need an update, so as you do this work, you can think about the main pain points and give us your ideas to make this better. We would love to implement all of your ideas and solve all of your problems, but we don’t have the resources to do it. So please keep in mind that we will have to choose a couple of changes and that we can’t promise you to fix all. But I’m sure we will find a way to make the tools much better!

We want to make this a collective effort, so we created the project plan and three etherpads to track the bugs that were already created, the main pain points and your ideas. It would be great if all of you give us your input or just put your name and a +1 next to an idea or comment you support. If you would like to have a conversation about tools with me or with other localizers we can organize a video, phone or IRC meeting let me know, I’d be more than happy to host it. The idea is to work on this together and create tools that work well for you, our localizers.

You can find the project plan here: http://mzl.la/OCMFdh. Please circle this with all SUMO localizers and give us as much feedback as you can. If you have comments on the project plan or any questions I’m here to help.

August 08, 2012 04:54 PM

• CSI:Mozilla / CrashKill:
  Followed the developments of getting daily jobs running in a stable fashion again on Socorro and trying to get stage to work reliably, as that now blocks shipping any new code to production.
  Flash 11.3 is still a hot topic, though the recent update improved the situation somewhat. This series stays more unstable than 11.2 by a significant factor, though.
  Weighed into the discussion of doing an out-of-plan Firefox update on Android because of a high-visibility crash on Jelly Bean.
  Kept track of the B2G crash reporting story in Bugzilla, GitHub, email and IRC discussions.
  Moved my components report over to using data from the database, now only the device reports is still based on CSVs.
  As usual, watched new/rising crashes, caring that bugs are filed where needed.
• German L10n:
  Reviewed / commented on Thunderbird 16 L10n.
  Updated ChatZilla, core and SeaMonkey L10n to recent trunk changes.
• Themes:
  Finished up work on 2.11 versions of EarlyBlue and LCARStrek, and uploaded those to AMO.
• Various Discussions/Topics:
  Mailcompose recycling crashes, localizing B2G, social API and trains, build system changes and comm-central, etc.

August 06, 2012 08:07 PM

Gaia is a collection of HTML5 apps running ontop of Gecko. These apps are akin to regular websites you visit on the Web every day and they’re made using the same technologies: HTML, JavaScript and CSS.

And just like other webapps, Gaia can be run in Firefox and tested using Firefox’s developer tools!

This is a gamechanger for localization. You can preview the structure of any Gaia app in the Inspector. You can adjust the size of the viewport with the Responsive Design View. You can live-edit the underlying HTML code using Firebug. And if you change some code or edit a localization file, just reload to see your changes right away.

I recorded a 15-minute-long screencast to show how easy it can be to work on Gaia localization. Using the aproaches that I show in the screencast, you can:

• try out different ideas for translations and see them in context,
• test sizing and make sure all the elements fit in the UI,
• verify the consistency of the verbiage used in the UI,
• compare the interface with the wireframes.

Note: As of August 2012, you’ll need Firefox Nightly or Aurora to make the most of Gaia webapps. Beta and Release don’t support all the APIs yet. (What are the release channels?)

Watch the screencast

Fun fact: while recording the part about looking for potential localizability issues (around the 9:00 mark), I stumbled upon a real localizability bug. I submitted a pull request with a fix, which has since been merged into Gaia’s main codebase.

Script

Here are the notes that you can see me use in the screencast.

How to test the desktop builds

• Instructions: http://informationisart.com/11

• DEBUG=1 make profile

• b2g -profile gaia/profile

• Home key is the main hardware button

• Edit a file in Gaia’s code and restart to see changes

  e.g., apps/browser/locales/browser.en-US.properties

How to test Gaia in the browser

• Can we do away with restarts?

• Run Gaia in your Firefox

• firefox -profile gaia/profile

• Responsive Design View is your friend

  Tools > Web Developer > Responsive Design View

  Ctrl+Shift+M

• Homescreen doesn’t work for now

• But, you can try entering other apps’ URLs:

  http://browser.gaiamobile.org:8080

  http://calendar.gaiamobile.org:8080

  http://email.gaiamobile.org:8080

  http://dialer.gaiamobile.org:8080

  http://clock.gaiamobile.org:8080

• Edit a file and reload to see your changes!

  e.g., apps/browser/locales/browser.en-US.properties

How to use the devtools and Firebug with Gaia

• No restarts, no reloads; edit the DOM live
• Use the Inspector and the 3D View to understand the structure
• Use Firebug to edit the DOM live and try different translations

Discussion

Don’t hesitate to ping me (stas on irc.mozilla.org) in #l10n, #gaia or #b2g. For localization-related questions, I encourage you to ask in the mozilla.dev.l10n newsgroup.

August 06, 2012 12:07 PM

• CSI:Mozilla / CrashKill:
  Once again, had a lot of discussions on Flash 11.3 stability. This continues to be our greatest concern in overall Firefox stability, even though the problems lie entirely on Adobe's side. Several people on our side continue working with people on their side to improve the situation. Adobe released an update with some improvements at the end of the week.
  Kept track of another not-so-successful try to switch the system for running regular Socorro jobs.
  Discussed how we can improve getting info about Android crashes to developers, and filed a bug on exposing some more info.
  Filed a bug on losing browser-side hang specificity again on Firefox 16 and up.
  Also continued following B2G crash reporting progress. The basic mechanics have landed, but there's quite a few additional pieces that need to be put together.
  As usual, watched new/rising crashes, caring that bugs are filed where needed.
• Various Discussions/Topics:
  Localizing B2G, crashes with SeaMonkey and Thunderbird mail compose, B2G status bar icons, etc.

August 01, 2012 04:07 PM

Taken from Matjaž Horvat’s blog:

I haven’t blogged about Pontoon for months and there’s no excuse for that. But that doesn’t mean it wasn’t keeping us busy.

In case you forgot, Pontoon is a website localization tool, which provides localizers with features never before seen in an open source website localization tool: WYSIWYG context and in-place editing.

Many things have changed in the last couple of months, including a transition to the Mozilla server infrastructure and to Playdoh – a web application template based on Django. We also implemented an AJAX-based user registration and login using Persona.

Translations are now automatically saved to a [translation memory] after every change, but you can also manually save your work to a predefined Transifex project. This is particularly useful for sites which cannot be fully localized using in-place string editing.

I’d like to thank the amazing Transifex team who helped me a lot with using their API and even modified it to suit our needs. Special thanks go to Ratnadeep Debnath, who volunteered his time to vastly improve our PO export and is now finishing the Django hooks. You rock!

All of this has brought us to the stage where we’re looking for a pilot project. Any not-yet-localized Mozilla website would be appropriate, but not too big in terms of number of strings to translate and locales to participate. We don’t want to hurt our localizers too much!

Any candidates?

July 30, 2012 05:11 PM

If you followed my recent announcements on this blog and in the mozilla.dev.l10n newsgroup, you were probably expecting a string freeze for B2G, a.k.a. Firefox OS, this Friday, July 27th.

The string freeze didn’t happen and we are pushing the localization schedule for B2G back a few weeks. I don’t expect the localization to start by the end of August.

What is the new localization schedule?

The exact schedule is yet to be determined. I hope to have more details in a week or two, so please do follow the newsgroup and expect more posts coming soon.

Is this a good thing?

Yes :) Having more time is obviously beneficial in many respects:

• fewer bugs in the code!
• more testing that will go into the final release,
• the main localization phase will not happen in August, which traditionally is a holiday month in many regions,
• there’s a MozCamp happening in September, so we’ll have a chance to talk about the localizability and the localization process during it,
• it will be easier to synchronize the localization of Gaia with the localization of Gecko 17 on which B2G will be based (17 goes to aurora on August 27).

Can the localizers work on something else today?

Meanwhile, there still are a few other things that you can do today to help B2G and Gaia be ready for localization.

Review the wireframes of Gaia apps.

Read more in this thread on mozilla.dev.l10n.

Test desktop builds and file bugs

I blogged about the desktop builds a week ago.

Localize Mozilla Marketplace

The Marketplace will be an important part of the Firefox OS experience. Watch out for Wil Clouser’s emails to the mozilla.dev.l10n list about the AMO localization to learn more.

Localize Mozilla Persona

Mozilla Persona (previously: BrowserID) will, again, be an important identity-management piece of Firefox OS and the Marketplace. See Matjaž Horvat’s emails to the mozilla.dev.l10n list about Persona localization.

Discussion

I started a thread in the newsgroup about this change to the schedule. Please post your thoughts and ask questions there.

July 28, 2012 08:07 PM

• CSI:Mozilla / CrashKill:
  Followed more progress on B2G crash reporting and added a bug for adding B2G to Socorro once we have sending of reports working.
  More discussions of Flash 11.3 instabilities with "Protected Mode", including efforts on Mozilla's and Adobe's sides to improve on that.
  Watched the deployment of the newest Socorro update, testing the changes to featured versions and alarming the team when regular jobs didn't run when they're supposed to, after which they reverted parts of the update.
  Helped Benjamin to get a crash-analysis account up.
  Just like every week, watched new/rising crashes, caring that bugs are filed where needed.
• SeaMonkey:
  Reviewed L10n parts of a patch for set as desktop background.
  Helped the 2.12b1 release with a few reviews.
• Add-ons:
  Tried to port a few recent updates to the Data Manager add-on but running browser-chrome tests on add-ons is quite difficult with today's settings to disable application directory add-ons by default.
• German L10n:
  Updated Florian's feed on the German Mozilla Planet.
  Reviewed a patch for Thunderbird 15 L10n.
  Did an emergency patch for SeaMonkey 2.12 to back out chatzilla and venkman changes that didn't land in releases yet.
  Updated core and suite localizations to trunk changes.
  Synchronized German l10n-central and l10n/mozilla-aurora at the stage of the Mozilla 16 uplift.
  Performed the license conversion to MPL2 on trunk and aurora.
• Various Discussions/Topics:
  Localizing B2G, B2G desktop builds and testing, first parts of WebRTC landing, etc.

July 23, 2012 07:48 PM

If your tool serializes internal state instead of editing files, it’ll do surprising things if it encounters surprising content. Like, turn

errNotSemicolonTerminated=Named character reference was not terminated by a semicolon. (Or “&” should have been escaped as “&”.)

into

errNotSemicolonTerminated=Named character reference was not terminated by a semicolon. (Or “” should have been escaped as “amp;”.)

And that’s for a string the localizer never touched.

(likely narro issue 316)

July 20, 2012 04:18 PM

If you want to preview B2G and Gaia, you might be interested in knowing that the release engineering team started producing desktop builds which you can run on your desktop computer a few days ago.

As Ben Hearsum explains in his blog:

Please note that these are NOT full B2G builds. These are developer-targeted builds which only run on desktop machines, and cannot be flashed onto a phone or tablet. These builds are primarily useful to developers, QA and localizers working on Gaia. They can also be used by anyone who wishes to test out their websites or apps through a B2G-like client.

Also note that these builds are not localized yet, although you will find that a few locales have been enabled and that some strings show up translated.

What you’ll need

• internet connection
• GNU make (On Mac OS X, you’ll need XCode and XCode’s Command line tools, to be installed from the Preferences dialog)
• git

To keep things organized, I created a separate directory for the desktop builds. On my machine, it’s ~/moz/b2g/desktop/.

Get Boot to Gecko

You can download the desktop builds from ftp.mozilla.org.

• On Linux, download the build ending with linux-i686.tar.bz2 and extract the archive into your working directory (e.g., ~/moz/b2g/desktop/). You’ll end up with a b2g directory in your current working directory.
• On Mac OS X, download the build ending with mac64.dmg. Mount the image and copy the application into your Applications folder.
• (The Windows builds are also available, but I don’t have a Windows machine to test and provide specific instructions. I’ll be happy to edit this post if you send me some.)

Get Gaia

Now that we have a build of B2G, we need to download Gaia and create a profile for it which will store our settings and the webcache.

Clone the Gaia repository and create a profile by runnning the following commands in your working directory:

    $ git clone https://github.com/mozilla-b2g/gaia gaia
    $ DEBUG=1 make -C gaia profile

Run it

You’re good to go. Make sure you’re still in your working directory and run B2G with:

    $ b2g/b2g -profile gaia/profile

Or, if you’re on Mac OS X, run:

    $ /Applications/B2G.app/Contents/MacOS/b2g -profile gaia/profile

Hint: the Esc Home key behaves like the main hardware button, allowing you to quit Gaia apps.

Update it

There are no autoupdates for the desktop builds of B2G yet. The builds are produced every night, however, so you can just re-download them and extract like I described it above.

For Gaia, just cd into your Gaia repo clone, and pull the new commits:

    $ git pull

Bonus: a script

I whipped up a script that does all of the above for me. If you’re on Linux, you’re welcome to use it.

Go to your working directory and download the script:

    $ curl -O https://raw.github.com/gist/3149861/boot2gecko.sh
    $ chmod +x boot2gecko.sh

Lastly, just run it!

    $ ./boot2gecko.sh

If you need help…

Don’t hesitate to ping me (stas on irc.mozilla.org) in #l10n, #gaia or #b2g. And, as always, the mozilla.dev.l10n newsgroup is your friend.

July 20, 2012 12:07 PM

• CSI:Mozilla / CrashKill:
  I visually reviewed more Socorro UI changes for rapid betas.
  Followed metrics getting ADU data for WebRT into Socorro and found out that the low crash numbers correspond to low ADUs as well.
  Followed progress on B2G crash reporting and took care that submission gets basecamp blocker status.
  Continued discussions of Flash 11.3 instabilities with protected mode.
  Some more discussions around missing versions and getting that fixed correctly.
  Also discussed crash reporter UI.
  Just like every week, watched new/rising crashes, caring that bugs are filed where needed.
• German L10n:
  Reviewed Firefox and Fennec 15 localizations.
• Various Discussions/Topics:
  Thunderbird management changes, Mozilla communication channels, trusted apps proposal for B2G, followup on Jono's post, etc.

July 19, 2012 06:06 PM

Started with Mozilla project: Started contributing for Mozilla in March. Not very long ago

Role in L10n community: A new localizer

I met Arky in India and I talked with him about the need to help localize into Indic languages and getting involved with the L10n program. I began localizing Firefox into Marathi. I soon discovered linguistic ambiguity issues with terminology and it drove me mad! The Marathi team’s reviewers had to make a lot of corrections to my work because of terminology & orthographical ambiguity as well as a lack of standardization within the L10n team. Even those orthographic standards that existed weren’t part of a central resource for newcomers to refer to. I had to constantly refer back to previous localizations to find those standards, which doubled the time it took for me to localize strings accurately. As you can imagine, I became very interested in leveraging this previous work.

So I went to the #l10n channel and discussed this problem with Pike. I told him that I wanted to do something that would help me develop a termbase for L10n standardization. At the time, I did not initially consider MT. Pike referred me to Phillipe (French Mozilla) to leverage the content from the Transvision alignments. That idea transformed into using MT as an alignment tool and then utilizing the alignments to create a standard termbase. In other words, I would take a target and source content, align them, create a termbase from alignment, and it would provide terminology and orthography suggestions. I quickly realized that we could also use this tool to rate the quality of previous localizations, as well as localizations in other projects. If successful, we could begin bringing MT into the localization workflow, opening up a MT post-editing workflow within the Mozilla L10n project.

Around this time, GSoC came up and I saw the opportunity to do this under GSoC with Mozilla.

The project is not yet complete, but hopefully will be by the end of August.

I’m a CS student. My only prior experience with MT was while in college. Since I had very limited experience with MT, there was a large learning curve. But, I felt so passionate about using MT in the L10n workflow that I didn’t have any issues with learning it. Since the project started, I’ve become very familiar with MT.

I found Google scholar articles on MT, I evaluated existing Mozilla l10n tools, and I read the Moses MT wiki. I also looked into data on which tools are most widely used.

I didn’t, however, spend much time looking into proprietary tools because of licensing issues. It can be really complicated to get tangled up in. Besides, I’m not a fan of proprietary tools anyway .

I looked at the range of MT tools available and saw that Moses MT was open source and what I deemed to be the best out there. I also looked into incorporating termbases into MozillaTranslator, and it had a lot of potential. [Another thing that led me to Moses is that] there’s a lot of community support (it’s still a very active project) and supports more languages than most of the other open source MT projects.

At first I wanted to create scripts that worked like term extractors then create TBXs (TermBase eXchange files), but MT has a wider scope and framework for future use than scripted term extractors. With MT, you can reduce your workload through its auto-translate function. Besides, I wasn’t very happy with the term extractor scripts’ results. I realized that while running them, I was lacking volume of translated strings. I wanted to give strings to the MT to learn the translation instead. Not only that, but the existing term extractors don’t work well with Indic languages. MT has a wider character support scope and is simply more scalable.

MT, however, has not matured enough to not require manual intervention. Plus, the community needs to have a say in it. I wanted to provide an option and let them either choose to fully implement MT or use a TBX file created from the MT utility.

Moses MT is still not very mature and I had installation issues with it. Some people have worked on creating installation packages for Linux (Debian, Fedora, and Ubuntu). Ubuntu seems to be the best supported platform for Moses and natural language processing tools.

MT also requires a lot of existing data. It was difficult to find enough data and convert it into a format that Moses could understand. Unfortunately, the amount of suitable Mozilla L10n data for this type of conversion is very limited. Moses needs this data in what’s know as a parallel corpus. I found that .lang files were the easiest to convert into a parallel corpus.

Special characters were also an issue when converting files into parallel corpuses. The challenge is basically to extract the data from .lang, .properties, and .dtd files, and only the .land files could do it well enough. I even ran into problems with .tmx files that contained special characters (e.g., brackets, etc.). I tried creating other data without going to the trouble of converting those files, but it would have required a lot of time. Most of the data that Mozilla has created are not suitable for MT.

Finally, I found that I cannot speak enough languages to really know if the resulting termbase data was good enough!

If you would like to learn more about Gautam’s GSoC project, visit the project’s wiki page.

July 19, 2012 05:03 PM

Yesterday I started a thread in mozilla.dev.l10n and published a post on my blog outlining the localization schedule for Boot to Gecko and asking localizers to respond if they’re interested in participating in the localization effort.

The community’s response to such questions is usually overwhelming, and B2G is no exception.

Within less than 24 hours, we have already heard from more than 30 interested locales!

• Arabic ar
• Assamese as
• Bengali (Bangladesh) bn-BD
• Catalan ca
• Welsh cy
• German de
• English (Unites States) en-US
• Esperanto eo
• Spanish es-*
• Estonian et
• French fr
• Frisian fy-NL
• Gaelic (Scotland) gd
• Galician gl
• Hindi (India) hi-IN
• Haitian Creole ht
• Indonesian id
• Italian it
• Japanese ja
• Korean ko
• Malayalam ml
• Dutch nl
• Punjabi pa-IN
• Portuguese (Brazil) pt-BR
• Russian ru
• Slovenian sl
• Albanian sq
• Swedish sv-SE
• Telugu te
• Urdu ur
• Chinese (Simplified) zh-CN
• Chinese (Traditional) zh-TW

Way to go! Even though the B2G devices will initially market only in South America, this proves the point that the localization effort should be global and scalable.

Here’s an interesting side note about the South America part above. (This wouldn’t be Mozilla if I didn’t learn something new today.) As Rhoslyn Prys mentioned in the newsgroup, in Argentina, there are around 50,000 Patagonians of Welsh descent, many of whom speak Welsh as first or second language.

What next?

I will be posting more details soon about how and what exactly to localize. Expect more updates this and the next week. The first freeze is scheduled for July 27th, which is next Friday.

If you want to get involved, check out the thread in mozilla.dev.l10n and contact other localizers from your locale.

July 19, 2012 04:17 PM

Mozilla is gearing up for releasing a mobile OS based on Gecko and HTML, codenamed Boot to Gecko, or B2G. It is a stack comprised of a Linux kernel and low-level userspace layer, with Gecko running on top of it, and all UI and other apps implemented in HTML and JS. Gaia is the name of the UI, which will consist of HTML5 apps, like the Homescreen, Dialer, Contacts, Browser, Email, Gallery, Camera, Clock, Calculator, Lockscreen, Settings etc.

The wiki has more information about the architecture and codenames.

The schedule

Update (July 28th): The schedule outlined below has been canceled. The new one has not been decided yet, but keep an eye on the newsgroup for updates. Read more in this thread on mozilla.dev.l10n.

We will be soon kicking off the localization effort for B2G. The plan is this:

• the UX freeze this Friday, July 20^th,
• the first string freeze the next Friday, July 27^th,
• the second string freeze TBD, probably the first week of August,
• the deadline will be Tuesday, August 21^st (giving us more than 3 weeks total for localization).

Why two string freezes?

We are already hearing from developers that they won’t be able to freeze everything by 7/27 (think error messages and rare and unexpected paths the interaction might follow). We prefer to freeze what we can early (7/27) and start the localization right then. For the second string freeze we will probably see some additions, but I’ll do my best to limit changes to already localized strings.

What’s the workload?

We don’t really know yet for sure, as not all the UI has landedas of this moment. Today’s numbers are the following (for some context, the entire Firefox Desktop with toolkit is ~6600, Firefox Mobile is ~5000 strings):

• ~500 strings in Gaia
• ~200 strings in Gecko/toolkit, but there’s a good chance that we will be able to reuse Mobile translations here.

Lastly, keep in mind that the first devices will be marketed in South America, so we will be focusing on Spanish and Brazilian Portuguese for the first release. This does not mean, however, that we can’t ship B2G with more locales available, for users in the said geographies, and for testing everywhere else. We are also investigating the feasibility of having langpacks for B2G.

OK, count me in!

Great! Just head to the mozilla.dev.l10n thread that I opened today and reply with your locale code.

July 18, 2012 02:07 PM

We’re happy to announce that a localized Fulah (ff) Firefox build has been added to the list of supported languages for Firefox 14. We also want to extend congratulations to the Fulah (ff) team! Native Fulah speakers (approximately 13 million speakers spread throughout 20 African nations) can download their localized build here.

Tristan Nitot has also written a very moving congratulations to Ibrahima Saar and the Fulah team, as well as a valuable description about how our localization philosophy differs from that of most companies on the Mozilla Beyond the Code blog. Don’t miss it!

Congratulations Fulah!

July 17, 2012 07:17 PM

Firefox 14 is now available as a free download for Windows, Mac, and Linux from http://www.mozilla.org/firefox/new/. As always, we recommend that users keep up to date with the newest version of Firefox for the latest features and fixes. The release notes for Firefox 14 are available at http://www.mozilla.org/en-US/firefox/14.0.1/releasenotes/. Firefox 14 is also now available for Android. The associated release notes are available at https://www.mozilla.org/en-US/mobile/14.0.1/releasenotes/index.html.

-Alex Keybl
Release Manager at Mozilla

July 17, 2012 03:02 PM

When it comes to localizing web content, you’re likely to end up with a lot of HTML inside of your source strings. You might be see markup like strong and em, or simply links to other resources with a tags.

Consider the following paragraph taken from www.mozilla.org.

Portions of this content are ©1998–2012 by individual mozilla.org contributors. Content available under a Creative Commons license.

The HTML code for this paragraph is this:

    <p>
        Portions of this content are ©1998–2012 by individual 
        mozilla.org contributors. Content available under a <a 
        href="/foundation/licensing/website-content.html">Creative 
        Commons license</a>.
    </p>

You’ll notice the a tag with an href attribute. The href is a URL, and it makes this HTML significantly harder to read.

If we wanted to localize this paragraph, the L20n code for English would look like this:

    <licenseInfo """
        Portions of this content are ©1998–2012 by individual 
        mozilla.org contributors. Content available under a 
        <a href="/foundation/licensing/website-content.html">Creative 
        Commons license</a>.
    """>

The URL will always be /foundation/licensing/website-content.html, regardless of the user’s locale. It makes little sense, then, to have it in the source string. The tag makes the string harder to read and increases the risk of introducing an error (e.g., removing a quotation mark or accidentally editing the URL).

In fact, the href attribute is part of the document’s structure rather than its source content, and as such, does not belong in the L20n code at all.

What if L20n let you skip attributes that are not related to the source content? What if it copied those attributes from the developer-defined code, thus sparing the localizer all the trouble?

Enter DOM overlays

The premise is simple: only localizable source content should live in L20n files. Let’s modify the HTML code and the licenseInfo string accordingly.

    <p l10n-id="licenseInfo">
        <a href="/foundation/licensing/website-content.html"></a>
    </p>

The actual content, both source & target, will be injected with L20n code. This way the developer doesn’t have to (although they can) put it in HTML. All that matters is the l10n-id="licenseInfo" part, as well as the a tag with the href attribute defined in HTML. All the rest happens in the L20n file.

    <licenseInfo """
        Portions of this content are ©1998–2012 by individual        
        mozilla.org contributors. Content available under a 
        <a>Creative Commons license</a>.
    """>

We keep the a tag in the L20n file so that the localizer has control over what islinked and what is not. However, the attributes of the tag are not localizable and thus, are absent in the string. The strings is easier to read, and also harder to accidentally break.

Matching and reordering multiple overlays

L20n’s DOM overlays match HTML nodes by type, name and position. If licenseInfo had two a child nodes, their attributes would be matched and copied from the source string in their respective order.

Consider the following example.

Welcome to Pancake, Staś.

The HTML and L20n code responsible for this message might look like this:

    <p l10n-id="welcome">
        <a href="/"></a>
        <a href="/profile"></a>
    </p>

    <welcome """
        Wecome to <a>{{ brandName }}</a>, <a>{{ $user.firstname }}</a>.
    """>

The a elements are in the same order in the source code and in the L20n code. L20n will thus copy the href attribute from the first a element in the source code to the first a element in the L20n code.

Let’s suppose now that the localizer wishes to change the order of the links. Maybe the grammar requires her to do so, or maybe the register is more (or less) formal in her locale. The expected result would be (translated back to English for the sake of this example) this:

Hi Staś. Welcome to Pancake.

Because the order is different, the localizer cannot rely on L20n’s automatching any more. Instead, she needs to instruct L20n which a element corresponds to which one in the source. L20n allows her to do so via the l10n-path attribute set on the element, like so:

    <welcome """
        Hi <a l10n-path="a[2]">{{ $user.firstname }}</a>.
        Welcome to <a l10n-path="a[1]">{{ brandName }}</a>.
    """>

Using the XPath syntax, the localizer identifies which source a element to copy attributes from.
The first a element in the translation will be matched against the second a element in the source. The meaning of a[2] in XPath is:

the second child (descendant of the first generation) of the context node that is an a element.

(The context node is the source node that’s being localized, in this example the p element with l10n-id="welcome".)

In most of the cases, the XPath expression will be very basic and minimal, like in the examples above. The full XPath syntax is supported, however, allowing for more complex matching.

Lastly, the l10n-path is only required when changing order of elements of the same type, like two a elements. If you want to change the order of child nodes in a string with one strong and one em tag, you can do so without having to specify the l10n-path attributes.

Privileges and autoextraction

The next step is to see if there’s a need to prevent some attributes from being copied. It might be interesting to extend DOM overlays with a mechanism which only accepts whitelisted attributes, or blocks blacklisted ones from being copied from the source strings to the translation. This could be done globally, or even per-entity.

I also started working on a maintainance script which extracts the contents of source nodes and automatically creates valid L20n code ready to be localized. It supports whitelisting attributes, but generally leaves most of the attributes out of the L20n code. You can find the code on Github, but bear in mind that this was more of an experiment and is very much a work-in-progress.

Discussion

Please post your thoughts in the mozilla.dev.l10n newsgroup.

July 17, 2012 02:17 AM

July 17, 2012 12:24 AM

First we’re gonna update your local, cloned repo by running the following commands from your local directory:

hg pull
hg update -C -r default

Then, select, drag, and drop the Narro export into your updated repo.

Now that you have your export in your local directory, review the file status by using this command:

hg status

Running this command will display what files in your local directory have been modified, added, and removed compared to the mercurial repository. You’ll see output like this:

M toolkit/crashreporter/crashreporter.ini
M toolkit/defines.inc
! browser/README.txt
! toolkit/chrome/mozapps/xpinstall/xpinstallConfirm.properties
? browser/branding/official/brand.dtd
? browser/branding/official/brand.properties

What does the output mean? It’s actually rather straight forward to interpret.

• M = Modified
• ! = Missing
• ? = Hg doesn’t know about this file
• A = Added to your local repo
• R = Removed by running hg remove

You’ll use the printed status output to evaluate what areas of your local repository need to be cleaned up before committing to your hg locale repo.

Here are issues to keep your eye on within your status output:

• Clean up files ending in .orig. These are most commonly labeled as ? in your status output and must be removed. You can find these by either running this command:

find . -name \*.orig -exec rm \{\} \;

or copying and pasting your output from the command line to your favorite text
editor and using its Find function, then removing those files by drag and drop.

• Revert your region.properties file and search plugins (if needed) by running this command:

hg revert -C -r default browser/chrome/browser-region browser/searchplugins

• Check for accessibility errors and & in .properties files. The problem here is that Narro exported .properties files consider the & character to denote an access key, thus Narro removes it from HTML fragments and breaks entity references, like &. You’ll have to manually make these changes in your favorite text editor.

hg diff dom/chrome/layout/htmlparser.properties browser/chrome/browser/quitDialog.properties browser/chrome/browser-region/region.properties browser/installer/custom.properties browser/installer/mui.properties browser/installer/override.properties toolkit/chrome/global/commonDialogs.properties toolkit/chrome/passwordmgr/passwordmgr.properties toolkit/chrome/search/search.properties

• Revert the files that Narro likes to break (found in the command below). If you had actual L10n work in them, you’ll need to manually fix those files in your favorite text editor. If you don’t have L10n work in them, run the hg revert command on them:

hg revert -r default dom/chrome/layout/htmlparser.properties  browser/chrome/browser/quitDialog.properties  browser/chrome/browser-region/region.properties  browser/installer/custom.properties browser/installer/mui.properties  browser/installer/override.properties  toolkit/chrome/global/commonDialogs.properties  toolkit/chrome/passwordmgr/passwordmgr.properties  toolkit/chrome/search/search.properties

Some final notes:

• Be sure you have a non-broken starting point on your computer before you clean up your export files, otherwise your diff will be corrupted and then you’ll really be in a bad spot. https://l10n.mozilla.org/source/diff/?from=b86699a22142&to=85bf50c13957&repo=releases%2Fl10n%2Fmozilla-aurora%2Fkm shows an example in a few of those (above files).

• If your last commit was already broken, hg diff will miss that Narro has dropped the & character or even misplaced it (e.g., $Brand&ShortName), thus breaking HTML and accessibility. Be diligent and detail-oriented while looking through files to correct accessibility issues.

   CONTEXT_OPTIONS របៀបសុវត្ថិភាព $Brand&ShortName

• Please remember that these issues are currently being investigated. If you have any problems with these, please ask for help on the #l10n IRC channel or in the m.d.l10n newsgroup. If you find additional bugs with Narro, feel free to file a bug in Bugzilla.

Additional resources:

• http://hgbook.red-bean.com/read/mercurial-in-daily-use.html
• https://developer.mozilla.org/en/Localizing_with_Narro/Intermediate_tutorial
• https://developer.mozilla.org/En/L10n_on_Mercurial

July 16, 2012 11:40 PM

(This is a crosspost from my blog: http://informationisart.com/8/.  Check it out for better code formatting and syntax highlighting.)

With L20n’s DOM overlays, developers can amend localized strings with additional non-localizable HTML markup. This improves the separation of content and structure and reduces the cruft in localization files.

When it comes to localizing web content, you’re likely to end up with a lot of HTML inside of your source strings. You might be see markup like <strong> and <em>, or simply links to other resources with <a> tags.

Consider the following paragraph taken from www.mozilla.org.

Portions of this content are ©1998–2012 by individual mozilla.org contributors. Content available under a Creative Commons license.

The HTML code for this paragraph is this:

 <p> Portions of this content are ©1998–2012 by individual mozilla.org contributors. Content available under a <a href="/foundation/licensing/website-content.html">Creative Commons license</a>. </p> 

You’ll notice the <a> tag with an href attribute. The href is a URL, and it makes this HTML significantly harder to read.

If we wanted to localize this paragraph, the L20n code for English would look like this:

 <licenseInfo """  Portions of this content are ©1998–2012 by individual   mozilla.org contributors. Content available under a   <a href="/foundation/licensing/website-content.html">Creative   Commons license</a>.  """> 

The URL will always be /foundation/licensing/website-content.html, regardless of the user’s locale. It makes little sense, then, to have it in the source string. The tag makes the string harder to read and increases the risk of introducing an error (e.g., removing a quotation mark or accidentally editing the URL).

In fact, the href attribute is part of the document’s structure rather than its source content, and as such, does not belong in the L20n code at all.

What if L20n let you skip attributes that are not related to the source content? What if it copied those attributes from the developer-defined code, thus sparing the localizer all the trouble?

Enter DOM overlays

The premise is simple: only localizable source content should live in L20n files. Let’s modify the HTML code and the licenseInfo string accordingly.

 <p l10n-id="licenseInfo"> <a href="/foundation/licensing/website-content.html"></a> </p> 

The actual content, both source & target, will be injected with L20n code. This way the developer doesn’t have to (although they can) put it in HTML. All that matters is the l10n-id="licenseInfo" part, as well as the a tag with the href attribute defined in HTML. All the rest happens in the L20n file.

 <licenseInfo """  Portions of this content are ©1998–2012 by individual   mozilla.org contributors. Content available under a   <a>Creative Commons license</a>.  """> 

We keep the <a> tag in the L20n file so that the localizer has control over what is linked and what is not. However, the attributes of the tag are not localizable and thus, are absent in the string. The strings is easier to read, and also harder to accidentally break.

Matching and reordering multiple overlays

L20n’s DOM overlays match HTML nodes by type, name and position. If licenseInfo had two <a> child nodes, their attributes would be matched and copied from the source string in their respective order.

Consider the following example.

Welcome to Pancake, Staś.

The HTML and L20n code responsible for this message might look like this:

 <p l10n-id="welcome"> <a href="/"></a> <a href="/profile"></a> </p> 

 <welcome """  Wecome to <a>{{ brandName }}</a>, <a>{{ $user.firstname }}</a>.  """> 

The <a> elements are in the same order in the source code and in the L20n code. L20n will thus copy the href attribute from the first <a> element in the source code to the first <a> element in the L20n code.

Let’s suppose now that the localizer wishes to change the order of the links. Maybe the grammar requires her to do so, or maybe the register is more (or less) formal in her locale. The expected result would be (translated back to English for the sake of this example) this:

Hi Staś. Welcome to Pancake.

Because the order is different, the localizer cannot rely on L20n’s automatching any more. Instead, she needs to instruct L20n which <a> element corresponds to which one in the source. L20n allows her to do so via the l10n-path attribute set on the element, like so:

 <welcome """  Hi <a l10n-path="a[2]">{{ $user.firstname }}</a>.  Welcome to <a l10n-path="a[1]">{{ brandName }}</a>.  """> 

Using the XPath syntax, the localizer identifies which source a element to copy attributes from. The first <a> element in the translation will be matched against the second <a> element in the source. The meaning of a[2] in XPath is:

the second child (descendant of the first generation) of the context node that is an <a> element.

(The context node is the source node that’s being localized, in this example the <p> element with l10n-id="welcome".)

In most of the cases, the XPath expression will be very basic and minimal, like in the examples above. The full XPath syntax is supported, however, allowing for more complex matching.

Lastly, the l10n-path is only required when changing order of elements of the same type, like two a elements. If you want to change the order of child nodes in a string with one <strong> and one <em> tag, you can do so without having to specify the l10n-path attributes.

Privileges and autoextraction

The next step is to see if there’s a need to prevent some attributes from being copied. It might be interesting to extend DOM overlays with a mechanism which only accepts whitelisted attributes, or blocks blacklisted ones from being copied from the source strings to the translation. This could be done globally, or even per-entity.

I also started working on a maintenance script which extracts the contents of source nodes and automatically creates valid L20n code ready to be localized. It supports whitelisting attributes, but generally leaves most of the attributes out of the L20n code. You can find the code on Github, but bear in mind that this was more of an experiment and is very much a work-in-progress.

Discussion

Please post your thoughts in the mozilla.dev.l10n newsgroup.

July 16, 2012 09:08 PM

Staś Małolepszy and I (Jeff Beatty) are happy to announce that we have been selected to represent Mozilla at the semi-annual Localization World conference in Seattle in October this year. We will be presenting on both Pontoon and L20n and how we hope they will impact the future of localization within the open source community. Here is a synopsis of our presentation:

As the web continues to grow, Mozilla seeks to uphold the standards and practices that keep it open for all. Through two of our latest open-source projects, l20n and Pontoon, we are creating a new generation of tools and resources that put more power in the localizers’ hands. Localizers reach a higher level of free linguistic expression with l20n, unencumbered by an application’s logic. Pontoon provides web localizers with something they’ve never had before in an open-source localization tool: WYSIWYG context, real-time translation editing, and collaborative review features. This  presentation will give participants a glimpse into the future of  open-source localization.

July 11, 2012 10:08 PM

• CSI:Mozilla / CrashKill:
  I visually reviewed a few Socorro UI changes for rapid betas.
  Followed the missing links to make WebRT support in Socorro complete.
  Noticed some versions missing on Socorro and filed a bug for that.
  Also filed a bug on adjusting FTP scraping for build changes.
  Followed up on some Stability Work Week discussions.
  Did some more triage of old crash bugs, e.g. there's no open crash bugs left in "Graveyard" products now.
  Continued discussions of Flash 11.3 instabilities with protected mode.
  Just like every week, watched new/rising crashes, caring that bugs are filed where needed.
• SeaMonkey:
  Helped out a bit with some beta release problems and figuring out how a recent change in buildbot tooling has caused those.
  Reviewed a Data Manager improvement.
• German L10n:
  Updated core and SeaMonkey L10n to recent trunk changes.
• Themes:
  Uploaded new 2.10 versions of EarlyBlue and LCARStrek, which meanwhile also have reviews on AMO.
• Various Discussions/Topics:
  SeaMonkey infrastructure, Thunderbird management changes, B2G and Gecko/low-level-OS L10n, key pinning, etc.

July 10, 2012 05:49 PM

• CSI:Mozilla / CrashKill:
  Updated forced Firefox versions for correlation reports once again.
  Together with Sheila, did some triage of old crash bugs.
  Commented on the first pieces of Socorro UI work for rapid betas.
  Had some discussions with relevant teams on crash reporting for desktop Webapp Runtime and for B2G.
  I was also involved in a lot of discussions about the new Flash 11.3 version crashing and hanging a lot more than older versions, mostly with their "Protected Mode" feature. We're continuing to track that.
  Had a ton of discussions on all kinds of different angles on Firefox stability Worked on some stats around Socorro bugs and crash signatures that I wanted to have around for Stability Work Week. One result of that is a list of bugs I filed due to our discussions.
  I also held a brown bag presentation on the life cycle of Firefox crashes.
• German Localization:
  Reviewed patches for Thunderbird 14 and Firefox 14 L10n.
  I also synched core and SeaMonkey to changes in the Mozilla 15 cycle, and merged trunk to aurora with that state.

July 10, 2012 04:58 PM

Mozillians participating in L10n are very diverse. They come from many different backgrounds, countries, languages, and experiences. For most, software development,  IT, and translation are their background. Others are Social Workers, Teachers, even Financial Civil Servants. Some are even employees of other open source projects similar to Mozilla (e.g., RedHat). I recently had the chance to ask Mozillians about their motivations for localizing Firefox. I learned that their reasons for localizing Firefox can be just as unique and varied as they are.

Let’s take a look at some of these reasons. While most were unique, there were also some common trends within the responses. These are top three motivators for localizing Firefox, according to Mozillians:

1. To help users in my region have access to the web in their language.
2. To preserve my language.
3. To participate in open source software projects.

In addition to these, localizers also had very personal reasons for getting involved:

“I tried to help Armenian localizers so my grandfather could use Firefox in Armenian.”

“I wanted to do something which had an impact on others. This is difficult to do when you are a student and all your work is something which is graded and then forgotten. Contributing to an open source project was my way of having
an impact. Mozilla was a good fit for me because the Mozilla browser was so much better than what I had before, and I wanted to be part of it. Mozilla became my choice because the project seemed to balance principles against market relevance, whereas other open source projects at the time had a narrow focus on principles.”

“I was intrigued by the web-style XUL-based UI design and found that I could just edit a couple of text files to change the strings to German, which was fantastic compared to any other software I knew.”

It was also interesting to note that these reasons rarely change over time. The only difference between a localizer’s first reasons for localizing Firefox and their current reasons is that they have become more focused. As time goes on, a localizer’s focus gradually moves toward giving back to Mozilla and preserving their language.

“Now I also do it to give back to Mozilla.”

“Original priorities regarding language revitalization and open web are now greater than ever. Firefox Cymraeg was the first popular piece of software available of Welsh. It has shown the way and has set expectations for a multitude of other software to be available also in Welsh. Long may it continue. Melys moes mwy.”

“I am not a student anymore, so looking for a place to have an impact is not that important to me anymore. The Mozilla mission means a lot more to me now.”

When asked to share any final thoughts about their reasons for localizing Firefox, this is what some localizers had to say:

“Nowadays is easier to find software available in you own language, the real challenge is to deliver a professional quality product and prove that an Open Source community driven by volunteers is capable of doing it.”

“Having Firefox in our language is a very powerful tool for language revitalization. Because the Firefox brand is so well respected, it gives respect to our language also. It normalizes our language on the web and provides a good example to localizers of other software.”

“Minority languages need a presence on the Internet to enhance their raison d’etre and to provide a source of support and pride for their speakers.”

“Our web needs a good community based browser that is translated into as many languages as possible.”

What are your reasons for localizing Firefox, or any Mozilla project? Please tell us about your experience below or by emailing here.

If you’re not currently contributing to Mozilla L10n and would like to, please visit this site to find all of the L10n opportunities available to you.

July 05, 2012 05:13 PM

Experts have discovered that there are approximately 7,000 spoken languages around the world, as cited by Ethnologue. Many of these are well known and are spoken by millions of people. Others are on the brink of extinction. It is estimated that nearly half of the world’s 7,000 languages could become extinct within this century, according to the Endangered Languages Project. Preserving these cherished languages has become a high priority for many organizations and people worldwide, including the localization teams at Mozilla.

Mozilla’s localization efforts aim to bring the open web to every corner of the globe, offering every user a regionally customized web experience. We are only able to accomplish this mission by teaming up with a very talented and dedicated, global community of volunteers who share our same values. Many of these volunteers are native speakers of languages that are considered to be endangered. For many of them, they localize Firefox for two reasons: they love the web and they want to preserve their language.

Mozilla works closely with volunteer localization teams who form part of organizations such as AnLoc in Africa and Nacnati in Mexico, as well as individuals and small groups who localize Firefox into the following languages:

• Asturian
• Breton
• Catalan
• Kashubian
• Welsh
• Basque
• Frisian
• Irish
• Scottish Gaelic
• Galician
• Ligurian
• Occitan
• Romansh

To support these teams, we provide the framework and vehicle for them to distribute their work as either official language packs or official localized Firefox builds. We seek to mentor their efforts wherever possible through dedicated Localization Community and Program Managers. In addition, we actively encourage experienced localizers to join us in mentoring these teams. As part of our mentor efforts, we work to visit these teams as often as possible, providing them with one-on-one trainings called L10n Sprints.

We love all of our localization teams and look forward to our continued opportunities to aid in preserving the languages of the world.

June 28, 2012 02:21 PM

This is the first localization update about Boot to Gecko and Gaia, where I’ll be summarizing the development and the progress of the localization plan for B2G.

There are a few tracks in which the work is taking place in parallel.

As Gaia can be thought of as a collection of HTML apps, we needed a way to localize web content on the client side. This is actually something we’ve never done before—our web pages are normally localized on the server side. So the first task was to develop a way to show localized content in HTML by using JavaScript to replace original strings with their translations. This work has been done by Kazé and the library he wrote is available on github.

Kazé based his work on the .properties format which is widely used in other Mozilla products. We want to be able to leverage the existing localization infrastructure like Elmo and make it possible to use many different translation tools like Mozilla Translator, Narro and Translate Toolkit and Pootle. I’m working with Kazé on making sure his work is compatible with the existing localization ecosystem.

We will also soon need localized builds for testing purposes, both for devices and desktop emulators alike. I filed bug 766962 to let the Release Engineering team know about our requirements.

At the same time, the User Experience team is hard at work finalizing the wireframes and the interaction designs for all Gaia apps. This is a great moment to start reviewing these designs in terms of localizability. All apps can be found on the Gaia wiki, e.g.
wiki.mozilla.org/Gaia/Clock links to the Clock app interaction design spec (pdf).

I posted a call for reviews in mozilla.dev.l10n earlier today. If you have a moment, feel free to take a look at the interaction design PDFs and respond with your thoughts in the newsgroup. Starting the reviews so early will help us flag potential localizability issues and fix them in a timely manner.

Read the call for reviews for Gaia wireframes.

June 22, 2012 10:55 PM

(This is a crosspost from my blog: http://informationisart.com/7/)

This is the first localization update about Boot to Gecko and Gaia, where I’ll be summarizing the development and the progress of the localization plan for B2G.

There are a few tracks in which the work is taking place in parallel. As Gaia can be thought of as a collection of HTML apps, we needed a way to localize web content on the client side. This is actually something we’ve never done before—our web pages are normally localized on the server side. So the first task was to develop a way to show localized content in HTML by using JavaScript to replace original strings with their translations. This work has been done by Kazé and the library he wrote is available on github.

Kazé based his work on the .properties format which is widely used in other Mozilla products. We want to be able to leverage the existing localization infrastructure like Elmo and make it possible to use many different translation tools like Mozilla Translator, Narro and Translate Toolkit and Pootle. I’m working with Kazé on making sure his work is compatible with the existing localization ecosystem.

We will also soon need localized builds for testing purposes, both for devices and desktop emulators alike. I filed bug 766962 to let the Release Engineering team know about our requirements.

At the same time, the User Experience team is hard at work finalizing the wireframes and the interaction designs for all Gaia apps. This is a great moment to start reviewing these designs in terms of localizability. All apps can be found on the Gaia wiki, e.g.
wiki.mozilla.org/Gaia/Clock links to the Clock app interaction design spec (pdf).

I posted a call for reviews in mozilla.dev.l10n earlier today. If you have a moment, feel free to take a look at the interaction design PDFs and respond with your thoughts in the newsgroup. Starting the reviews so early will help us flag potential localizability issues and fix them in a timely manner.

Read the call for reviews for Gaia wireframes.

June 22, 2012 04:00 PM

Role at mozilla: Pontoon developer and L10n driver (currently driving BrowserID L10n)

Where I’m from: Slovenia, AKA the country where Donald Trump’s latest wife comes from

Languages I know: Slovenian, English, Croatian & Bosnian & Serbian, German, Latin

Years with the project: almost 11. I started on Fri, July 12 2002 at 21:36:52 CEST by sending email:
http://liste2.lugos.si/pipermail/lugos-slo/2002-July/003621.html

Professional experience: I graduated from Computer and Information Science in 2009 and before joining Mozilla full-time in 2011 I worked for three successful Slovenian IT companies: Zemanta, Vox.io and XLAB.

Blog: http://horv.at/blog/
Twitter: @mathjazz

5 things you may not know about me:

* I learned to play the accordion for three years. Luckily (for my listeneres), I forgot everything.
* I represented Slovenia at IT competition for students organised by Microsoft for two years in a row. Please don’t fire me for that.
* I was featured in a Wired UK article titled Mozilla vs. King Corporate.
* I used to be a journalist. I wrote a couple of hundred pieces for the leading slovenian IT-magazine and the leading slovenian IT-website.
* I skipped a grade at the primary school.

June 15, 2012 06:10 PM

A little over a year ago we radically changed the release process for all Mozilla products, most notably Firefox. Not only were new versions of Firefox going to be released every six weeks, but anyone could follow Firefox development by downloading builds from any of four different channels (corresponding repos), Nightly (mozilla-central), Aurora (mozilla-aurora), Beta (mozilla-beta), and Release (mozilla-release).

It’s clear that each channel had its unique dev and QA purpose.

• Nightly is where the main dev work is performed with new builds being created every day.
• Aurora is for more stable builds. It is not built as often as Nightly.
• Beta is even more stable and is heavily tested.
• Release is for the most stable and final approved builds.

So where does L10n fit in (**hint** look at this blog post’s title)? You got it, the Aurora channel! For L10n, the release channels are used in a similar fashion to dev and QA, with the main exception being where the bulk of the work takes place.

• Nightly is where the main dev work takes place. Only the brave try to localize here because the strings in this repo have not yet been frozen (i.e., are still changing).
• Aurora, the localizer’s workspace. Strings in this repo have been frozen, making Aurora the ideal place for L10n. This also means that when a particular version is ready to move to the Beta channel that L10n teams should have at least begun the review process (technical reviews for new locales, sign-offs for existing locales).
• Beta is the place for fixing the L10n bugs found in the review process.
• Release is where all of a localizer’s work is distributed to world. Once a Beta revision has been reviewed an approved it is moved into the Release channel.

Since new versions of Firefox (and all other projects following this cycle) are migrated from between channels every six weeks, this implies that localizers must be vigilent about watching their Aurora repository and translating new strings as they come. If they aren’t vigilent, they run the risk of falling behind and having more and more new strings added to their repos as each new version passes through the Aurora channel. If this is a new locale’s first time producing a localized version of Firefox, they run the risk of not shipping in the Release channel.

To sum it all up, these are best practices to keep in mind:

• Aurora is where localizers make the bulk of their contributions.
• L10n teams need to keep a close eye on Aurora and localize as new strings are added with each migration from the Nightly channel.
• Are you a new locale looking to ship in the Release channel? Don’t forget to localize everything in Aurora, even if your review build is in the Beta channel.
• Reviews should begin toward the end of your work’s six week stay in Aurora.

For more information on these channels visit the Becoming an official release wiki page.

June 14, 2012 02:44 PM

Wait a second, we’re on the rapid release schedule for almost a year now, and 9 releases. How can the l10n dashboard be friends with the trees only now?

Well, I’ve hacked and lied and tweaked and spoofed the data for a year. No more.

The obvious changes are:

• Localizers as well as drivers can now see how far behind their work is, in release cycles
• channel migration code is actually not a lie, and can be taken over by release management

On the team page, you’ll now see something like

You’ll notice the difference between the Current sign-off with the green check-mark, and the fx14 one with the looking glass. In the past, we’ve shown the green check-mark for both, now we’re actually showing the version that we’re using instead of the current one, and the looking glass is there to indicate that the localizer should actually look into this. There’s been a good deal of confusion about this, and I sure hope that this will resolve it a good deal.

There’s a ton of follow-up work, for one on elmo. This bug has been blocking a lot of other patches and work, both for the localizer-facing parts as well as the release infrastructure-facing parts.

More so, the state of localizations changes from “n missing strings, probably in this bucket” to “didn’t update since fx12″. That’s changing how we guide our work as l10n drivers a good deal. The impact between what we do and what localizers do becomes less anecdotal, and more science.

And there’s quite a few things we need to do, in particular for desktop.

June 09, 2012 07:07 PM