A new Web-based localization tool

By Duncan Moore on September 21st, 2007

As Heri at Montreal Tech Watch reported, we recently rolled our own Web-based localization tool. Specifically, it lets you easily translate into any number of languages any application that uses Gettext. (We’re using Gettext to enable internationalization of CakeMail, which is currently in beta.)

We created this translation tool because we found that using desktop Gettext editors didn’t facilitate an agile workflow. When you’re making iterative improvements while simultaneously translating the whole shebang into another language, it can get ugly pretty quickly if there are several people using different local copies of the master file instead of accessing the same file through a Web interface…

However, just after our lead programmer, George, whipped up this nifty little translator, we realized we had reinvented the wheel somewhat: turns out there are already a few Web-based Gettext editors out there (Rosetta/Launchpad, Pootle, IRMA and Kartouche). On the other hand, from what we can tell so far, the existing tools may not offer all the features people want or need. For example, a hosted tool’s translation licensing policies may not be appropriate for everyone; other tools may require that you install the server and run it yourself. And the WordPress Codex mentions the following:

Note: many translators have found Rosetta to be a good starting point, but once it comes time to proofread the entire list of translations, many have opted to switch hand-editing the PO file or using a program like poEdit or KBabel, since the Rosetta UI lacks a search feature and other things that become essential when proofreading and editing.

So now the question is: is there room for another Web-based Gettext editor? You tell us. If you’re using Gettext, we want to hear from you. What are the current tools not offering that you need or want? Leave a comment below or drop us a line at hi@thecodekitchen.com.

Our Gettext translator tool would be free for non-profit open-source projects. Initial features include:

• Simultaneous read/write by several users anywhere in the world
• Permission-based access
• Unlimited languages per project
• Search/find within entire language file
• Journaling and unlimited undo (revert to any previous version)
• Integration of screen shots and notes to provide translators and editors with the all-important context of a given message
• Live updates to the language database from within the app
• SSL encryption

Below is a very preliminary mockup of the interface (Note that the tool won’t actually be called Translator–that’s just a placeholder name):

Filed under: Translation Tool – 

15 Responses to “A new Web-based localization tool”  

Feed for this Entry Trackback Address

1. Simon Law Oct 11th, 2007 at 7:59 am

   Your UI mockup looks really good.

   There are a few main features that web-based translation tools only do 80% well:
   1. Good support for distributed translation: multiple simultaneous authors, conflict resolution, unlimited undo
   2. Good support for proofreading: search and replace, spell-checking, statistics
   3. Control of translations: option to self-host, permissions, branching translations
   4. Tight integration with workflow: open API, modification of source

   Right now, desktop applications get most of this right. If you’ve got your translations checked into a source repository, you can get all four of these things. But you lose the ability to have outside contributors help with localization.

   Since this is a toolchain product, having all of these is pretty vital to getting good adoption. If I weren’t to use existing desktop tools, I’d probably go for a free software tool that would let me add missing features that are important to me. After all, the people who are the customers of this product are programmers, so it’s reasonable to expect that a popular tool will get a lot of community support.

2. Duncan Moore Oct 11th, 2007 at 2:31 pm

   Thanks for the input, Simon! This is exactly the kind of feedback that will help us decide which direction to take…

3. Mikko Ohtamaa Nov 19th, 2007 at 3:09 pm

   Hi Duncan,

   How about this wild feature: just point and click any web page text to translate it? Anyone could do Wiki style editing and the final translation could be determined by voting/heurestics to prevent vandalism.

   For example, translation ids could be embedded to web page code using Javascript and then a click causes a pop-up Javascript window loading where you can instantly translate text to another language. Or a simple search could find the original text string.

   Ps. If you want some (commercial) testing ground for your product I could have one small client doing Russian translations for few websites. I think we are going wth in-house tool unless we find something similar you have described here.

4. Duncan Moore Nov 22nd, 2007 at 7:13 pm

   Hi Mikko, and sorry about the belated reply.

   Thanks for the offer for testing! We’ll keep that in mind when we’re ready to open it up to third parties.

   Interesting ideas about point-and-click translation for websites… For this to work, I imagine that it would have to become a Web standard first, no? Then there’s the issue of copyright, as well as whether this approach would work with dynamically-generated sites.

   Food for thought, in any case!

5. Simon Law Nov 22nd, 2007 at 7:15 pm

   Duncan,

   Well, you could always put the translations under a permissive license, like Wikipedia does for its articles. I don’t think you have to make it a web standard at first, especially since web standards often need a reference implementation before you start the process.

   What’s probably going to be the biggest issue for translation like this is having to revert spam. I guess you could have trusted translators (maybe registered users or power users?) since random people updating your translations probably isn’t the way to go.

   You might also have a UI issue when people accidentally double-click on some text.

   Simon

