¿Inglés británico o inglés estadounidense?

93

Si tiene una API y es un desarrollador con sede en el Reino Unido con una audiencia muy internacional, si su API es

setColour()

o

setColor()

(Para tomar una palabra como ejemplo simple).

Los ingenieros del Reino Unido suelen estar bastante a la defensiva acerca de su ortografía "correcta", pero se podría argumentar que la ortografía estadounidense es más "estándar" en el mercado internacional.

Supongo que la pregunta es ¿importa? ¿Los desarrolladores de otras regiones tienen problemas con la ortografía de GB, o normalmente es bastante evidente lo que significan las cosas?

¿Debería ser todo en inglés estadounidense?

izb
fuente
1
incluirlos a ambos. no te va a hacer daño.
Amarghosh
Nuestro sistema educativo siempre enseña en-gb, por lo que estoy acostumbrado a escribir en-gb en código. (A veces era perezoso e insertaba algún identificador chino cuando desarrollaba un código específico de cliente chino, y esos se cambiaron al inglés más tarde)
Michael Tsang

Respuestas:

77

Yo tendería a usar el inglés estadounidense, ya que se ha convertido en la norma en otras API. Hablando como programador de inglés, no tengo ningún problema en usar "color", por ejemplo.

Chris
fuente
6
La estandarización es un buen objetivo, y su API será aceptada más fácilmente por la multitud internacional que si usa la versión GB.
Maitus
54

No soy un hablante nativo. Por escrito, siempre trato de usar en-gb. Sin embargo, en programación siempre uso en en-uslugar del inglés británico por la misma razón por la que no uso alemán o francés para mis identificadores.

Konrad Rudolph
fuente
15

Depende de dónde veas a la mayoría de tus clientes. Personalmente, prefiero usar English-GB (por ejemplo, Color) en mi código privado, ¡pero voy a Color para aplicaciones / API / código publicados externamente!


fuente
7
El uso de GB internamente y EE. UU. Externamente corre el riesgo de una colisión de variable semántica, similar al tipo de cosas que sucede con "color" y "co1or". Su cerebro procesa la palabra, no la ortografía y puede generar confusión
Chris Cudmore
1
Yo tendería a hacer lo mismo, pero teniendo cuidado con lo que menciona Chris: si usa una ortografía en la API, probablemente debería usar la misma en otra parte del proyecto.
Mark Baker
15

En general, sería un riguroso con la ortografía de GB, pero creo que el código se lee mucho mejor si es consistente y encuentro:

Color lineColor = Color.Red;

verse mucho mejor que:

Color lineColour = Color.Red;

Supongo que, en última instancia, realmente no importa.

Carl
fuente
8
Es incluso peor si tiene una propiedad pública Color Color {get;}
Benjol
10

Aunque por lo general soy muy pedante con la ortografía correcta, como desarrollador del Reino Unido siempre me decantaría por la ortografía de "color" estadounidense. En todos los lenguajes de programación que he encontrado, es así, por lo que en aras de la coherencia, usar 'color' tiene mucho sentido.

Philip Morton
fuente
5

Suponiendo que se trata de una API de Java o C #, probablemente no importe dada la omnipresencia de la funcionalidad de autocompletar en los IDE. Si se trata de un lenguaje dinámico o uno en el que los IDE modernos no son la norma, optaría por la ortografía estadounidense. Por supuesto, soy estadounidense y, por lo tanto, obviamente soy parcial, pero parece que la mayoría del código que veo de los desarrolladores que no son hablantes nativos de inglés usan la ortografía estadounidense para sus nombres de variables, etc.

Mike Deck
fuente
3
Las pautas de diseño de .NET Framework recomiendan el inglés de EE. UU. En aras de la coherencia
Mark Cidade
@MarkCidade: ¿Tiene un enlace a la recomendación mencionada? Lo busqué de arriba abajo sin éxito.
Dio F
1
@DioF Se menciona en el libro "Pautas de diseño de marcos: convenciones, modismos y patrones para bibliotecas .NET reutilizables" por Krzysztof Cwalina y Brad Abrams
Mark Cidade
5

Como programador en inglés, uso en-US para mi desarrollo de software. El inglés americano domina tan bien en casi todas las demás API que es mucho más fácil ceñirse a un tipo de ortografía y eliminar la ambigüedad. Es una pérdida de tiempo buscar un método solo para encontrar que la ortografía está desviada por una letra debido a la localización de la ortografía.

