Launchpad logo and name.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index ][Thread Index ]

Re: [Launchpad-users] Translations branch keeps having status set to 'Merged'



On Wed, 29 Jul 2009, Jeroen Vermeulen wrote:

Michael B. Trausch wrote:

I have my trunk branch at lp:alltray. I branched this to lp:~mtrausch/alltray/launchpad-translations and told Launchpad Translations to commit to that branch (that doesn't quite work, though more on that later). Every time I commit to lp:alltray, Launchpad's code hosting thinks that my personal branch (~mtrausch/alltray/launchpad-translations) has been merged and marks its status as "merged" in code hosting. This is probably because trunk has the same history plus an addition, so it figures that the personal branch is useless. Once LP Translations commits translations, it comes back to "Development" status.

We've talked this over on IRC.  There were two separate issues:
[snip the resolved one]

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.

Therefore, it seems that one of two things is required:

(a) after every commit, I merge to the destination branch so it's up-to-date and can be merged back when the translations are updated, or

(b) I must avoid the use of the destination branch altogether, and manually sync translations every-so-often when I think about it.

I'm going to have to go with (b) for now, I would guess. The only two “workflows” that make any sense to me with Translations is to either do that, or be able to merge in translations nearly at-will.

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.

To go into that in slightly more detail; Translations is a _great_ service. Especially great for someone like myself---a unilingual speaker, even worse, a unilingual American English speaker who is only just learning gettext. Had I not read the entire gettext manual, I wouldn't have even realized that there were multiple forms for plurals in other languages. Oops.

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.

(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.

(2) If the developer does not want Bazaar integration on the export side, stop processing this project here.

(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):

(a) If necessary, merge the HEAD of the import branch into the destination branch.

   (b) Commit to the export 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.

This could be overkill for what most people think of the system for, though it seems to make sense to me.

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.

	--- Mike


This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.

(Formatted by MHonArc.)