LWN: Comments on "Easing software localization with Transifex"

Easing software localization with Transifex

4utumn — Thu, 30 Aug 2012 14:06:25 +0000

Hello, everyone.

Our team just developed a new online localization tool, http://poeditor.com/

It started as a po editor, as the name says, but we now also support other popular localization formats.

Here are some its features,
+ unlimited projects
+ unlimited languages
+ unlimited terms
+ add contributors
+ open projects
+ stats
+ import from pot, po, xls, xlsx (for now)
+ export to po, mo, json, php array(for now)
+ support for context (without plurals for now)

We're constantly looking to improve our projects, so it would be great if you could give it a spin.
Any feedback is welcome. We hope it will come useful to you.

Sincerely,
Po Editor Team

Upstream translation on the GNOME project

stephane — Mon, 06 Apr 2009 10:25:57 +0000

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

Internal consistency

ableal — Sat, 04 Apr 2009 22:09:54 +0000

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

Transifex solves a lot of problems.

stickster — Wed, 01 Apr 2009 00:44:48 +0000

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

ivazquez — Sat, 28 Mar 2009 17:49:25 +0000

Performing translations within the web interface is planned for a future release. For now it requires a client-side solution such as Poedit.

Easing software localization with Transifex

magnus — Sat, 28 Mar 2009 09:22:47 +0000

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

rahulsundaram — Fri, 27 Mar 2009 01:12:23 +0000

"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

mezcalero — Thu, 26 Mar 2009 17:19:45 +0000

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

mmcgrath — Thu, 26 Mar 2009 16:39:43 +0000

One way to see transifex in action if you're a translator is to join Fedora and translate:

https://fedoraproject.org/wiki/L10N

Easing software localization with Transifex

danilo — Thu, 26 Mar 2009 16:37:16 +0000

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

danilo — Thu, 26 Mar 2009 16:26:12 +0000

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,
Danilo

Easing software localization with Transifex

danilo — Thu, 26 Mar 2009 16:07:53 +0000

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,
Danilo

Easing software localization with Transifex

mezcalero — Thu, 26 Mar 2009 16:01:34 +0000

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

hmh — Thu, 26 Mar 2009 15:15:16 +0000

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

omaciel — Thu, 26 Mar 2009 13:54:19 +0000

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

omaciel — Thu, 26 Mar 2009 13:48:51 +0000

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

nelzas — Thu, 26 Mar 2009 12:48:56 +0000

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

danilo — Thu, 26 Mar 2009 12:03:18 +0000

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

hmh — Thu, 26 Mar 2009 10:24:16 +0000

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

hughsient — Thu, 26 Mar 2009 09:44:05 +0000

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

jamesh — Thu, 26 Mar 2009 08:15:56 +0000

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.

Transifex solves a lot of problems.

madhatter — Thu, 26 Mar 2009 07:59:17 +0000

I thought LWN was pretty clear about point 1:

> People who are able to translate text into another language [...] are not
> necessarily developers, so their knowledge of VCS systems may be small.

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.

mmcgrath — Thu, 26 Mar 2009 03:55:57 +0000

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.

Easing software localization with Transifex

ivazquez — Thu, 26 Mar 2009 02:33:51 +0000

Just a quick note that 0.5.1 has just been released, and is available at the same locations above.