Ross Anderson
fuente
4

Seguiría los estándares actuales y elegiría la ortografía del inglés estadounidense. HTML y CSS son estándares reconocidos con la ortografía "color", en segundo lugar, si está trabajando con un marco como .NET, es probable que ya tenga colores disponibles en diferentes espacios de nombres.

El impuesto mental sobre tener que lidiar con dos ortografías obstaculizaría en lugar de ayudar a los desarrolladores.

Label myLabel.color = setColour();
Mauro
fuente
3

Tengo problemas con las API que no están en inglés de EE. UU. Solo por las diferencias ortográficas. Sé lo que significan las palabras, pero la diferente ortografía me hace tropezar.

La mayoría de las bibliotecas y marcos con los que estoy familiarizado usan la ortografía estadounidense. Por supuesto, soy estadounidense, así que ... el inglés estadounidense es mi lengua materna.

epochwolf
fuente
3

La mayor parte de la documentación de desarrollo (al igual que MSDN) está en inglés americano.

Por lo tanto, podría ser mejor quedarse con la corriente principal y usar el inglés americano en su API si se dirige a una audiencia internacional.

Rinat Abdullin
fuente
2

Tengo otra muestra: serializar y serializar. :)

Personalmente, no creo que importe mucho. He trabajado en proyectos que usaban países de ortografía del Reino Unido-Inglés y usan la ortografía del Reino Unido. Todavía es inglés y realmente no importa mucho debido a Intellisense.

jop
fuente
Estoy seguro de que mi profesor de inglés me dijo que las terminaciones de tamaño eran válidas en inglés británico. Tanto las terminaciones ise como ize son aceptables en inglés británico, por lo que las mías se adaptan a las septicas. ( cockneyrhymingslang.co.uk/slang/sceptic_tank )
Scott Langham
2

Como canadiense, me encuentro con esto todo el tiempo. Es muy difícil para mí escribir "color" ya que mi memoria muscular sigue buscando la 'u'.

Sin embargo, tiendo a adoptar el lenguaje de las bibliotecas. Java tiene la clase Color, así que uso color.

Chris Cudmore
fuente
1
"c", "o", "l", Ctrl + Espacio, "."
Tom
1

Intento encontrar palabras alternativas si es posible. Dejaré que se deslice. Para el color, posiblemente podría usar tono, tinta, primer plano / fondo ...

Si no, como inglés, usaré en-GB porque me queda algo de orgullo en mi país y orígenes.

Sin embargo, si fuera parte de un proyecto más grande, especialmente uno internacional, mantendría todo el proyecto consistente antes de tener una pequeña parte en una variación de idioma y el resto en otra.

JeeBee
fuente
2
No estoy de acuerdo con el uso de primer plano / fondo en lugar de color / o color). fore / background también podría significar patrón, por ejemplo. Si desea establecer / obtener un colo (u) r, así es como debe llamarlo. La 'u' faltante / adicional es menos confusa que una propiedad mal nombrada.
Treb
Eso es un detalle en el ejemplo, no en el principio, pero lo suficientemente justo.
JeeBee
2
Por cierto. la ortografía -ize no es un americanismo!
Jules
@Jules sí, lo es.
igorcadelima
@igorcadelima Puede ser británico de uso común, pero considere: en.wikipedia.org/wiki/Oxford_spelling
Jules
1

También tendré que ponerme del lado del inglés estadounidense, simplemente para mantener las cosas consistentes (como otros ya han señalado aquí). Aunque soy un hablante nativo de inglés estadounidense, he realizado proyectos de software con empresas de software tanto alemanas como suecas, y en ambos casos, mis compañeros de equipo ocasionalmente tenían la tentación de usar texto en alemán o sueco en el código, generalmente para comentarios, pero a veces también para nombres de variables o métodos. Aunque puedo hablar esos idiomas, es realmente discordante para los ojos y hace que sea más difícil incorporar a un nuevo no hablante al proyecto.

La mayoría de las empresas de software europeas (al menos con las que he trabajado) se comportan de la misma manera: el código permanece en inglés, simplemente porque eso hace que el código sea más compatible con el mundo internacional en caso de que se incorpore otro programador. Sin embargo, la documentación interna suele estar redactada en el idioma nativo.

