Michael B. Trausch wrote:
I am a member of the team. I don't remember if that was automatic, or if I had to explicitly add myself, but either way, I am:https://edge.launchpad.net/~alltray-developers/+members
As noted in the other thread, but so everyone sees it: this is indeed a bug. Fixing it isn't quite trivial, but there's an easy workaround. Edit the branch to make yourself the owner; then set it as the translations export branch; and then make the team the owner again.
The exports will continue despite the ownership change. I've updated the blog post to mention this workaround. It also links to the bug.
The output from that is already translated and will presumably be UTF-8 for all non-English locales, and in my case (using en_US.UTF-8) I wanted the output to also take advantage of Unicode. Why not? It looks better, and I am a perfectionist. ;-)
I definitely sympathize with that!You said that translation is to not just a language but an encoding as well. That throws in a whole new perspective for me. It's definitely true, but it's also a can of worms that scares me.
Our current handling of encodings is pretty simple: we import and export whatever encoding the file says it is in the header. Saying "en_US is UTF-8, so you can keep your msgids in ASCII" would be an exception to that.
So either en_US would have to be basically a language like any other; or we'd have to force UTF-8 everywhere (which would upset at least one well-known platform that's tragically tied to UTF-16); or we'd have to build a whole new mechanism for dealing with encoding. Which would probably have to give us a lot more than this use-case.
I think inevitably we'd end up with en_US being a language like any other. The risks I see to that are:
* Confusion. If people see en_US in their listings, with incomplete translations showing up in red, the sensible conclusion for them would be that they need to complete those translations for some reason. We'd have to have some kind of "it's okay to fall back on English" completion mechanism to counteract that, which we don't.
* "Text creep." This will be a temptation to correct mistakes in English by fixing the en_US translations instead of the msgid. Translators working in other languages would still see the old, uncorrected messages. Depending on how far it goes, we may end up with translators not being aware that a string has changed in some meaningful way. I do wish we supported English "translation" as a way to correct text, but again, that's not trivial and it's not a given that this would be the best solution for that problem.
* More people than today would be tempted to use non-English msgids if they saw that they could translate to en_US. But the UI doesn't support that, and the gettext format has evolved away from it by assuming that the source language has exactly a singular form and a plural form. We did look at supporting this style, but found that it's only worth it for formats that were consistently designed to work this way--and even then, conversion from/to gettext is often a better choice overall.
All of these would have a cost for the users, and for us developers. How great those costs would be is anyone's guess, but I feel before we could make a change like this, we'd at least have to find some inspired trick to avoid these problems very easily and effectively.
Jeroen
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)