More language support added to Firefox 14

Jeff Beatty

0

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!

Tips & tricks: Cleaning up Narro exports

Jeff Beatty

0

If you’ve ever used Narro to localize a project, you may have spent time cleaning up your exported files before they are committed to your locale’s repository. If you don’t catch the errors within your Narro export, you’ll find that some files may be reverted or corrupted in other ways that can ultimately break your localization. On the other hand, cleaning up these exported files can require some time and smooth hacking skills.
While these Narro bugs are being fixed, here’s a work around that you can easily use to make sure that your L10n work is squeaky clean before it goes into your locale repository.

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:

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

      For example, you may see something like below and notice that it is missing its &
character in the localized string.

   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:

L20n features explained. DOM overlays.

Staś Małolepszy

0

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

Mozilla at Localization World 2012 in Seattle

Jeff Beatty

0

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.
Staś and I are looking forward to showcase these tools, as well as the incredible and dedicated efforts of the Mozilla L10n teams, at one of the L10n industry’s premiere events.

Why we localize Firefox

Jeff Beatty

1

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.

Mozilla and language preservation

Jeff Beatty

10

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:

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.

Boot to Gecko localization update, June 22

Staś Małolepszy

0

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

Get to know a L10n driver: Matjaž Horvat

Jeff Beatty

0

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.

Aurora: The localizer’s workspace

Jeff Beatty

0

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.

Awesome L10n contributor: Marcelo, Reuben, and Fernando

Jeff Beatty

0

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

 

Marcelo Araldi, Reuben Morais, and Fernando Silveira

 

Nationality: Brazil
Languages: Portuguese
Role in L10n community:  Rueben – SUMO locale owner, Marcelo – SUMO peer, Fernando – websites

How did you get started with the Mozilla project?

RM: I’ve been with the project since January 2011. I basically clicked through the Get Involved page, specified localization as my interest, and ended up at SUMO.

MA: About 3 years ago I had no idea what  Mozilla was. I found and watched some talks from Chofmann and started talking to people from the Brazilian community about getting involved.

FS: Back in 2003 I was using Firefox. I knew it was already localized into Brazilian Portuguese, but the help wasn’t translated yet. I started looking for the Firefox localizer to get involved with localizing the help. SUMO didn’t exist back then, so I helped localize the help that came with Firefox.

 

What tips or tricks do you use for overcoming blocks and bugs in your L10n work?

RM: Depends on the area. In general, I try to work closely with the project owners for our locale.

MA: I mostly work with Verbatim. I mostly try to follow my dashboard and the email notifications I receive about updates to my projects and any bugs that are filed against them.

FS: I work mostly on websites so most of my work is done on web dashboard. Sometimes there are other projects that I help out with and that need our help to fix L10n bugs so we try to work together to resolve any issues and communicate a lot.

 

How do you help your team find new L10n contributors?

RM: One thing we’ve been doing is giving talks on localizing SUMO and gauging interest from those events.

FS: Like Reuben said, we give talks at universities and events like LatinoWare and try to recruit from there. We’ll even find places to do workshops and give tutorials on how to localize with Mozilla.

 

What’s your philosophy/method on mentoring new contributors?

MA: I try to start new contributors on Verbatim, cause it’s simple to learn and easy to sue. Once they become good at using Verbatim, I move them over to SUMO projects.

FS: It’s difficult and confusing for to teach some newcomers about localizing different projects (specifically the differences between localizing web projects and product projects), but we try to be as supportive and helpful as we can.

 

If you could identify several best practices that have helped you to become a successful Mozilla localizer, what would they be?

RM: A few best practices we try to follow: always avoid duplicating work! Double and triple check to make sure you’re not overwriting someone else’s work! I always ask for review to ensure good translation quality before checking in your work. Term consistency is important to us and it’s difficult to keep that consistency between SUMO, products, and websites. It would be really good to have a tool to manage and access terminology across those different projects.

FS: I’m really annoying because of how often I’m reviewing and editing translations, over and over again. I really try to check for details and consistency.

 

What projects are you most looking forward to working on this year?

RM: BrowserID has been really exciting! I’m also looking forward to Boot2Gecko, but I’m also shifting my focus to doing more coding.

MA: I’m helping translate ReMo for our website.

FS: Most of the time I enjoy localizing fun projects, like Firefox Flicks, but now I’m trying to focus more of my time on translating doc articles on SUMO and MDN.