Dicho esto, la distinción aquí se trata de dos dialectos diferentes del inglés, que no es tan extremo como ver dos idiomas totalmente diferentes en el mismo archivo de código fuente. Entonces yo diría, mantenga la API en inglés de EE. UU., Pero sus comentarios en inglés de GB si le conviene más.

Nik Reiman
fuente
1

Yo diría que mire cómo otras bibliotecas en su idioma eligen y siguen su convención.

Los diseñadores del lenguaje de programación y sus API integradas tomaron una decisión, y ya sea que los usuarios sean internacionales o no, están acostumbrados a ver ortografías consistentes con esta elección. No se dirige a hablantes de un idioma diferente, sino a usuarios de un lenguaje de programación. Lo más probable es que hayan aprendido bastantes palabras en el idioma extranjero de las API integradas, y es posible que no sepan que hay diferencias entre el inglés de EE. UU. Y el inglés de GB. No los confunda cambiando de lado del estanque.

Utilizo principalmente los lenguajes .NET y .NET Framework utiliza la ortografía del inglés estadounidense. En esta plataforma, me quedaría con el inglés estadounidense. No conozco ningún idioma estandarizado en inglés de GB, pero si el tuyo lo ha hecho, entonces mantente coherente con el idioma.

OwenP
fuente
1

Estoy de acuerdo con la compañía "Go for American". Yo mismo prefiero en-GB cuando escribo correos electrónicos y cosas así, pero el inglés americano es prácticamente el estándar en todos los círculos de programación.

dguaraglia
fuente
1

A pesar de que el inglés británico es lo que se habla en todo el mundo, recomiendo usar inglés americano que, como han dicho otras personas, domina el mercado.

user24199
fuente
1

Definitivamente inglés estadounidense.

Shiva
fuente
1

Primero, estoy en Estados Unidos. En mi proyecto actual, siempre es "color", sin embargo, la palabra que parece que no podemos elegir una ortografía es "gris" vs "gris".

De hecho, se ha vuelto bastante molesto.

Brian Postow
fuente
1

La selección del idioma para los nombres de los identificadores no tiene nada que ver con la audiencia y todo que ver con el idioma original en el que se desarrolló el marco o API.

No sé muchos idiomas, pero no puedo pensar en uno solo que use otro idioma que no sea el inglés de EE. UU.

En mi humilde opinión, los peligros de introducir errores sutiles debido a diferentes ortografías son demasiado grandes.

Una anulación de función puede convertirse fácilmente en una pseudosobrecarga.

Un archivo de configuración podría dejar de ser válido debido a la diferencia de ortografía.

Puede surgir una situación en la que se haya definido el mismo objeto conceptual utilizando varias clases, utilizando tanto en-US como en-GB.

Por lo tanto, ya sea que un fragmento de código sea puramente para uso interno o también para uso externo, la ortografía utilizada siempre debe coincidir con el idioma original de la plataforma / marco / compilador / API.

Umar Farooq Khawaja
fuente
Solo me importa la consistencia dentro de nuestra API. Por ejemplo, si nuestro paquete está dirigido al Reino Unido, solo se puede usar en-gb, absolutamente ninguna ortografía como "color".
Michael Tsang
Supongo que también escribes tus propias bibliotecas de clases base, Michael.
Umar Farooq Khawaja
0

Si todos sus programadores son británicos, utilice en-gb. Si su código será visto por programadores fuera de Gran Bretaña, entonces en-us sería una mejor opción.

Un punto menor, confiamos en un servicio de traducción para copiar nuestra documentación a otros idiomas. Hemos descubierto que obtenemos mejores traducciones cuando usamos en-us como fuente.

Jim C
fuente
0

Debes considerar a tu audiencia. ¿Quién va a usar el código y qué esperan ver?

Trabajo en una empresa que tiene oficinas en Canadá y Estados Unidos. Usamos la ortografía canadiense (muy similar a la del inglés británico) cuando producimos documentación y código en Canadá y ortografía estadounidense para lo que se usa en los EE. UU.

Algunas cosas cruzan las fronteras, pero la diferencia de ortografía rara vez es un problema. En realidad, puede generar un diálogo interesante cuando los estadounidenses no son conscientes de las diferentes grafías del inglés canadiense y británico. A veces están de acuerdo con eso, otras veces insisten en que se cambie a la ortografía "correcta". Esto también afecta a los formatos de fecha (dd / mm / aaaa en Canadá y mm / dd / aaaa en EE. UU.)

