Re: Workflow between dev, UX and l10n teams

On 26/01/15 15:40, Jan Holesovsky wrote:
> But at some stage this will have to apply to the sources - and at that
> time, it will be even worse than now :-(  I'm afraid having en_US as a
> separate language will make the situation worse, not better.
Am I right in reading into this, that master is using American English?
And if so, why? Seeing as LibreOffice is, at heart, a European program
surely it should be using English?

Okay, maybe I'm being a little facetious here, but I do get very fed up
when people assume that "English" means American English, and not English.

Surely it would make a lot of sense to state that "Master uses
international English (ie any well-understood variant), and for local
consistency en_gb, en_us, en_au etc have to translate it".

What proportion of developers are native American speakers?

Bear in mind that most English variants use English spelling, not
American spelling. Most non-native speakers of English (even very good
speakers) "don't get" English tenses very well. Likewise, most
non-native speakers use odd grammar and word order - very comprehensible
but a dead giveaway that they are non-native.

At the end of the day, not enforcing en_us as a translation means that
the majority of us (including those of us that speak English rather than
American as our native language) are forced to suffer pain as the
foundations are messed up underneath us. And by allowing that *minority*
to avoid suffering, they are enabled to cause unnecessary pain without
even realising what they are doing!

The rule should be simple. Any changes of meaning can be edited directly
in master. If it's non-native English, and poor at that such as it's
hard to comprehend then it can be corrected in master. If it's clear
comprehensible English, whether English or Strine or American or
International or whatever, then it's off-limits for changes to master,
and has to be done in Pootle or whatever as a localisation.

Cheers,
Wol