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 writingA 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
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)