[Design] Proposal: have an en-US localization egg

[Philippe Bossut]

Hi,

A small issue yesterday with my French localized egg made me re-think 
about something and I'd like to make the following proposal.

- Proposal:
--------------
I'd like Chandler to allow the use of a translation egg for English 
(yes, American English aka en-US). The string in the code would be the 
default "geek speak English", usable but could differ from the final 
reference. The proper English strings would be delivered via the message 
factory.

- Rationale:
---------------
2 issues prompted me to think about this.

- Issue1: Minute changes in strings in the code end up breaking all 
localized eggs
e.g. Changing "Today" in "Today's events" last week broke my French 
translation and since "Aujourd'hui" is already longish, I'm not planning 
to change this to anything else. It's a minor pain today but imagine 
breaking 87 localized languages with a last minute change like that... 
painful...

- Issue2: Some strings are identical in English but different in other 
languages.
e.g. "to" in the DV is used twice but would actually need 2 different 
strings in French because of the different contexts. Allowing the code 
to add context and have "to(in)" for interval time and "to(date)" for 
final date would allow me to have "au" and "jusqu'au" separately. Bryan 
Stearns shown me another way of doing this though I just can't remember 
what the trick was.
(Note that allowing dupes in the po and have 2 or more entries for "to" 
wouldn't help me much since I would lack the context to understand which 
"to" is what...)

- Nice side effects:
-----------------------
Beyond not breaking localized eggs, this will allow easy fix of typos 
and allow non devs to polish the UI wording without interfering with the 
work of localizers.

One *very* nice side effect for localizers and PPD alike is that changes 
to the "Welcome" message will be possible till the last minute without 
impossible to achieve synchronization between people scattered around 
the planet. Actually, we could (should) even suppress this lengthy 
message entirely from the .py, replace it in there by _(u"Here goes the 
long welcome message") and have this message live only in the en-US po, 
making possible for Pieter and al, to fiddle with it till the last darn 
second without interfering with the main svn tree.

- Consequences on the code:
------------------------------------
As far as I can tell, none. We can continue to code as today, we just 
need to make sure that a en-US egg will be loaded and used if we have 
one. We also need to log typo bugs and others against the en-US .po egg 
maintainer and not the code owner (so that we indeed don't break the 
other localization...).

Thoughts?

- Philippe