On Thu, 30 Jul 2009, Jeroen Vermeulen wrote:
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.
Hrm. Interesting. I own the team (AllTray Developers) and the team owns the project (and the branch), and I've got (at least insofar as I am aware) full rights to the project and the trees.
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!
I need to take a look and see if there is anything amiss in my project setup, if what you stated above was correct. Perhaps this means that there is a bug in Launchpad, also, but it is perhaps more likely that I plain messed something up or didn't do something right. I know that in the drop-down list that is offered, I can't select it, and when I enter it manually, it tells me that there is an error.
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?
My guess is that this is done for the reason suggested in the Info documentation for gettext: POSIX does not specify the character set of the C locale, which makes it implementation dependent. That more-or-less implictly makes it only safe to assume that the C locale has the 7-bit original ASCII character set. One example of using the C locale actually comes to mind: taking log output and dumping it to a relatively old dot-matrix printer. Probably not a terribly common use-case, and for many of the things I spit out to mine, I run through iconv and ask it to convert and transliterate as much as possible into my printer's character set (ISO-8859-1). If I send UTF-8 output to the printer, it freaks out (if there are actually any UTF-8 characters that are non-ASCII, anyway). Another use-case would be hardware terminals that might not be able to use UTF-8 output in the C locale (and the vintage of UNIX system that would be driving those terminals). It would be bad form, for example, to display proper quotes (which are representable in UTF-8-encoded Unicode text) in a locale where the operating system or display device would not be able to handle the input. Now, as an aside, I had thought about this once before. We very much so live in a Unicode world, and I've been quite happy to say good-bye to the days of asking the question “which text encoding is this in?” because now there is one character set (with multiple representations, sure, but autodetectable ones, for the most part) and most often it's used using a character encoding that is backwards-compatible with ASCII, at least for displaying ASCII text as much as possible. But, and I am sure that I'm not alone, though I may be in the minority, I still have devices and the like which don't talk Unicode at all. Most of those use ISO-8859-1, though I have one device (a _very_ old printer) that only takes ASCII input; everything else is a control code or otherwise gibberish when output there. So, “translating” into en_US.UTF-8 would be desirable. If this were five years ago, I'd say that being able to translate to even more specific character sets would be important, but I don't think that it is so much.
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.
The only thing (at least in my own use-case) that would ever be committed would be an updated .pot file, with the possibility of the .po files having new (yet-to-be translated) strings put in them. Whatever it is that the automake magic does when you regenerate the .pot file, anyway. I'm "okay" with deleting the files and re-adding them when needed (which is basically what I did today to avoid any conflicts, since it just wouldn't merge). But the mode of operation where basically Launchpad manages the translation files works well for me, at least in theory. That way, I can always have the up-to-date translations already available and integrated, and focus on adding and changing strings in the code for the translators. ;-)
(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.
So the newer translation wins? Hrm. Well, perhaps the best idea would be record the conflict and present it as an additional suggestion in the Web UI, and prioritizing the selected translation in Launchpad to resolve the conflict. That would actually be pretty nifty, I think.
(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.
Are "stacked" branches stacked virtually? Like, here's the big project, and here's a subdirectory which is not the project proper, but a sibling project or something (say, translations) and so branch (A) is the project, and branch (B) is the translations only, with (A) holding all of the other project? That is, when (A) is updated, and (B) is stacked on (A), does (B) see the new changes? Or is (B) a branch that will have it's own history and have to have (A) merged into it to be kept current?
(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.
Is that how it's done with the Automake stuff for gettext and translations? If so, I should be in the clear. I don't modify any of the files by hand...
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.
Scripting client-side would only work, I think, with knowledge of when imports and exports are taking place. If LP had an API that was, say, get_next_import_timestamp and get_next_export_timestamp, a client could poll those things and make smart decisions on doing the merges automatically and warning in case of conflicts so that user intervention could be performed. I think it would probably be more efficently done on the server, though, unless there's a simpler way to do it yet than that.
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.
Hrm. An interesting point... I will explore that road tomorrow and
see what it holds.
--- Mike
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)