Weekly Edition
Return to the Front page
| |||||||||||
Easing software localization with TransifexTranslating text strings into other languages, called "localization" or "l10n", is a critical part of extending the reach of free software. But it is equally important that those translations make their way upstream, so that the translation work is not duplicated, and that all future versions can benefit. Making all of that easy is the goal of Transifex, which is a platform for doing translations that is integrated with the upstream version control system (VCS). The project recently released Transifex 0.5—a complete rewrite atop the Django web framework—with many new features Transifex came out of work done in the 2007 Google Summer of Code for the Fedora project. Dimitris Glezos worked on a project to create a web interface to ease localization for Fedora. In the year and a half since then, Transifex has grown greatly in capabilities, and is now used as the primary tool for Fedora translations. One of the key aspects, as can be seen in the SoC application is a focus on being upstream friendly. ![[Transifex project view]](/images/transifex_sm.png)
People who are able to translate text into another language—for good or ill, most software is developed with English text—are not necessarily developers, so their knowledge of VCS systems may be small. In addition, they are unlikely to want to have multiple accounts with various projects who might need their services. Transifex abstracts all of the VCS-specific differences away, so that it presents a single view to translators. This allows those folks to concentrate on what they are good at. Transifex interfaces with multiple different VCS systems that a development project might choose to hold its source code. The five major VCS packages used by free software projects: CVS, Subversion, Bazaar, Mercurial, and Git; are all handled seamlessly by Transifex. A translator doesn't have to know—or care—what the project chose, and their translations will be properly propagated into the repository. ![[Transifex language view]](/images/transifex1_sm.png)
This stands in contrast to Canonical's Rosetta, which is also a web-based translation tool, but it is tightly integrated with Launchpad. That requires that projects migrate to Launchpad to take advantage of the translations made by Ubuntu users. Many projects are skittish about moving to Launchpad, either due to its required use of Bazaar, or due to the non-free nature (at least as yet) of the Launchpad code. No doubt there are also projects who are happy with their current repository location and are unwilling to move. Because of the centralized nature of Rosetta, translations tend to get trapped there, leading some to declare it a poor choice for doing free software translations. Perhaps when Launchpad opens its code, and support for more VCS systems is added, it may be a more reasonable choice. For now, Transifex seems to have the right workflow for developers as well as translators. The 0.5 release adds a large number of new features to make it even easier to use and to integrate with various projects. The data model has been reworked to allow for arbitrary collections of projects (i.e Fedora 11 or GNOME), with multiple branches for each project. A lot of work has also gone into handling different formats of localization files (such as PO and POT formats), as well as supporting variants of languages for specific countries or regions (e.g. Brazilian Portuguese). For users, most of whom would be translators, 0.5 has added RSS feeds to follow the progress of translations for particular projects. User account management has been collected into its own subsystem, with features like self-service user registration and OpenID support for authentication. In addition, the VCS and localization layers are easily extensible to allow for supporting other varieties of those tools. Transifex 0.5 has the look of a very solid release. Glezos and others from the Transifex team have started a new company, Indifex to produce a hosted version of Transifex (at Transifex.net) that will serve the same purpose as Wordpress.com does for Wordpress blogs. Projects that don't want to host their own Transifex installation can work with Indifex to set up an localization solution for their code. Meanwhile, Indifex employees have been instrumental in the 0.5 rewrite and will be providing more development down the road. Glezos outlined their plans in a blog post in December. Because of its openness, and its concentration on upstream-friendliness, Transifex has an opportunity to transform localization efforts for free software projects. There are a large number of willing translators out there, but projects sometimes have difficulty hooking up with them. Transifex will provide a place for translators and projects to come together. That should result in lots more software available in native languages for many more folks around the world. (Log in to post comments)
Easing software localization with Transifex Posted Mar 26, 2009 2:33 UTC (Thu) by ivazquez (subscriber, #50782) [Link] Just a quick note that 0.5.1 has just been released, and is available at the same locations above.
Transifex solves a lot of problems. Posted Mar 26, 2009 3:55 UTC (Thu) by mmcgrath (subscriber, #44906) [Link]
We've used Transifex to translate a lot of stuff in Fedora with great success. One thing that's not quite clear from the article is the number of problems Transifex actually solves. In particular:
1) Translators aren't all super technical people who have the time to learn every scm that all the engineers start using. Transifex allows them to translate without having to learn bzr, git, svn, etc.
2) As a developer and as someone who uses transifex, it's nice to just have stuff translated. I've never once had to worry about it, I make a change, it gets translated in my repo as if I'd done it myself. From the developer point of view, it's just that easy.
I've been working with these guys and running the old TG transifex and the new Django Transifex and wish Indifex the best of luck. If you're a company who needs stuff translated, give glezos a call. I'm positive he'll take good care of you.
Transifex solves a lot of problems. Posted Mar 26, 2009 7:59 UTC (Thu) by madhatter (subscriber, #4665) [Link]
I thought LWN was pretty clear about point 1:
> People who are able to translate text into another language [...] are not
but point 2's a great one; it's nice to see some positive feedback for l10n-made-easy, from the developers' side. If I only spoke a second language, I'd be minded to shoot off Right Now and see what I could translate.
Transifex solves a lot of problems. Posted Apr 1, 2009 0:44 UTC (Wed) by stickster (subscriber, #40146) [Link]
I know this is probably sounding like ad copy, but I had to pitch in my two cents anyhow. I also found working with Transifex very pleasant as a content developer, because it really reduces a lot of the extraneous side work to manage access for many additional people. You don't have to manage submission processes; you can simply monitor your commit list as usual and everything just happens as it should. The jumps in functionality over just the last few months have been phenomenal for submission and reporting, and I know there's much more planned.
Perhaps even more importantly though, Dimitris and the rest of the Indifex team are great to deal with from the standpoint of a project poobah. They provide quick issue resolution and a clear vision of where they want Transifex to go in the future. They truly understand the power of the open development model, and know how to work collaboratively with their customers, peers, and translation communities. Based on the results so far, I have no doubt that their work will be a huge success.
Easing software localization with Transifex Posted Mar 26, 2009 8:15 UTC (Thu) by jamesh (guest, #1159) [Link]
I know this article is about Transifex, but it doesn't help to give an incorrect portrayal of its competitors.
It is true that if a project wants to use Launchpad's translations system, it will need to be registered in Launchpad. It is not true that this implies using Launchpad's code hosting system though. There are a number of projects that use Launchpad for translations but not version control.
At the moment, version control system integration for Launchpad translations is not a strong point, so you aren't at a disadvantage if you host your VCS at a different site.
Saying that "translations tend to get trapped" in Launchpad is a pretty loaded phrase. A project owner can import templates and existing translations using the standard PO file format. They can then export the translations in the same format, with the translations made within Launchpad being BSD licensed (no advertising clause). The translators for the project don't need any special knowledge of either the import or export procedures.
The translations will remain in Launchpad though, since it may suggest those translations for other projects where the same strings have been used. Most people see this as a benefit, and a benefit to using a shared translation system rather than a disadvantage of centralisation. Chances are, some of the translations for your application originated from another project (this is one of the reasons why translations produced within Launchpad are BSD licensed).
Disclosure: I work at Canonical, and was a part of the Launchpad team. This comment represents my own views, rather than being any kind of official statement.
Easing software localization with Transifex Posted Mar 26, 2009 10:24 UTC (Thu) by hmh (subscriber, #3838) [Link]
Actually, all it takes is for Canonical to take a very pro-active approach to _pushing_ the translations upstream, and people will stop looking at Rosetta like a place where translations "get lost as far as the outside world is concerned".
Or, if you already do it (which is likely to be true for at least a subset of the packages), disclose that fact properly, with reports every 6 months or so, to the community at large.
Easing software localization with Transifex Posted Mar 26, 2009 12:03 UTC (Thu) by danilo (subscriber, #57549) [Link]
That's a completely untrue statement. First of, you are talking about Ubuntu translations in Rosetta, not about any translations in Rosetta. Next, if Canonical is to push translations upstream "proactively" (i.e. somebody with no knowledge of all the languages that Rosetta contains translations for would go to hundreds of upstream projects times the number of translation teams, and send them the translations), we'd get even more bad press because we are submitting them the work they are not asking for. We're actively encouraging Ubuntu translators to work with upstreams (and we are providing tools to help with that collaboration), but we simply don't have resources to learn all the languages and have people talk to a thousand different upstream translation teams. Also, Ubuntu will have a dedicated person to work on translator collaboration in the next few days.
The same statements are brought up by Og Maciel in quoted article, where, in the comments, he basically agrees that most of his points are untrue in response to others' comments. It's unfortunate that this article is still being used as a reference to problems in Rosetta, when his comments were outdated by a few years.
Also, Rosetta at this moment is not a competitor to Transifex (which doesn't mean we won't make it so in the future ;). FWIW, we could make Rosetta talk to Transifex for translation submission, and I think that would be a great idea. What Rosetta does provide is a web-based UI for managing translations on a lower-level, requiring even less technical skills on translators' side.
Yes, maintainers have to do some manual work to make it so easy for translators in Launchpad, and that's exactly the step where Transifex shines: helping maintainers set up their translations. I'd argue that it's more of interest to maintainers than to translators (a proper set-up in Launchpad is easier for translators, but harder on maintainers to sync).
I am currently a developer of Launchpad Translations (code named "Rosetta"), but I have also contributed a lot to the free software i18n in the past.
Easing software localization with Transifex Posted Mar 26, 2009 13:48 UTC (Thu) by omaciel (subscriber, #49553) [Link]
Hi Danilo,
"The same statements are brought up by Og Maciel in quoted article, where, in the comments, he basically agrees that most of his points are untrue in response to others' comments."
I'm sorry Danilo but I believe you misunderstood my comments. What I said was that I had designed a blueprint to try and remedy the disconnect that there is between Ubuntu translations and upstream's.
Last time I checked, even if you don't host your code in Launchpad, you still have to manually upload newer translation catalogs (pot files) in order to "synchronize" the existing translations, which is suboptimal, but I *know* how understaffed you all are and that this will be resolved.
Transifex, in my opinion is a *great* option for those who need to manage their translations but either don't have the resources to handle the requirements or don't want to bother with it. The tool completely abstracts out the underlying "engine" and allows translators to get the job done.
Disclaimer: I do not work for either company or projects here mentioned.
Easing software localization with Transifex Posted Mar 26, 2009 16:07 UTC (Thu) by danilo (subscriber, #57549) [Link]
Hi Og, in my reading, you seem to confirm that there is a "disconnect between Ubuntu translations and upstream's", but not necessarily because there's something wrong with Launchpad as a tool. IMO, that's due to social interaction that exists (or doesn't exist) between Ubuntu translators and upstream translators. There is really not much we can do in that particular case. I am not saying Launchpad Translations is perfect, but it's far from being the cause of any problems you mention in the article - today.
As for your second point, uploading a tarball, or downloading one back has so far been a well used interface for project maintainers: if it's working so well for so many projects, I don't understand why do you insist that it's unusable. Translators have had a chance to completely enjoy easy to use interface for translation, and I simply can't see what do you think is harder for translators with Launchpad than with Transifex (actually, I can see that a lot of things are easier for translators).
Now, Transifex is a great tool that helps maintainers with allowing outside contributions from translators. At this time, it beats Launchpad Translations hands-down when it comes to effort a maintainer needs to do to accept outside contributions. But, this is only for maintainers: I see no advantages in the approach for translators.
And, we _are_ working on making this easier for maintainers as well.
But, on some points, we'll simply have to agree to disagree.
Cheers,
Easing software localization with Transifex Posted Mar 26, 2009 15:15 UTC (Thu) by hmh (subscriber, #3838) [Link] First of, you are talking about Ubuntu translations in Rosetta, not about any translations in Rosetta. I don't know about others, but I certainly mean only translations to upstream software (i.e. stuff that would be useful outside of Ubuntu)... Next, if Canonical is to push translations upstream "proactively" (i.e. somebody with no knowledge of all the languages that Rosetta contains translations for would go to hundreds of upstream projects times the number of translation teams, and send them the translations), we'd get even more bad press because we are submitting them the work they are not asking for. You just submit it once, or maybe once every year, with a pointer to a system very much like the one you have for packages derived from Debian, where the upstream maintainer can subscribe to update notices for translations? It is not that hard a problem to solve. In fact, you probably already have something like this. Then you track the use of this system, and you can produce hard numbers if anyone says translations to upstream material "get lost" inside of Rosetta. We're actively encouraging Ubuntu translators to work with upstreams (and we are providing tools to help with that collaboration), but we simply don't have resources to learn all the languages and have people talk to a thousand different upstream translation teams. Fair enough. But that wouldn't make the (maybe unfair) idea that "translations made in Rosetta end up not spreading upstream and to others" any less true, should it be true at all.
Easing software localization with Transifex Posted Mar 26, 2009 16:26 UTC (Thu) by danilo (subscriber, #57549) [Link] Fair enough. But that wouldn't make the (maybe unfair) idea that "translations made in Rosetta end up not spreading upstream and to others" any less true, should it be true at all. If you modify that statement to say: "translations made in _Ubuntu_ end up not spreading upstream and to others", I might agree. Rosetta is a tool to organize a translation effort. It allows one to keep track of changes between upstream, and also to only download such changes. Ubuntu has had a lot of problems with how their translation effort is organized, but that's being actively worked on, and I am sure will hugely improve in the next few months. Translations that are eg. done in-house in RedHat and/or SuSE do not go anywhere either (I know they did that in the past, not sure what they do today). They just don't have a public service like Launchpad where such translations are easily accessible and visible to everyone. Openness is sometimes a two-edged sword, but I'd always go for openness and visibility. And I am not saying that there are not improvements that we can make. But, this has nothing to do with comparing it to Transifex, where Transifex has full control of upstream translations. There are very successful Launchpad examples where projects directly host their translations in Launchpad. They are, naturally, neither outdated nor have any problems with syncing. And after you go past syncing, Transifex is definitely not a competitor to Launchpad Translations (eg. Pootle is much more suitable to be in the same sentence). Cheers,
Easing software localization with Transifex Posted Mar 27, 2009 1:12 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
"Translations that are eg. done in-house in RedHat and/or SuSE do not go anywhere either (I know they did that in the past, not sure what they do today)."
Red Hat makes a strong effort to push all translations upstream. If you have seen anything that suggests otherwise, do let me know. Grand claims without references aren't very helpful.
Easing software localization with Transifex Posted Mar 26, 2009 9:44 UTC (Thu) by hughsient (guest, #52199) [Link]
I've talked to Dimitris quite a bit about Transifex at conferences. He's always been energised and passionate about Transifex, and for this reason I think he's going to succeed in capturing market share with Indifex. Given that the 0.5 Transifex release "just works" for developers and translators, I think the problem of submitting translations is now solved for open source software.
I've been an early adaptor of Transifex as maintainer of PackageKit, and I've seen the number of high quality translations swell from 4 to 32 in 18 months. For me, I believe Transifex has accelerated the adoption of PackageKit due to the number of high quality translations, and I thank Dimitris for making that possible.
I wish him the best of luck.
Easing software localization with Transifex Posted Mar 26, 2009 12:48 UTC (Thu) by nelzas (subscriber, #4427) [Link]
So what a (potential) translator has to do to use this? How can one find projects using it (googled: project using transifex - in the first results page, saw only one project with the question transifex or launchpad)?
also does it handles right-to-left languages? Thanks
Easing software localization with Transifex Posted Mar 26, 2009 13:54 UTC (Thu) by omaciel (subscriber, #49553) [Link]
The Fedore project is a good example of a project using Transifex, and the LXDE project guys were considering it as well.
As far as support for left-to-right (and vice-versa) the tool serves out translation catalogs (po files) and allows you to submit it back to the proper project. In other words, you translate it offline using your own tools. One of the advantages that it has to offer is that once you submit it, if you have the proper credentials, it gets automatically applied to the source code!
There are also other advantages/features, such as having up to the minute statistical information for a project, as well as the ability of having at a glance a "picture" of who is doing what, which for project managers, is a great feature to have.
Anyhow, I'll let the Transifex developers chime in with their feature list. :)
Easing software localization with Transifex Posted Mar 26, 2009 16:39 UTC (Thu) by mmcgrath (subscriber, #44906) [Link]
One way to see transifex in action if you're a translator is to join Fedora and translate:
Easing software localization with Transifex Posted Mar 26, 2009 16:01 UTC (Thu) by mezcalero (subscriber, #45103) [Link]
Tx is the best thing since sliced bread. For an upstream maintainer i18n is otherwise just pain: you have to hand merge a huge amount of patches that you don't understand (I don't speak Swahili, sorry!) band patches that usually have a pretty low quality since the authors are no die-hard hackers.
With Tx all this is gone. For supporting i18n all I need to do is run "git merge" from time to time to merge in new translations. And that's just awesome. I am pretty sure that Tx is exceptionally useful from a translators perspective as well, but for me only the upstream maintainer perspective matters directly. And it cannot get any better then just having to type in a single git command.
Transifex is plain awesome.
Easing software localization with Transifex Posted Mar 26, 2009 16:37 UTC (Thu) by danilo (subscriber, #57549) [Link]
I agree, this is the biggest advantage of Transifex. Though, I disagree it can't be made simpler: it can happen without you typing a single command. ;)
Easing software localization with Transifex Posted Mar 26, 2009 17:19 UTC (Thu) by mezcalero (subscriber, #45103) [Link]
Actually it can. You can configure Tx to commit directly to your master branch instead of a seperate i18n branch. That way you don't even have to merge things yourself anymore. But quite frankly I am always a bit uneasy if things commit directly to master, since only one guy should ever commit to master of my project. And that's me.
Easing software localization with Transifex Posted Mar 28, 2009 9:22 UTC (Sat) by magnus (subscriber, #34778) [Link]
Looks like an interesting project.
One things that's unclear to me, is how translations are actually done. Can you actually translate strings inside of this web interface or is it based on downloading and uploading .po files?
Easing software localization with Transifex Posted Mar 28, 2009 17:49 UTC (Sat) by ivazquez (subscriber, #50782) [Link]
Performing translations within the web interface is planned for a future release. For now it requires a client-side solution such as Poedit.
Internal consistency Posted Apr 4, 2009 22:09 UTC (Sat) by ableal (guest, #57174) [Link]
(Just a late note for anyone who happens to re-read this)
The major difficulty I've found with collaborative translation is ensuring internal consistency. Consider this: in a program, there is a menu item called, in English, "Settings". This is referred to 35 times in 24 separate pages of the documentation. Chances are that, if different persons edit different pages, they'll use different words to translate that item's name.
I've three ideas about this: 'wiki'fying/voting, more hyper-linking in source, a glossary. Don't know how well they're implemented in these systems, I've only tried 'pootle' (which is a well-meaning effort, but limited - all you get is a bunch of proposed translations).
Upstream translation on the GNOME project Posted Apr 6, 2009 10:25 UTC (Mon) by stephane (subscriber, #57867) [Link]
The upstream translation of the GNOME project is managed with Damned Lies (http://l10n.gnome.org) a similar but different solution to Transifex:
http://live.gnome.org/DamnedLies
|
|||||||||||