Make it easy to add En (US) to the list of languages

David explained it well. And now I know why we saw one or two oopses from Michael trying to get to en_US pages!

There are several use-cases for en/en_US as translation languages:
 * Fixing mistakes in the English (i.e, this use-case).
 * Using symbolic msgids instead of English. We don't like that, but do support it "under the hood" for certain formats.
 * Using languages other than English for msgids. We don't like that at all.
 * Offering a choice of ASCII-only (for ssh and such) and super-ASCII UIs (for GUIs) in the same library or component.

But we obviously want to:
 * Minimize pollution in the database of translatable English strings that powers the suggestions system.
 * Avoid mixing strings of wildly different types and reasons in what to the database is the same language.
 * Make any exceptions to our usual way of working clear and explicit.

Now as it happens, we're rolling out variants support tomorrow. It may make sense to use that. We could have an en_US@correction or whatever for this use-case. Not something you'd want as a locale on the end-user's system, but something you could give special treatment in building language packs etc.

And to add a bit more to this. This sounds like a long term problem, meaning that these strings will only ever be fixed as "translations", and they'll never enter our "original strings" database. So, for instance, if software-centre has a separate DB of these descriptions, but includes corrected forms, they'll never be matched and Launchpad won't be able to show appropriate translations from the other package.

So, while it is a short-term hack that may get you moving, I'd strongly suggest that you consider it a hack and look for other options. We'll soon be able to open-up variants for whatever you need, but for reasons mentioned above, I'd rather not.

Of course, if that's what you see as the only viable solution, we can sure do it.

(We actually need more information to be able to proceed — variants support is there now)

Well , i dont really understand what the question is..

What is required is for us to make changes to debian descriptions without actually touching the debian packages.
ie: make changes to the en_US [which is currently not in the list of languages]

This would be a short-term hack, but there is a blueprint : https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-user-contributed-metadata-for-software-center
and User-contributed metadata is in the roadmap for lp: https://dev.launchpad.net/RoadMap

But those are not likely to happen any time soon. afaik , there has been no work started yet, related to this.

Ok, so what I am saying is this:
 1. we won't add "en_US" to the list of languages as long as our policy mandates original strings to be en_US: having it will be very confusing for everybody else using Launchpad
 2. we _can_ add "en@something" (i.e. "en@fixes") which would clearly communicate intent

For 2, you'd have to post-process resulting PO files from Launchpad (either a simple rename to what you want them to be, or whatever else you want).

Note that even using "en_US" Debian descriptions will not be improved/fixed for those using C locale. And translators will see original descriptions instead (thus, they might be translating bad strings).

I strongly believe this should not be the approach to take, but if this is blocking some very important work, I'd be happy to have us create en@fixes language just for fixing English strings. The question is, do you want that?

mvo is on vacation this week , so we have to wait for him to return.
He can probably let us know which would be more feasible for us to do.

This question was expired because it remained in the 'Needs information' state without activity for the last 15 days.