[gnome-love] Re: GNOME Lovers Needed: l10n work for locations database



Alan Horkan wrote:
On Mon, 13 Dec 2004, Adam Weinberger wrote:


David Lodge wrote:

Quoting Danilo Å egan <danilo gnome org>:


I don't think we have a policy of using American English in the msgid.
We discussed this before, and I proposed to have a more thorough
discussion at the Guadec meeting in Krisiansand, but there was no
meeting on this in Kristiansand. Maybe next time. My suggestion is that
we continue to use English English, as it is more used around the world.
and needs less modifications when going from one version of English to
another.

So, it is recommended for at least documentation.

OTOH, we already have all the code in U.S. English, and we have en_GB
team (and no en_US team).


Switching now to British English is going to cause many problems for
other translators as well.


I fully agree with Danilo - even though I don't like American English (being
British ;-) - I realise that the majority of GNOME developers and users either
speak or have been taught American English. With my own correspondance with
NNES I have noted that, for Europe at least, American spelling and grammar is
taught in preference to British and with the homogenity of American documents
this is probably the safer option.

As the en_GB teams does exist (though it seems to just be me at the moment!) I
see nothing wrong with stating that all strings should be follow American
grammar and spelling.

I have actually raised bugs where spellings have been mixed (mainly on
gnumeric).

dave

FWIW, as the maintainer of the Canadian English (en_CA) translations, I
agree. People expect that if they don't request anything specific,
they'll get American English spellings. This is a nearly universal truth
across software projects, it seems, and more to do with convention than
with a recognition of what the majority of the world sees as native
spelling and grammar. Switching to en_GB as the default would make us
the odd project out, and would serve to confuse more people than it
would benefit.


I always accepted the C locale as being equal to en_US, but I failed and
still fail to understand why if en_IE or en_AU is unavailable I do not
fall back to "en" and for "en" to be equal to en_GB which is still
considered to be standard English is it not?

The worst part is when translators choose to use words like
Favourites/Favorites rather than simpler more sensible words like
Bookmarks which do not require localisation.  (I started a translation
once because I was sick of seeing an almost useless error message which
read "bogus document".  Anytime I hear "bogus" or "awesome" I cannot help
thinking it should be followed by "dude!")

Ideally translators should use standard grammar common to both if at
all possible.

Do you mean translators or developers?

I will fix spelling errors, grammar errors, and situations where the source string is confusing or unclear. But as a translator, it's my job to /translate/ messages, not redesign the UI. If the authors meant "bookmark," they'd have written "bookmark." My job is to make the UI look natural to Canadians, not give better word choice. Even in apps like gimp-gap where about 25% of the words in the source strings are misspellings, poor word choices, or made-up words.

The notion of "standard English" is irrelevant: again, we're not going off of logic here, we're going off of convention. Our users expect that if they don't specify any particular language, they'll get American English spellings. That is how every other app/project does things too. I don't believe that it's up to us to redecide that, even if, (and I fully agree here), en_GB is what the majority of the world would rather see.

To fall back on an old stereotype, put it this way: don't ask too much of Americans ;;) [BTW, I'm an American, but I'm in Canada pretending to be Canadian]

# Adam


--
Adam Weinberger
adamw magnesium net || adamw FreeBSD org
adamw vectors cx    ||   adamw gnome org
http://www.vectors.cx



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