6. Duncan Moore Nov 22nd, 2007 at 8:53 pm

   First, a clarification: I’m not sure that the point-and-click idea is compatible with what our tool would offer, since Gettext uses a language file hosted separately from the interface and the messages displayed are generated dynamically. But the idea of a point-and-click approach is interesting in terms of facilitating a more multilingual Web.

   Good point about the spam aspect! I’m sure the Defensio system could be brought to bear for something like this, though, from what I understand of their product (which we are now using on this blog!).

   If I clicked on a page to translate it, though, where would the translated text be stored, and how would it be displayed when someone wanted to view that language version later? The wiki approach might be a solution. I had an interesting conversation recently with Evan Prodromou about how one might create a reputation tool that would encourage more widespread translation of wiki entries. The concept of reputation/trusted status and/or voting heuristics for quality control is interesting.

   À suivre !

7. Simon Law Nov 22nd, 2007 at 9:06 pm

   Well, you could supply the same interface as libgettext, but make it database-backed. Because all of your translations are already stored in a database with your current tool, right? Or, the simpler hack would be to atomically replace the .mo files after someone has done a translation.

   I’m not sure generic automated spam detection would work so well with something like this. Maybe you’d want to run the translated text past an online dictionary, to see if it matches up a high percentage of the right words?

   Evan’s idea of building a reputation system is a good idea.

8. Mikko Ohtamaa Nov 23rd, 2007 at 6:15 am

   My great vision:

   - Each text editor has Wikipedia-like account (can be anonymous too)

   - All entries are stored in the database

   - You can plug-in the translation machine to any web server (PHP/Python/Java). it uses its own backend and the embedding is done with simple server-side hooks and few Javascript files

   - Everyone can edit entries. However, there is some kind of trust mechanism preventing vandalism. For example, anonymous edits need to be confirmed and users need to earn some trust points to make non-reviewed edits

   - The site texts can be rolled out regularly (once in a day) or manually by generating gettext .po files from the database

   - The web page itself may have Javascript-based pop-up interface for text editing. For example, in the bottom right corner you have an icon which opens a dialog box with text editing capabilities:

   - Choose languages (you can see few languages at a time)

   - Browse language entries for this page. The dialog loads them asynchronously via AJAX

   - Click any text to see its translation information in the target languages. The matching between actual web page visible text and gettext database entry can be done by heurestic matching (regexp can fill those %s in gettext) or by hidden embedded translation information on the page (e.g. a javascript snipped containing page entry -> gettext id mappings)

   - You can change the text instantly. However, the change is visible only for yourself until it’s reviewed and rolled out

   - You can save entries to database, see entry history and other version control and translation management specific actions using asynchronous Javascript calls

9. wishcow Dec 21st, 2007 at 3:10 pm

   Hi Duncan,

   We are working on an internationalized project http://www.traxtuff.com
   our main difficulty is having to generate the po files from the project, sending them to the translators (a.k.a friends) and having to integrate them back into the project.

   Our lead developer also decided that he really needs an html based po editor (great minds think alike).

   It would have been cool to allow the translators to connect to our development site’s html based “translation server” and let them translate the project directly, they can then see the results of the translation immediately without having to send us (the programmers) the translation files first.

   That’s why hosting the “translation server” inside our code is crucial, since it would have to synchronize automatically with code changes.

   If you are interested in turning this into an open source project, we would be happy to help out with the development - providing we have the same goals

   The mockup looks really cool by the way.

10. Eduardo Bacchi Kienetz Jun 10th, 2008 at 11:31 pm

    Whenever it is released as open source, please send me an e-mail so I’ll post a new in Brazilian Portuguese.

11. vdunjy Jul 22nd, 2008 at 7:13 pm

    nude celebs The third of the boys face against him by the vibrator.

1. 1 The Code Kitchen previews new localization tool | Montreal Tech Watch Pingback on Sep 24th, 2007 at 11:21 am
2. 2 BarCampMontreal3 report « Marc-André Cournoyer’s blog Pingback on Nov 3rd, 2007 at 11:04 pm
3. 3 Cross Lingual Wiki Engine Project at Codefest 2008 | Montreal Tech Watch Pingback on Jan 6th, 2008 at 9:45 pm
4. 4 Web Based Workflow Trackback on Apr 26th, 2008 at 7:55 pm

Leave a Reply

There was an error with your comment, please try again.

Name:(required)
Mail:(will not be published) (required)
Website:

Notify me of followup comments via e-mail