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
_______________________________________________
Mailing list: https://launchpad.net/~launchpad-users
Post to : [email protected]
Unsubscribe : https://launchpad.net/~launchpad-users
More help : https://help.launchpad.net/ListHelp
