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

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?

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.

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.

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!

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.

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.

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.

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.

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();

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.

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.

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.

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.

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.

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.

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.

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.

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.

Definitivamente inglés estadounidense.

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.

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.

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.

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.

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.

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?

Prefiero el inglés de EE. UU.

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".

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!

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! :)