Use of American/British English (was Re: request for string addition)

fre 2004-02-20 klockan 01.19 skrev Bastien Nocera:
> > ² I think "behavior" should be spelled without the "u" with American
> > English spelling, and Merriam-Webster seems to support that theory
> > ( And
> > source messages should use American English spellings according to the
> > GNU/GNOME standards.
> Urgh.
> Allow me to reply to the footnotes (once in a while, it's interesting).
> There's nothing in the GNU/GNOME standards (if such a thing exists)
> saying which language should be used as the base ("C") language for
> programs. While it's commonly accepted that it should be in English, so
> that translators can work from it, there is nothing saying which flavour
> of the English language should be used.
> I think that the help message above should be in American English,
> because the rest of the program is in American English (use of "Trash",
> etc.). The programs I write are all in British English as the "C"
> language, and it's going to change over my dead body.

I'm not arguing for use of American English for the fun(?) of it. Heck,
what I myself learned in school was the British variant. This is all so
*not* about personal preference. There are very basic and important
reasons for standardising on a single spelling in source messages and
source documentation.

1. Ambiguity in spellings is causing severe problems for translators.
Ambiguity, and many different spellings used, in the source messages
very much ruins any effort at automated translation re-use across
This is very much the reason why translators are advocating the use of
the terminology and spellings of the GNOME Word List provided by the
GDP, and it's also the reason for advocating the use of a single flavour
of English. In fact, the spelling differences between British and
American English usually are causing much more problems when they occur
in messages than any other terminology differences, since they are
relatively common in the terminology occuring in application user
interfaces ("colour"/"color", "customise"/"customize" etc.).

2. Fortunately, most developers and free software projects have long
since standardised on the use of a single flavour of English in source
messages and source documentation, and in the overwhelming majority of
cases it happens to be American English, for better or for worse. The
standardisation may be official or a defacto one, but it's still there,
and it helps translators every day.

3. Any other British spellings still can be, and are, provided by
translations. We've had a British/Commonwealth English team in the GTP
for a *very* long time, and just this week a Canadian English team
started aswell!

4. Fortunately, many developers and users recognise and accept all of
this. They recognise that this defacto standardisation on American
English in source messages is there, that there are technical benefits
of a standardisation, and are willing to leave their personal
preferences aside.

5. Still, some people always seem to take this more or less as a
personal attack on them and on their freedom whenever this topic is
discussed, usually leading to lots of heated debate, and so it very much
helps to make the defacto standardisation official in a project if it
isn't already, just to avoid lengthy heated and entirely unhelpful
discussions and misunderstandings.

On the other hand, a maintainer of course always has the final authority
of what he or she would like to do with his or her application, and what
language should be used in it. There's no question about that!

I'm merely just pointing out that if you want to make use of the
services of the GNOME Translation Project, you'd better at least try to
use American English spellings in the gettextisised program source
messages. Any occasions where this isn't so will likely be reported as
bugs, just the same as any other terminology problem or terminology
inconsistency issue.

And if you want your application to become part of the GNOME Desktop and
Developer Platform, any tendency to not wanting such bugs in the
application be resolved in an acceptable way is likely to influence the
opinions of the GTP on such an inclusion.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]