Данилово блогче

Wed, 21 Oct 2009

Warning: This is not a plea to move GNOME translations to Launchpad. I am just publishing an analysis I did about how suitable Launchpad is for translating a big project like GNOME. I am using GNOME as an example because that's a big project I am most familiar with.

If GNOME was to switch translations to Launchpad today, this is what would happen: I am listing all the benefits, status-quos and missing features compared to what GNOME does today.


Easy to use web interface
Some would debate this, but Launchpad web interface is easy to start with, and good for maintaining translations as well: global suggestions help maintain consistency and speed up the work, review mechanism allows someone to ask for a peer review, etc.
Translations sharing between different releases
No need to put in extra effort to do identical translations for both GNOME 2.28 and latest trunk when all the GNOME modules branch for the 2.28 release; also, translation fixes can automatically go to 2.26, 2.24,... for any distributor's benefit who wants to keep using those older versions
Automatic commits of merged translations
Launchpad can provide automatic export of all translations merged with latest translation template as a bazaar branch (this can easily be used to automate commits to a git branch as well); there is one big caveat here, though (see below)
Not saying that GNOME's damned-lies are immature, but Launchpad is a complex system that is capable of delivering translations for entire Ubuntu which has over 300k translatable messages. It also does many things like taking care of conflicts between multiple translators working at the same time, etc.

Stays the same

Ability to work on PO files off-line
One can easily download a PO file from Launchpad, work on it using their favourite tools like Gtranslator, KBabel or po-mode, and upload it back when they are done
Ability to control who can do the translation for each language
Project in Launchpad can decide to let only translation team members for a particular language review translation suggestions (which anybody can submit); if there's no team for a language, project can decide either to lock those translations out, or to let anybody submit them; if needed, even translation suggestions can be limited to team members only
Ability to directly submit translations to git repos without going through the web interface
Launchpad will automatically pick these up as well, and import them pretty quickly, and the chance of conflicting translations will be minimal; even if conflicts happen, Launchpad will handle them gracefully but letting the last submitter review all the conflicts
Communication between translators still stays outside actual translations — this is not a good thing, and would be great to add to Launchpad; still, external mailing lists and forums is what everyone is using anyway, and Launchpad can even host mailing lists.

Would suffer

Statistics and regenerating POT files
Today, Launchpad can't regenerate POT files for GNOME modules, meaning that we can't import the latest POT files automatically — this is what Damned Lies is doing for GNOME today (however, without this, it'd be worthless to try to do automated commits), and up-to-date statistics are impossible without it
Workflow management
Launchpad has a slightly different concept of workflow management compared to damned-lies, and it's missing some core features like PO file assignment, and PO file submission for review (while it has even better review capabilities when translations are submitted through the web interface, there's nothing to allow submission of PO files for review: they are either rejected or accepted)
GNOME specifics
Damned Lies is heavily geared toward GNOME and thus can do things for GNOME that no other platform can. For instance, it's able to track string freezes for GNOME and email gnome-i18n about any problems. Or, report about intltool setup problems.
Complete control
Even though software behind Launchpad.net is free software, Canonical is still the major driver behind it. However, GNOME community would be able to implement any features they need (like the above workflow management or string freeze support) without anyone complaining :)

After this analysis, I feel reasonably confident that Launchpad is already pretty good for large projects wanting to manage their translations. Yes, there's always room for improvement, but there's already some workflow management, and one can live without built-in string freeze support.

And, since it's already "decent", the new focus for Launchpad is going to be slightly different from what it was in the past few years. That means that we will not concentrate on improving Launchpad for projects hosting their translations in Launchpad, but instead on having a two way communication between Launchpad and upstreams (especially upstreams living elsewhere).

As such, we will definitely not work on improving the Launchpad to provide string freeze abilities for a project, or to improve workflow management. We will, however, work on regenerating POT files because that's implicitely related. But more on that in the next few days.

[17:29] | [] | # | G | | TB
RE: not implementing string freeze support, it probably wouldn't be all that difficult for someone who knows the LP code, as from a usability perspective, it could probably be integrated with the series/milestone management for projects, assuming that Translations already has some support for dealing with different series/branches of a project easily.

