api - traduccion - GB inglés o inglés de EE. UU.
name tag traducir a español (28)
A pesar de que el inglés británico es lo que se habla en todo el mundo, recomiendo usar el inglés americano que, como otras personas, han dicho que domina el mercado.
Si tiene una API y es un desarrollador con sede en el Reino Unido con una audiencia internacional, su API debería ser
setColour()
o
setColor()
(Para tomar una palabra como un simple ejemplo)
Los ingenieros basados en el Reino Unido a menudo son bastante defensivos con respecto a su ortografía "correcta", pero podría argumentarse que la ortografía estadounidense es más "estándar" en el mercado internacional.
Supongo que la pregunta es ¿Importa? ¿Los desarrolladores de otros lugares luchan con la ortografía de GB, o es normalmente bastante aparente lo que significan las cosas?
¿Debería ser todo inglés-estadounidense?
A pesar de que generalmente soy muy pedante sobre la ortografía correcta, como desarrollador del Reino Unido, siempre elegiría la ortografía estadounidense del ''color''. En todos los lenguajes de programación que he encontrado, es así, así que, por coherencia, usar ''color'' tiene mucho sentido.
Como canadiense, me encuentro con esto todo el tiempo. Es muy difícil para mí escribir "color" porque 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.
Como programador de inglés, uso en-US para mi desarrollador de software. El inglés estadounidense domina tan bien en casi todas las demás API que es mucho más fácil apegarse a un tipo de ortografía y eliminar la ambigüedad. Es una pérdida de tiempo buscar un método solo para descubrir que la ortografía está desactivada por una letra debido a la localización ortográfica.
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 al inglés británico) cuando producimos documentación y el código en Canadá y la ortografía de los Estados Unidos para lo que se usa en los EE. UU.
Algunas cosas cruzan fronteras, pero la diferencia en la ortografía rara vez es un problema. En realidad, puede generar un diálogo interesante cuando los estadounidenses no tienen conocimiento de la ortografía diferente para Candian y el inglés británico. A veces están de acuerdo con eso, otras veces insisten en que cambie a la ortografía "correcta". Esto también afecta los formatos de fecha (dd / mm / aaaa en Canadá y mm / dd / aaaa en EE. UU.)
Cuando hay un callejón sin salida, generalmente vamos con la ortografía de los Estados Unidos ya que las personas en Canadá están familiarizadas con ambas variaciones.
Definitivamente inglés de los Estados Unidos.
Depende de donde vea a la mayoría de sus 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, yo sería un fiel para la ortografía de GB, pero creo que el código lee mucho mejor si es consistente y encuentro:
Color lineColor = Color.Red;
para verse mucho mejor que:
Color lineColour = Color.Red;
Supongo que finalmente no importa.
Estoy de acuerdo con la troupe "ir a América". Yo mismo prefiero en-GB al escribir correos electrónicos y cosas por el estilo, pero el inglés americano es prácticamente el estándar en todos los círculos de programación.
Intento encontrar palabras alternativas si es posible. Dejaré -ize deslizar. Para Color, posiblemente podría usar Hue, Ink, Foreground / Background ...
Si no, como inglés, usaré en-GB porque me queda un poco de orgullo en mi país y mis orígenes.
Sin embargo, si fuera parte de un proyecto más grande, especialmente uno internacional, mantendría constante todo el proyecto, teniendo una pequeña parte en una variación de idioma y el resto en otra.
La mayoría de la documentación de desarrollo (al igual que MSDN) está en inglés americano.
Por lo tanto, es mejor que se quede con la corriente principal y use el inglés americano en su API si se dirige a público internacional.
La razón principal que escuché para elegir el inglés de los EE. UU. Es que la audiencia del Reino Unido, al ser confrontada con la ortografía estadounidense, se da cuenta de que es una aplicación estadounidense (o presume que es así), mientras que un público estadounidense confrontado con la ortografía del Reino Unido piensa ... hey, eso está mal ... es color, no color
Pero como han dicho otros, estandarizar. Elija y quédese con él.
La selección del idioma para los nombres de los identificadores no tiene nada que ver con la audiencia y todo tiene que ver con el idioma original en el que se desarrolló el marco o la API.
No conozco muchos idiomas, pero no puedo pensar en uno solo que use algo más que el inglés estadounidense.
Los peligros de introducir errores sutiles debido a diferentes deletreos son demasiado grandes en mi humilde opinión.
Una anulación de función puede convertirse fácilmente en una pseudo-sobrecarga.
Un archivo de configuración podría dejar de ser válido debido a la diferencia en la ortografía.
Podría surgir una situación en la que el mismo objeto conceptual se haya definido utilizando múltiples clases, utilizando tanto en-US como en-GB.
Por lo tanto, si una parte del código es puramente para uso interno o para uso externo también, la ortografía utilizada siempre debe coincidir con el idioma original de la plataforma / framework / compilador / API.
Me gustaría ir con los estándares actuales y escoger la ortografía del inglés de EE. UU. HTML y CSS son estándares reconocidos con el "color" de ortografía; en segundo lugar, si está trabajando con un framework como .NET, entonces es probable que ya tenga colores disponibles en diferentes espacios de nombre.
El impuesto mental sobre tener que lidiar con dos deletreos obstaculizaría en lugar de ayudar a los desarrolladores.
Label myLabel.color = setColour();
No soy un hablante nativo En la escritura, siempre trato de usar en-gb . Sin embargo, en la programación siempre uso en-us lugar de inglés británico por la misma razón que no uso alemán o francés para mis identificadores.
Obtuve otra muestra: serializar y serializar. :)
Personalmente, no creo que importe mucho. Trabajé en proyectos que utilizaban países de ortografía del Reino Unido e Inglés y utilizan la ortografía del Reino Unido. Todavía es inglés y realmente no importa mucho debido a Intellisense.
Para mi es natural trabajar en inglés británico sin siquiera pensarlo. Sin embargo, si está desarrollando procedimientos internos, realmente no importa. Si está creando API que se usarán públicamente y su audiencia es internacional, ¿por qué no implementar ambas?
Prefiero el inglés de Estados Unidos
Primero, estoy en los Estados Unidos. En mi proyecto actual, siempre es "de color", sin embargo, la palabra que parece que no podemos elegir es "gris" frente a "gris".
En realidad se ha vuelto bastante molesto.
Si mira hacia atrás unos pocos cientos de años, verá que el cambio no tiene nada que ver con los EE. UU., Como muchos pensarían. Los cambios provienen de influencias europeas, particularmente de los franceses. Antes de ese momento, la palabra inglesa "color" se escribía en realidad como "color".
Intentar estandarizar sería inútil ya que la mitad de los niños chinos están aprendiendo la influencia preeuropea y la comprensión de los EE. UU. Del inglés, mientras que la otra mitad lo está asumiendo tal como está hoy, como el idioma inglés.
Si crees que el idioma es un problema, debes considerar el Taiwán Kg que pesa 600 g. Todavía tengo que descubrir cómo lo manejaron, pero espero que nunca sean empleados como personal de abastecimiento de combustible para aviones.
Si todos sus programadores son británicos, use en-gb. Si su código será visto por programadores fuera de Gran Bretaña, en-us sería una mejor opción.
Un punto menor, confiamos en un servicio de traducción para copiar nuestra documentación en otros idiomas. Hemos encontrado que obtenemos mejores traducciones cuando usamos en-us como fuente.
Siempre uso en-GB para toda mi programación. Supongo que se debe a una gran influencia de las novelas británicas.
Sin embargo, ¿no sería posible tener dos conjuntos diferentes de API (una para en-US, otra para en-GB) que internamente llaman a la misma función? Sin embargo, esto podría hinchar los archivos de encabezado, ¿así que tal vez dependiendo de la definición del preprocesador, una compilación condicional? Si usas C ++, podrías hacer algo como lo siguiente ...
#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 cliente define ENGB o no, como se muestra a continuación
#define ENGB
podría usar las API en la cultura que prefiera. Tal vez demasiado para un propósito tan trivial, pero bueno, si parece importante, ¿por qué no? :)
Soy una de esas personas cuya frecuencia cardíaca y presión arterial aumentan cada vez que me veo obligado a utilizar el inglés americano en los archivos de configuración, etc., debido a que el software no da la opción de inglés británico, pero eso es solo yo :)
Sin embargo, mi opinión personal sobre esta sería proporcionar ambas ortografías, darles setColor () y setColour (), escribir el código en una de ellas, y hacer que la segunda pase los parámetros.
De esta forma mantendrás contentos a los dos grupos, con la condición de que tu intellisense se alargue un poco, pero al menos la gente no puede quejarse de ti usando el lenguaje "incorrecto".
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 esto es para un lenguaje dinámico o uno en el que los IDE modernos no son la norma, me inclinaría por la ortografía estadounidense. Por supuesto que soy estadounidense y, por lo tanto, estoy obviamente predispuesto, pero parece que la mayoría del código que veo de los desarrolladores que no son hablantes nativos de inglés usa la ortografía de los Estados Unidos para sus nombres variables, etc.
También voy a tener que ponerme del lado del inglés de EE. UU., Simplemente para mantener las cosas consistentes (como otros ya lo han notado aquí). Aunque soy un hablante nativo de EE. UU.-Inglés, he realizado proyectos de software con compañías de software alemanas y suecas, y en ambos casos la tentación de vez en cuando podría afectar a mis compañeros de equipo para usar texto 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 desagradable para los ojos y hace que sea más difícil incluir a un nuevo no hablante en el proyecto.
La mayoría de las empresas de software europeas (al menos aquellas con las que he trabajado) se comportan de la misma manera: el código se mantiene en inglés, simplemente porque eso hace que el código sea más amigable con la comunidad si otro programador se suma. La documentación interna por lo general tiende a hacerse en el idioma nativo, sin embargo.
Dicho esto, la distinción aquí es sobre dos dialectos diferentes de 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 que mantenga la API en inglés de EE. UU., Pero sus comentarios en GB-inglés si le conviene más.
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 ortografía diferente me emociona.
La mayoría de las bibliotecas y marcos con los que estoy familiarizado usan la ortografía de los EE. UU. Por supuesto, soy estadounidense, así que ... EE. UU.-Inglés es mi lengua materna.
Tiendo a usar el inglés de EE. UU. Ya que se ha convertido en la norma en otras API. Hablando como programador en inglés, no tengo ningún problema para usar "color", por ejemplo.
Yo diría que mire cómo otras bibliotecas en su idioma eligen y siguen sus convenciones.
Los diseñadores del lenguaje de programación y sus API integradas tomaron una decisión, y si los usuarios son internacionales o no, están acostumbrados a ver la ortografía consistente con esta opció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 se den cuenta de que hay diferencias entre el inglés estadounidense y el inglés GB. No los confunda al cambiar los lados del estanque.
Yo uso lenguajes .NET principalmente, y .NET Framework usa ortografía en inglés de EE. UU. En esta plataforma, me quedaría con el inglés de EE. UU. No conozco ningún idioma estandarizado en inglés GB, pero si el suyo ya lo ha hecho, manténgase en consonancia con el idioma.