Closing Narro

7 years ago I started this project that didn't have a name for a year. Mozilla asked me if I can make it open source, which I did 6 years ago, and for which I thank Mozilla for pushing me to create my first open source project and supporting me along the way.

I started this project because I couldn't bare to translate monolingual xml files side by side and keep them in sync with a diff viewer.

I continued this project because I had a dream: open translations.

Anyone can contribute, anyone can fork a translation; much like open source software. What if you wanted Firefox in Klingonian or you wanted to translate a particular word differently just because you liked it that way ?

The dream is still a dream, but for the last years, my job (director of software development at a translation agency) and my personal life (future wife and kids) have and will take most of my time, so I have to admit that I won't be developing Narro anymore, but would still want to see this dream come true at some point with or without my help.

Narro's code will remain open as is, with no support.

There were two instances of Narro maintained by me, http://tradu.softwareliber.ro and http://a.maimult.ro/lmo . I will take those down because they aren't used anymore. I exported the valuable data (translations) in tmx files, which is standard for translation memories. You can download them from here: http://alexxed.fedorapeople.org/narro/tmx and import them in Pootle.

If you're looking for alternatives to Narro, I suggest Transifex or Pootle. Both have right now most of the functionality of Narro and more.

If you ever used Narro, thank you for that, you made me feel awesome!

New look based on jQuery themes

Since I'm not that fond of designing, I'd rather use someone else's work if possible, so I changed most of Narro's UI to use native jQuery UI elements so that you can apply any jQuery UI theme to change Narro's look.

What you see above is the redmond theme, currently users can't change the theme, but that would be a nice feature to have.

Have a look at the other jQuery themes if you don't like the above ones.

What's been done so far

Performance improvements

Under the hood, Narro's core is actually the translation memory concept.
If you're not into programming, imagine yourself listening to hundreds of users talking in 80 different languages and trying to relate everything to English.
If you're in programming, imagine 80 texts longer than 255 characters for each English text stored in a database.
It's a continuous challenge.

Feedback

Getting feedback is important, but gathering feedback is more important. Sure you can have everyone post their worries and wishes on a list, but building on that is a separate task that you need to do before you can act on it.
Arki did a fantastic job getting that done and that helped a lot.

Documentation

I'm not a fan of reading documentation in general, I'd rather just browse it. Jeff wrote the Narro wiki page on Mdn.

UI improvements

Translate and reviewing (proofreading) are separate actions with separate UIs
Everything needed to work with a Mozilla repository is bundled in a plugin.
UI improvements
Work with several texts as once, scroll as much as you need to have a clear picture of what you're working with.

Core improvements

HTML support.
SVN and Mercurial commit support.

Server

The current server is slow. So slow that sometimes I can't connect through SSH. There's a plan to move Narro to another server, waiting for a bug to review security.

Facebook's translation app

Just had a look at Facebook's translation app. It has some good ideas that should be implemented in Narro:

• big numbers about your progress, e.g. added translations and votes; definitely stimulating
• click on the other translation suggestions to copy them in the translation box
• good way of using placeholders; really descriptive texts inside them rather than %S or %$1S; but this is determined by the developers that create them
• glossary right under the translation box
• definitely appreciate the fact that they manage to squeeze the translation app in the middle of the page; good design

Not so great ideas imho:

• the text comment is placed under the text to translate; although greyed out, I think it may lead to confusion on what to translate, the text or the comment
• vote / translate switch; clicking on translate hides the suggestion list and shows the translation box only

TMX export

Just added a new column that shows the number of translations for each language, and next to that number, there's a TMX button that allows exporting all the translations in a TMX file. See it here.

The Mozilla build system inside a Narro plugin

I just finished a Narro plugin that sets up the Mozilla build system.

What it actually does on import is:

1. clones or updates the appropiate Mercurial repository
2. parses l10n.ini files to build the en-US directory with files to localize

and on export:

1. if the project is not Firefox, copies the required translation files from the associated Firefox project
2. builds a languge pack
3. runs compare locales and interprets the output to build Narro links to the contexts with errors or warnings

Let's get into details. Here's how the project edit page would look in Narro for a Mozilla project with the Mozilla Build plugin activated:

You need the mercurial path to the proper repository. Common options are comm-central, comm-aurora, comm-beta, comm-release and mozilla-central, mozilla-aurora, mozilla-beta, mozilla-release.

You need to specify the internal application type, browser (Firefox), suite (Seamonkey), mobile (Fennec/Firefox Mobile), mail (Thunderbird), calendar (Sunbird).

Also need the release name, this is empty for central, aurora, beta or release. This is used to find specific l10n.ini files, e.g. l10n-aurora.ini.

If the project is Seamonkey, Sunbird, Thunderbird or Fennec/Firefox Mobile, then you need some folders from Firefox, that's why you need to do this association here.

It makes no sense translating dom and toolkit folders again if you already did that in Firefox.

Now here's how the export page looks after an export, if the Mozilla Build plugin is activated:

You can see at the bottom the output of compare locales, with a link to the text to correct.
Also, you can see the xpi language pack as well.

What's happening in the background is quite complex and very platform dependent (Fedora/Centos/Debian/Ubuntu only supported).

You need to have make, autoconf-2.13, python, easy_install installed on the server.

But the result is quite amazing, since you can get an xpi language pack directly from the browser, no Mercurial, no build commands, no terminal, just the browser.

I'm currently converting all l10n.mozilla.org to use this plugin, so expect possible problems today.

Goodbye ZendFramework!

I was using ZendFramework for OpenID, Caching and Session handling. I had to keep ~700 files for this, which was too much, so I just removed this dependency and added a lightweight library for OpenID support, used QCubed file caching and standard session handling. Eventually this brought more speed and less files, so it's a good thing.

Also, as a bonus, you can now authenticate with your Google account as well. Authenticating with OpenID or Google leads to a pretty ugly user name, so that takes me to adding a real name property to users.

Revisited form states since I've seen many errors reported on that. If you leave the page open with a formstate for a while and come back and your session expired, then the form state is invalid. Previously this lead to an exception and a error message to the user. This was replaced by a javascript alert message and a redirection to the project list, so that the user can start again with minimum disruption.

Oh yes, and if you're wondering how Narro looks, just check this blog's background ;^)

Last but not least, I really appreciate the patience that people have in helping me to fix bugs and am glad that so many people find my work useful.