I'd like to see something similar for other freezes as well, but I dream. :)
— Posted by Rodney Dawes at Wed Oct 21 17:51:26 2009
IMO, transifex.net is a MUCH better solution.
— Posted by neo at Wed Oct 21 17:52:15 2009
I for myself would appreciate a Launchpad-powered GNOME infrastructure.

Ubuntu, imo, is the place to be for a Linux project, since their doing most things right as an distribution.
— Posted by Rabe at Wed Oct 21 18:28:45 2009
Git support......
— Posted by John Stowers at Wed Oct 21 18:46:11 2009
@neo: if you want to make a case for Transifex, feel free to do so.  "MUCH" is not a qualitative statement, even if it's broadly quantitative. This was not an excercise in what GNOME should move to, it was about describing interesting features that Launchpad has and GNOME doesn't get the benefit of, and of interesting features that damned-lies has and Launchpad does not.

@John: Launchpad can already import git branches. What we'd miss is commit to git branches, and that might happen as well in the future.

@Rodney: yeah, and we are hoping we'll see some users implement it for everybody else to benefit as well :) If not, we might get to it later.

Everyone, thanks for the input!
— Posted by Danilo at Wed Oct 21 18:55:25 2009
One thing that makes launchpad simply inacceptable for GNOME translations is that canonical claims to receive all translations under BSD licence (see https://help.launchpad.net/Translations/LicensingFAQ ).

I say "claims to", because translations are obviously a derived work of the original strings, which are copyrighted by the original authors and under the licence of the original work. In the case of GNOME, the original licence is usually GPL and thus the translations are GPL too, canonical's claims nonwithstanding.
— Posted by chpe at Wed Oct 21 19:17:37 2009

How about you use a nice search engine?

— Posted by neo at Wed Oct 21 21:47:16 2009
What I find most interesting about Launchpad is that it's a sort of TVCS, a translation version control system: since PO files are a blend of derived and source information, normal VCS operating on text line level is not sufficient; since translation maintenance is very different from code maintenance, normal VCS procedures (esp. branching) is not appropriate. Launchpad exhibits TVCS features explicitly through translation sharing and automatic commits (and picking up of external commits), as well as implicitly by avoiding conflicts due to merging. Unless I'm mistaken, there's also the capability to track modification-review status by message (rather than by file), which is crucial for any kind of organized review in teams. These are, in my opinion, great advantages for translation workflow.

What I'm ambivalent to in Launchpad are its work coordination features (who can translate what, who translates what... in fact, I didn't really pay intention to which such features there are exactly). This is probably because I was never a part of a big team (never more than 3-5 active people), so haven't yet experienced coordinatorial problems which would require structured solutions.

There are two things I don't like about Launchpad, which when put together, prevent me from wanting to use it in any capacity. I'm speaking here of Launchpad as a tool in itself, so I won't touch the issues with upstream synchronization in Ubuntu's deployment (it has been covered sufficiently by now, and its anyway the focus of immediate future development).

The first thing is that, while it's a TVCS, Launchpad does not provide VCS-like command line interface. If I want to update dozens of POs quickly, I cannot update my offline checkout with one command, update translations, and commit changes with another command (this we can do in KDE's translation system, without the need to fetch the code too and absolutely everything else from the repo). Going through web interfaces here, manually selecting and downloading and uploading complete files, as compared to svn up/svn ci (or the like) is just not an option for me[*]. Why I would want to download/upload POs in the first place, is related to the second issue.

The second thing I don't like about Launchpad is its web interface as the direct translation tool. I think that a web interface in general, in the foreseeable future, cannot beat a offline translation tool (set of tools), but here I refrain to commenting on what Launchpad currently provides. Moving between messages is clunky; for example, I can choose to view untranslated messages, but then for a given message I cannot see messages immediately before and after it, which leaves me without positional context. Search capability is way too simple, and again provides no positional context for found messages. There is no diffing at all, such as between previous and current msgid in fuzzy messages, or between msgid of current message and of suggestion translatation; diffing is crucial for longer texts, both for efficiency and for quality (imagine paragraph of several sentences in which a single important word changed). There is no way to add translation comments (showstopper for me). There is no highlighting of special syntax in text, nor any assistance with it (such as quick inserting of XML-like tags). Not the least, compared to an offline tool Launchpad's translation interface is horribly slow.

