Inglês GB ou inglês dos EUA?

Question

Se você possui uma API e é um desenvolvedor baseado no Reino Unido com um público altamente internacional, sua API deve ser

setColour()

ou

setColor()

(Tomemos uma palavra como um exemplo simples.)

Os engenheiros baseados no Reino Unido são muitas vezes bastante defensivos quanto à sua grafia “correta”, mas pode-se argumentar que a grafia dos EUA é mais “padrão” no mercado internacional.

Acho que a questão é: isso importa?Os desenvolvedores em outras localidades têm dificuldade com a ortografia do GB ou normalmente é bastante aparente o que as coisas significam?

Deveria ser tudo em inglês dos EUA?

Answer 1

Eu tenderia a usar os EUA-inglês, pois isso se tornou a norma em outras APIs. Falando como programador inglês, não tenho nenhum problema em usar "cor", por exemplo.

Answer 2

Eu não sou um falante nativo. Por escrito, sempre tento usar en-gb. No entanto, na programação eu sempre uso en-us Em vez de inglês britânico pela mesma razão que não uso alemão ou francês para meus identificadores.

Answer 3

Depende de onde você vê a maioria de seus clientes. Pessoalmente, prefiro usar o inglês-GB (por exemplo, cor) no meu código privado, mas vou colorir para aplicativos/API/código publicados externamente!

Answer 4

Geralmente eu seria um defensor da ortografia do GB, mas acho que o código é muito melhor se for consistente e eu acho:

Color lineColor = Color.Red;

Parecer muito melhor do que:

Color lineColour = Color.Red;

Eu acho que, em última análise, isso realmente não importa.

Answer 5

Mesmo sendo geralmente muito pedante sobre a ortografia correta, como desenvolvedor do Reino Unido, eu sempre iria com a ortografia da 'cor' americana. Em todas as linguagens de programação que encontrei, é assim, então, por uma questão de consistência, o uso de 'cor' faz muito sentido.

Answer 6

Supondo que esta seja uma API Java ou C#, provavelmente não importa, dada a difusão da funcionalidade de preenchimento automático nos IDEs.Se for para uma linguagem dinâmica ou onde IDEs modernos não são a norma, eu escolheria a grafia americana.É claro que sou americano e, portanto, obviamente tendencioso, mas parece que a maior parte do código que vejo de desenvolvedores que não são falantes nativos de inglês usa a grafia dos EUA para seus nomes de variáveis, etc.

Answer 7

Como programador inglês, eu uso o EN-US para o meu dev de software. O inglês americano domina tão bem em quase todas as outras API que é muito mais fácil manter um tipo de ortografia e remover a ambiguidade. É uma perda de tempo procurar um método apenas para descobrir que a ortografia está desativada por uma carta devido à ortografia.

Answer 8

Eu iria com os padrões atuais e escolheria a ortografia inglesa dos EUA. HTML e CSS são padrões reconhecidos com a ortografia "cor", em segundo lugar, se você estiver trabalhando com uma estrutura como .NET, é provável que você já tenha cores disponíveis em diferentes espaços de nomes.

O imposto mental sobre ter que lidar com duas grafias dificultaria, em vez de ajudar os desenvolvedores.

Label myLabel.color = setColour();

Answer 9

Tenho problemas com APIs que não estão no inglês-inglês. Só por causa das diferenças de ortografia. Eu sei o que as palavras significam, mas as diferentes ortografia me tentam.

A maioria das bibliotecas e estruturas com quem me familiariza usa as grafias dos EUA. Claro, eu sou americano, então ... US-inglesa é minha língua nativa.

Answer 10

A maioria da documentação de desenvolvimento (assim como o MSDN) está no inglês americano.

Portanto, pode ser melhor ficar com o fluxo principal e usar o inglês americano em sua API se você estiver segmentando o público internacional.

Answer 11

Recebi outra amostra: serialize e serialize. :)

Pessoalmente, acho que não importa muito. Eu trabalhei em projetos que usavam países de ortografia do Reino Unido-inglês e eles usam a ortografia do Reino Unido. Ainda é inglês e realmente não importa muito devido ao Intellisense.

Answer 12

As a Canadian, I run into this all the time. It's very difficult for me to type "color" as my muscle memory keeps reaching for the 'u'.

However, I tend to adopt the language of the libraries. Java has the Color class, so I use color.

Answer 13

I try to find alternative words if possible. I will let -ize slide. For Colour I could possibly use Hue, Ink, Foreground/Background...

If not, as an Englishman, I will use en-GB because I have some pride left in my country and origins.

If it was to be part of a bigger project however, especially an international one, I would keep the entire project consistent above having a small part be in one language variation and the rest in another.

Answer 14

I'm also going to have to side with US-English, simply to keep things consistent (as others have already noted here). Although I am a native US-English speaker, I have done software projects with both German and Swedish software companies, and in both cases the temptation occasionally would strike my teammates to use German or Swedish text in the code -- usually for comments, but sometimes also for variable or method names. Even though I can speak those languages, it's really jarring on the eyes and makes it harder to bring a new non-speaker into the project.

