Michael B. Trausch wrote:
2. If you set up translation exports into a branch, and translation
imports from another branch, merging the translations from the two
branches can involve conflicts.
The way around this is to use the same branch for translation import
and translation export. The export will not happen if there are
pending changes on the branch, so the risk of export overwriting
changes you make to translations in the branch before they're imported
is fairly small.
This won't work: Launchpad will not permit me to make lp:alltray a
destination. It apprently must be one of my own personal branches.
It can belong to a team, so long as you're a member of that team. You
can "give" a branch to another owner, so whoever owns the project branch
could set up a team and make that the new owner of the branch.
/me adds note to the tutorial he was writing
A bit unfortunate how the privileges need to come together for this: you
need editing rights on the project, and be an owner of the branch, and
the branch still needs to be the one you want. Don't see how we can do
without any of those though, and given the implications I guess it
shouldn't be too easy to do anyway.
I had thought about filing bugs, but based on the conversation that we
had in IRC, I don't know that it would truly be worth it; they would
very likely be closed close to immediately. That said, I'd file a bug
to request that it be made possible to more tightly integrate
Translations into a workflow that is slightly more convenient, and I'd
file a bug to request that en_US be a translation target (but labeled
differently). I'll provide my viewpoints on them and if they seem
worthy as feature requests, I'll go ahead and file 'em.
Worse than being closed immediately would be staying open forever: "a
great idea that we don't have time for."
We deliberately rejected the "full circle" workflow as a design goal
because it was too ambitious. While implementing I came across a few
small design tweaks as a "cheap trick" to get at least some use cases
there anyway. If branch ownership is the only obstacle, let's see if we
can get around that!
As for en_US translations: we've had that request before and I am
skeptical about it. You make a good argument for your use case: keeping
the template in ASCII so everything runs nicely in the C locale. Now
that you've told us about it, I recall having seen one or two others
doing the same.
But how desirable is it? GUI-based programs and libraries should
probably run in a more descriptive locale. On the other end of the
spectrum there's software that you may not want translated at all, or
for which it really doesn't matter if you can't include asymmetric
double-quotes or Unicode bullet points—the nicer you make it look, the
more can go wrong. Question is, how much is inbetween?
Getting to the point, when I saw the feature of interfacing with Bazaar
branches, I thought there was gold there. My mental concept of the
process would be:
(0) A developer commits to the mainline, which Translations watches for
template and translation updates, and imports any it finds.
The ideal setup is to let Translations import the template from the
branch, and export the translations to it so you can ship them. But
yes, there may be more you want to do, such as letting translators work
offline using bzr as an upload interface.
We have something else in the pipeline that may fulfill that need
though. At some point we're planning to allow translators to upload
files to translations they don't have review rights for. The
translations in the files would go into the system as suggestions.
(1) Translations compares the imported translations to what it had in
the database before: if they are identical, Translations does nothing.
If there are differences, Translations looks at them and merges them
(with precedence given, in case of conflict at the Translations level,
given to the branch), saving them in the database.
This part we already have, pretty much. A translator with review rights
could get the snapshot from the export branch, edit offline, and then
upload straight to the Launchpad UI. The import process checks for
conflicts based on timestamps in the file header.
(3) If the developer wants Bazaar integration on the export side, then
use the specified destination branch (which would naturally be a mirror
of the mainline development):
Could be, though doesn't have to be. Something we haven't looked at yet
is stacked branches. In principle you could have a "mainline plus
translations" branch stacked on the mainline branch. We'd have to make
sure some of the internal components do the right thing in that
situation though.
(a) If necessary, merge the HEAD of the import branch into the
destination branch.
(c) Optionally, branch the import branch and attempt to merge the
export branch back into the import branch. If the merge does not
succeed, warn the group or person who owns the branch.
To minimize conflicts, always keep messages in the exact same order as
in the template and give things time to settle when there are template
updates. Also, with message sharing, avoid making translations specific
to any release series of the project. The current export code will put
those messages in a different place in the file.
This could be overkill for what most people think of the system for,
though it seems to make sense to me.
I think a lot of it could be scripted on the client side. If a clear
winner emerges and there are also clear benefits to doing it on the
server, the next step would be to integrate it into Launchpad. Or maybe
all it takes is some support improvements, such as adding web-service APIs.
For the moment, I'll try a brute-force method: use a cron job to merge
trunk into my translations export branch, one hour before Translations
commits to the branch, and see if that results in a workflow that fits
me. Obviously, though, that would not be very scalable.
There may be tricks to make LP do this for you. I don't know if there's
anything stopping you from mirroring a Launchpad branch on Launchpad.
Of course you can't have the translations export to a mirrored branch,
but it may enable some other approach.
Jeroen
_______________________________________________
Mailing list: https://launchpad.net/~launchpad-users
Post to : [email protected]
Unsubscribe : https://launchpad.net/~launchpad-users
More help : https://help.launchpad.net/ListHelp
