Exporting translations back upstream
Providing translation work back upstream is now greatly simplified!
There is a lot of translation work going on in Launchpad, for Ubuntu as well as for other projects. There is also a lot of translation work going on for the projects, that is not done in Launchpad. This is especially true for many of the Ubuntu packages that have their own translation effort “upstream”.
For various reasons, translations imported from upstream projects may be altered in Launchpad. One possible scenario is that an error is detected in the upstream translation with no time to fix that upstream and import again, because the next Ubuntu release is imminent. The Ubuntu translator will then fix it in Launchpad and Ubuntu will have the corrected version. But now it is a matter of good community citizenship to provide that change back upstream.
So far, the only option here was to either communicate the changes manually or to download the whole translation file and provide that to the upstream project. Unfortunately this may not be easy to merge into the upstream translations which may have progressed in the meantime. This step is now simplified by a new feature that only exports those translation strings from Launchpad that were changed from what was originally imported from upstream. This export also includes translations of strings that were not translated at all before.
You can find information about the feature on the help page.
I really hope that this feature will find good use and that the upstream translations can profit much more from the translation work done in Launchpad. It is as easy as clicking on “export” and then forwarding the exported file to upstream.
Watch for more enhancements on the import/export front in the next releases.
January 29th, 2009 at 6:25 am
What is the expected workflow for using the partial export? Once you have the partial export what do you do with it to get it into upstream? For example, if I wanted to take a partial po file from this feature and wanted to apply it to GNOME upstream how would GNOME’s svn for translators need to be adapted to use the partial po file?
reference: http://live.gnome.org/TranslationProject/SvnHowTo
January 29th, 2009 at 8:52 am
The assumptions on which partial exports are based are that (1) the number of changed strings is much smaller than the total number of messages and that (2) the upstream template has changed as development has continued.
Referring to the Gnome workflow you mentionned, the partial export is used in the “vi xy.po” step. The partial file is expected to be fairly short so that manual replacement of the changed messages shouldn’t be too hard. This feature is meant to help with this step but it cannot automate it.
The long standing alternative is to download the full po file and merge that (semi-)automatically with the upstream version, using a tool of your choice.
January 29th, 2009 at 9:24 am
The main problem with the lack of coordination of launchpad (in the case of ubuntu) translations and upstream (in the case of GNOME) is that they translate everything they see untranslated, which is not bad, but usually LP translations do not have the same quality as Upstream, besides the manuals are not translated at LP, therefore there are usually mistakes and differences between the manuals and the UI.
January 29th, 2009 at 6:31 pm
@Henning
merge with a tool of your choice? What semi-automated tool would you reach for?
Doesn’t the tool which can be used somewhat depend on the format of the partial po file?
Let me ask it this way. Would it make sense for this partial po file to be a patch file that can be applied to the xp.po with the patch command instead of manually? Would a patch file be an easier format to integrate into existing upstream translation workflows without manual cut and pasting with a text editor?
-jef
January 30th, 2009 at 6:09 pm
Patches don’t work well with PO files (even though they look like regular text files, they are not: they hold a lot of program-generated metadata, that will cause conflicts). “Partial PO” files still work correctly with standard GNU gettext tools like msgmerge (except that you’ll need to add content-type declaration to the “partial” PO file). Partial PO files are also useful for reviewing (i.e. you see only what you actually need to review). I’ll extend documentation on https://help.launchpad.net/Translations/PartialPOExport to explain these bits.
January 31st, 2009 at 1:15 am
@Danilo:
Are there upstream project translation efforts outside of Launchpad currently use the partial po format regularly? I’m not making any arguments as to what format is best.. I just not sure upstream workflows are already encouraging people to use that format. And if they aren’t then just offering the format won’t necessarily help your translators get their stuff upstreamed. You might need to educate upstream projects about how to digest the format as part of their workflow.
The extended documentation will help. But you’ll have to be on the watch to see if there is still an impedance mismatch from established upstream translation groups when your contributors try to hand these partial files over. If upstream doesn’t know what to do with them, its not necessarily better. Back to the existing example, does the upstream GNOME translation team already make use of this fileformat from contributors?
One question, why is the manual msgstr “Content-type: text/plain; charset=UTF-8\n” step necessary?
Couldn’t the appropriate msgstr definition be added to the partial file as part of the launchpad export for each upstream po?
-jef
February 3rd, 2009 at 1:24 am
@Jef: simply because not having a header allows you to simply cat the two files together and then manipulate them with any of the existing PO tools. Upstream translators are usually well versed in dealing with PO files, so I’d like to give them a lot of options. Only one example is documented.
Also, having a header might allow people to import it into Launchpad, which is what we want to stop people from doing.