Cuando hay un callejón sin salida, normalmente optamos por la ortografía estadounidense, ya que la gente de Canadá está familiarizada con ambas variaciones.


fuente
0

La razón principal que he escuchado para elegir el inglés de EE. UU. En lugar del inglés del Reino Unido es porque la audiencia del Reino Unido, cuando se enfrenta a la ortografía de EE. UU., Se da cuenta de que es una aplicación de EE. UU. (O presume que es así), mientras que una audiencia de EE. .oye, eso está mal ... es color, no color '

Pero como han dicho otros, estandarice. Sigue y quédate con eso.


fuente
0

Para mí es natural trabajar en inglés británico sin ni siquiera pensar en ello. Sin embargo, si está desarrollando procedimientos internos, realmente no importa. Si está creando API que se utilizarán públicamente y su audiencia es internacional, ¿por qué no implementar ambas?

BlackWasp
fuente
0

Prefiero el inglés de EE. UU.

vaske
fuente
0

Soy una de estas personas cuya frecuencia cardíaca y presión arterial aumentan cada vez que me veo obligado a utilizar el inglés americano en archivos de configuración, etc., debido al hecho de que el software no ofrece la opción de inglés británico, pero eso es solo yo :)

Mi opinión personal sobre este, sin embargo, sería proporcionar ambas ortografías, darles setColor () y setColour (), escribir el código en uno de ellos y hacer que el segundo pase los parámetros.

De esta manera, mantienes felices a ambos grupos, dado que tu intellisense se alarga un poco, pero al menos la gente no puede quejarse de que usas el lenguaje "incorrecto".

Jimoc
fuente
7
No es buena idea. La API estaría llena de métodos redundantes.
McDowell
6
Esa es una solución realmente pobre. Probablemente confundirá a mucha gente, que está tratando de averiguar la diferencia entre setColour y setColor. Además, puede crear mucho desorden en una API si tiene muchos métodos con la palabra color en ellos.
Kibbee
Mis pensamientos exactamente. No le cuesta nada proporcionar ambas ortografías y simplemente documentarlas como idénticas. En cuanto a la objeción de la redundancia, la usabilidad triunfa sobre la ortogonalidad.
Dave Sherohman
0

Si miras hacia atrás unos cientos de años, encontrarás que el cambio no tiene nada que ver con Estados Unidos, por mucho que muchos lo piensen. Los cambios provienen de influencias europeas, particularmente las francesas. Antes de ese momento, la palabra inglesa "color" se deletreaba "color".

Tratar de estandarizar sería inútil, ya que la mitad de los niños chinos están aprendiendo la influencia preeuropea y la comprensión estadounidense del inglés, mientras que la otra mitad lo está adoptando tal como está hoy, como el idioma inglés.

Si cree que el idioma es un problema, debería considerar el kilo de Taiwán, que pesa 600 g. Todavía tengo que averiguar cómo lo lograron, ¡pero espero que nunca sean empleados como personal de abastecimiento de combustible de aviones!

Steve Keenan
fuente
0

Siempre uso en-GB para toda mi programación. Supongo que se debe a la fuerte influencia de las novelas británicas.

Sin embargo, ¿no sería posible tener dos conjuntos diferentes de API (uno para en-US, otro para en-GB) que llamen internamente a la misma función? Sin embargo, esto podría inflar los archivos de encabezado, así que tal vez dependiendo de la definición de un preprocesador, ¿una compilación condicional? Si está usando C ++, podría hacer algo como a continuación ...

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

Dependiendo de si el programador del cliente define ENGB o no como se muestra a continuación

#define ENGB

podría usar las API en la cultura que prefiera. Quizás exagerar para un propósito tan trivial, pero bueno, si parece importante, ¡por qué no! :)

Bharat Mallapur
fuente
2
Es mejor seguir la ortografía de EE. UU., Ya que casi todas las API estándar la siguen. Los compiladores requieren estrictamente la ortografía exacta, por lo que es una mala idea ofrecer dos API diferentes para dos configuraciones regionales. La documentación podría adaptarse a dos configuraciones regionales diferentes, pero la API debe ser coherente. En general, se espera que incluso si se usa la misma API en diferentes regiones que hablan diferentes idiomas como alemán, francés, español, etc., aunque la documentación puede proporcionar explicaciones en los idiomas locales, los métodos, las variables, etc., seguirán el idioma original de la API. (lo más probable es que en EE.UU.).
ADTC