Michael B. Trausch wrote:
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 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.
I'm not entirely certain that owning a team also makes you a member... Can you also join the team as if you weren't also the owner? It sounds like a bug in the ownership check, yes.
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).
In this example, the right thing to do is probably not to log non-ASCII data, unless the log file has a well-defined encoding. So that's perhaps more of a data i18n issue than a software translation issue.
Insofar as the messages come from the software itself, it sounds like one of those cases where you shouldn't want to translate the original messages anyway, or have non-ASCII characters in them.
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.
I agree that we can't just pretend that every environment will support Unicode. But how important is it for these specific programs to support non-ASCII characters in the English messages when run in environments that support them? Is it really worth the extra effort, or would pure-ASCII messages be acceptable for these programs?
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.
That's a different matter: you can tell Launchpad to import just the templates from your branch. The export option will only export the translations, so you'd have templates going one way and translations the other. When Launchpad imports a new template, it automatically updates the translations: messages that are no longer in the template are gone, and new ones are added as untranslated entries.
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. ;-)
True, the diffcult merges are likely to be a teething problem that mostly go away once your original translation files are synchronized with what Launchpad produces.
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.
That's pretty close to what we actually do.It's not really possible to say which translation is newer: if you upload a file with a change, the date the change was made is some unknown time between when you exported the original file from Launchpad and the time you re-uploaded the changed version. So in that case, if someone changed the translation inside Launchpad in the meantime, your message is accepted as a suggestion and you get a notification email about it.
If you have JavaScript enabled and are using a compatible browser (pretty much anything I've tried except IE), the warning will also show up as an info icon next to the upload's import-queue entry.
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?
The former.
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.
Do let us know! Your feedback so far has been very helpful. Jeroen
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)