Most European software companies (at least the ones I've worked with) behave the same way -- the code stays in English, simply because that makes the code more international-friendly should another programmer come on board. The internal documentation usually tends to be done in the native language, though.

That said, the distinction here is about two different dialects of English, which isn't quite as extreme as seeing two totally different languages in the same source code file. So I would say, keep the API in US-English, but your comments in GB-English if it suits you better.

Answer 15

I'd say look at how other libraries in your language choose and follow their convention.

The designers of the programming language and its built-in APIs made a choice, and whether the users are international or not they are used to seeing spellings consistent with this choice. You are not targeting speakers of a different language but users of a programming language. Odds are they've learned quite a few words in the foreign language from the built-in APIs, and they might not be aware there's differences between US English and GB English. Don't confuse them by switching sides of the pond.

I use .NET languages primarily, and the .NET Framework uses US English spellings. On this platform, I'd stick with US English. I'm not aware of any languages standardized on GB English, but if yours has done so then by all means stay consistent with the language.

Answer 16

I agree with the "go for American" troupe. I myself prefer en-GB when writing e-mails and such, but American English is pretty much the standard in all programming circles.

Answer 17

Even though British English is what is spoken throughout the world - I recommend using American English which like other people have said dominate the market.

Answer 18

Definitely US english.

Answer 19

First, I'm in the US. In my current project, it's always "color" however, the word we can't seem to pick a spelling for is "grey" vs "gray".

It's actually gotten quite annoying.

Answer 20

I'm one of these people who's heart rate and blood pressure rises each time I'm forced to use American English in setup files, etc, due to the fact that the software doesn't give the option for British English, but that's just me :)

My personal opinion on this one however would be to provide both spellings, give them setColor() and setColour(), write up the code in one of them, and just have the second one pass the parameters through.

This way you keep both groups happy, granted your intellisense gets a bit longer, but at least people can't complain about you using the 'wrong' language.

Answer 21

Selection of language for identifier names has nothing to do with audience and everything to do with the original language in which the framework or API was developed.

I don't know very many languages but I cannot think of a single one that uses anything other than US English.

The dangers of introducing subtle bugs due to different spellings are too great IMHO.

A function override can easily become an pseudo-overload.

A config file could become invalid due to difference in spellings.

A situation might arise where the same conceptual object has been defined using multiple classes, using both en-US and en-GB.

So therefore, whether a piece of code is purely for internal use or intended for external use as well, the spellings used must always match the original language of the platform/framework/compiler/API.

Answer 22

If all of your programmers are British, use en-gb. If your code will be seen by programmers outside of Britain, then en-us would be a better choice.

One minor point, we rely on a translation service to copy our documentation in to other languages. We have found we get better translations when using en-us as the source.

Answer 23

You need to consider your audience. Who is going to use the code and what are they expecting to see?

I work in a company that has offices in both Canada & US. We use Canadian spelling (very similar to British English) when producing documentation and code in Canada and US spelling for what is used in the US.

Some things cross borders, but the difference in spelling is rarely an issue. It acutally can generate some interesting dialogue when American's are not aware of different spellings for Candian and British English. Sometimes they are OK with it, othertimes they insist on it changing to the "correct" spelling. This also affects date formats (dd/mm/yyyy in Canada and mm/dd/yyyy in US)

When there is an impasse, we typically go with the US spelling since the people in Canada are familiar with both variations.

Answer 24

The main reason I've heard for choosing US over UK English is because the UK audience, when confronted with US spelling, realise it's a US application (or presume it is so), whereas a US audience confronted with UK spelling thinks '... hey, that's wrong.. it's color not colour'

But like others have said, standardise. Pick on and stick with it.

Answer 25

It comes naturally for me to work in UK English without even thinking about it. However, if you are developing internal procedures it doesn't really matter. If you are creating APIs that will be used publicly, and your audience is international, why not implement both?

Answer 26

I prefer US English.

Answer 27

If you look back a few hundred years, you will find the change has nothing at all to do with the US, much as many would think so. The changes stem from European influences, particularly the French. Before that time, the English word "colour" was then actually spelt "color".

To try to standardise would be futile as half of Chinese children are learning the pre European influence and US understanding of English, while the other half are taking it up as it stands today, as the English language.

If you think language is a problem, then you should consider the Taiwan Kg which weighs in at 600g. I've yet to find out how they managed that one, but I hope they are never employed as aircraft fuelling personnel!

Answer 28

I always use en-GB for all my programming. I guess it's due to a heavy influence of British novels.

However, might it not be possible to have two different sets of APIs (one for en-US, one for en-GB) which internally call the same function? This might bloat the header files though, so maybe depending upon a preprocessor definition, a conditional compilation? If you're using C++, you could do something like below...

#ifdef ENGB
     typedef struct Colour
     {
      //blahblahblah
     };
     void SetColour(Colour c);
#else
    typedef struct Color
    {
      //blahblahblah
    };
    void SetColor(Color c);
#endif

Depending upon whether the client programmer defines ENGB or not as below

#define ENGB

he could use the APIs in the culture that he prefers. Maybe overkill for such a trivial purpose, but hey, if it seems important, why not! :)