Another general problem of web translation interfaces is their non-modularity. Unless I download and translate locally, I have at my disposal only what that single interface provides. With an offline PO editor which misses this or that feature, I can use any other tool on the side which provides it. For example, above I complained about too simple search in Launchpad; with an offline PO editor having the same problem, I could use an external search tool when necessary, such as msggrep or pogrep. Same goes for language-specific and project-specific verifications, metadata normalizations, etc.

(There are positive sides to Launchpad's translation interface, as compared to an average offline PO editor. It gets correctly that contexts and extracted comments should be shown by default, always, and conspicuously. It does not throw elements of the message all over the screen, but keeps them bunched together and visible for each message. Extremely importantly, when issuing suggestions it also shows who made that translation and when -- here TVCS meets translations interface, so this is not available in any offline tool as of yet.)

[*] I have to add here that the two most important TVCS features I've identified so far, translation sharing and modification/review ascription, I already have wrapped around generic VCS workflow (still semi-experimental, though, but used on daily basis), so for me they are not killer features of Launchpad that would surmount the web interface woes.
— Posted by Chusslove Illich at Thu Oct 22 09:25:09 2009
chpe: the intent of getting you to license your translations under liberal terms is to facilitate reuse of those translations in other projects.  In exchange for this, you get use of all the other translations people have made using Launchpad.

As for your argument about the license on the original code constraining how a translation can be used, I'd agree with you to the extent that those strings are copyrightable.

I'd argue that if two unrelated projects happen to use the same string (e.g. common menu items like "File", "Open", etc), then it shouldn't matter which project the string was translated in first: it should be usable in both projects assuming that the translation itself has a compatible license.  And that is the case that the BSD licensing is supposed to facilitate.

If you've got other ideas about how to better achieve this goal, I'm sure the Launchpad team would be happy to hear.
— Posted by James Henstridge at Thu Oct 22 09:37:48 2009
chpe: one more note: the Launchpad terms of use ask contributors to license translations to everyone under the BSD license.  Canonical is not getting any rights to those translations that are not available to everyone else.

The effect is pretty much the same as the copyright disclaimer the FSF Translation Project requires, but means you maintain copyright over your work.
— Posted by James Henstridge at Thu Oct 22 09:46:50 2009
@chpe: translations end up under the GPL license combination when they are integrated into software that needs to use them, even if they are originally licensed as BSD.  The reason is simple and has been well explained by James.  Also, note that many of the translators in GNOME are breaking licensing by simply re-using GPL translations in LGPL software (like Gtk+ and similar: many of them use translation compendia containing translations from other translators [so they don't own the copyright] which were originally for a GPL software).

@Chusslove: I agree that there is no on-line tool that can beat combination of offline tools at this point. But, if we were going to extend tools further, I'd draw them in the direction of collaboration and that's an area where off-line tools cannot easily gain any ground. Of course, it's possible to do many more improvements in Launchpad as a generic translation tool (similarity/fuzzy matching for suggestions, showing more positional context, better search and filtering,...), but there's a lot of work involved in getting there :)  Now that Launchpad is free software, I hope we'll get many more people interested in driving that forward.

@neo: thanks for the pointer and the polite approach you generally have. However, I've already commented on that article long ago explaining what is incorrectly stated there. Yes, please take a look at that page and actually read further down than just the article.
— Posted by Danilo at Thu Oct 22 10:43:37 2009

I hate Bugzilla. I also cannot reply to bugzilla comments via email. It wastes my time.
— Posted by Vadim P. at Thu Oct 22 21:17:35 2009





Danilo Segan

This is blog (web log) of Danilo Šegan (or Данило Шеган).


< October 2009 >
    1 2 3 4
5 6 7 8 91011

My study page
Friends' Blogs
alex (en)
bc (en)
Bojan Živanović (sr)
Carlos (en)
Goran (sr)
imp (sr)
lilit (sr)
Oskuro (en)
Zombie (sr/en)