Translation status for ubuntu-docs
mdke at ubuntu.com
Tue Apr 3 08:10:38 UTC 2012
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 , that
this isn't the case!
> - 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.
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.
> - 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
gnupg pub 1024D/0E6B06FF
More information about the ubuntu-translators