Translation status for ubuntu-docs

Tue Apr 3 09:03:07 UTC 2012

Al 03/04/12 10:10, En/na Matthew East ha escrit:
> On 3 April 2012 07:57, David Planella <david.planella at ubuntu.com> wrote:
>> Al 03/04/12 08:49, En/na Matthew East ha escrit:
>>> On 26 March 2012 11:09, David Planella <david.planella at ubuntu.com> wrote:
>>>> You're probably aware of the feature, but you can also alternatively
>>>> export translations to a separate branch, which you can choose to merge
>>>> to trunk at your convenience. In whichever way you use it, branch
>>>> exports and imports are recommended over manual exports and imports.
>>>
>>> Yes, I was aware of it, but I don't really see any benefit in using it
>>> over and above a simple export of po files from Launchpad. What are
>>> the reasons why a branch export is recommended over a manual export?
>>>
>>
>> In general,
>>
>> - Correct paths: Paths and PO file names of branch exports are correct,
>> unlike many manual exports
> 
> I think that, as you noted at the bottom of your email here [1], that
> this isn't the case!
> 
> [1] https://lists.ubuntu.com/archives/ubuntu-doc/2012-April/016482.html
> 

You're absolutely correct, which is why I think the current set up is
already the best we can have:

- Automatic imports
- Automatic exports (exporting to a separate branch).

Sorry I didn't include the info about the exports layout on my previous
reply. It was meant to be a generic list of advantages of manual vs.
automatic exports, and what I meant by that point is that in automatic
ones the files are named correctly (e.g. <languagecode>.po) and are
placed in the right location, which is something that often does not
happen with manual exports.

Now in the particular case of Ubuntu docs we've got the following layout:

ubuntu-help/ubuntu-help.pot
ubuntu-help/ca/ca.po
ubuntu-help/zh_CN/zh_CN.po
...

But Launchpad expects the common gettext layout, i.e. flat, with all .po
files and .pot file in one same folder:

ubuntu-help/ubuntu-help.pot
ubuntu-help/ca.po
ubuntu-help/zh_CN.po
...

Which in turn means the ubuntu-docs layout is not directly supported. I
only realised that after I had initially suggested to use automatic
exports to trunk, so I apologise for suggesting a non-working option. I
think it would still work if we were to set symlinks linking to the
right paths, but unless someone would like to volunteer for
investigating this approach, I'd suggest leaving trunk exports for now.

In summary, though, I'd still recommend the current setup (automatic
imports, automatic exports to separate branch) for this and future releases.

>> - More automation: no need to manually go to the web UI, request an
>> export, wait for Launchpad to reply, get download URL from Launchpad's
>> e-mail. Changes are committed daily to the branch, which can then be
>> merged to trunk with one bzr command, instantly, without having to wait
>> for Launchpad.
> 
> That might be true if the correct paths were maintained, but if they
> aren't, the po files have to be added manually anyway, and I don't
> think it makes much difference.
> 

It still offers advantages.

Compare (manual export):
1. Go to the docs project Launchpad URL
2. Request the full translations download (only project maintainers can
do this)
3. Wait for Launchpad to request (it might take from minutes, to hours
to days, depending on Launchpad's load)
4. Check your e-mail, retrieve the download link
5. Fetch translations from the download link, wait for download to complete
6. Uncompress tarball, fix filenames and paths if necessary
7. Put translations in the ubuntu-docs tree
8. Commit translations:
    bzr commit -m"Updated translations from Launchpad"

Vs (automatic export to separate branch):
1. Checkout latest translations:
    bzr checkout --lightweight
lp:~ubuntu-core-doc/ubuntu-docs/$RELEASE-translations
2. Put the translations in the ubuntu-docs tree. E.g. (where PODIR is
the checkout location of the previous command, and DOCSDIR where the
ubuntu-docs tree lives)

#!/bin/env bash

for f in "$PODIR/ubuntu-help/"*.po
do
        LANG=`basename $f .po`
        echo "Copying $f to $DOCSDIR/ubuntu-help/$LANG"
        cp $f $DOCSDIR/ubuntu-help/$LANG
done

3. Commit translations:
    bzr commit -m"Updated translations from Launchpad"

The second option (automatic export to separate branch) you can do in a
matter of a few minutes in a synchronous manner, while the first option
might take hours and you'll be depending on Launchpad and you'll have to
finish your work asynchronously.

> I'm not 100% up to speed on how bzr merge works, but won't the bzr
> merge command add the revision history from the translations branch to
> the main branch? If so, and given the massive number of daily changes
> to the translations branch, I think that this could dramatically
> increase the size of the revision history in the main branch,
> increasing download time for contributors.
> 

I'm not a bzr expert either, so I'm not in the position to provide an
authoritative answer. In any case, I'll just add a few points to the
discussion:

- With the 3-step approach above, you would not be merging revisions
with bzr, simply copying the files from the latest revision and adding a
commit. In that case, the size concern would not apply.
- I'm not sure how translation commits affect history in terms of size,
be it from merging an external branch or from having daily commits to
trunk. Note that daily commits only add .po files which have had
modifications in Launchpad since the last commit, so in days where no
one translates in Launchpad, you'd have no daily commit. The same if
e.g. only Italian translators do work: you'd then only have a commit for
it.po. Also note that this is similar with the GNOME approach:
translations are committed to trunk directly (with the difference that
it's translators who do the commits, instead of Launchpad).

>> - Latest data availability: expanding on the previous point, having the
>> latest data available without the need of manual intervention, makes it
>> possible to provide infrastructure to help community work around that
>> data. I've not announced it widely as it is not more than an experiment
>> for now, but I've been working on such a tool as a helper to
>> documentation translation work, and getting feedback from translators
>> (see below).
> 
> I agree that this could be an advantage, although if there is the path
> issue noted above, wouldn't it require manual intervention in any
> event?
> 

I can automate the whole process without manual intervention, basically
scripting the 3 steps outlined above.

In fact, I already do it and that's how I update translations on
http://91.189.93.101/ (btw, back online) daily. The only thing that's
missing is for me to set up a cron job to run once a day, which I'll do
whenever I've got some time.

Cheers,
David.

-- 
David Planella
Ubuntu Translations Coordinator
www.ubuntu.com / www.davidplanella.wordpress.com
www.identi.ca/dplanella / www.twitter.com/dplanella

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-doc/attachments/20120403/23f0525b/attachment-0001.pgp>