Anglais GB ou anglais américain?

Si vous avez une API et que vous êtes un développeur basé au Royaume-Uni avec une audience très internationale, votre API devrait-elle être

setColour()

ou

setColor()

(Pour prendre un mot comme exemple simple.)

Les ingénieurs basés au Royaume-Uni sont souvent assez défensifs quant à leur orthographe «correcte», mais on pourrait affirmer que l'orthographe américaine est plus «standard» sur le marché international.

Je suppose que la question est: est-ce important? Les développeurs d'autres pays ont-ils des difficultés avec l'orthographe GB, ou est-il normalement assez clair ce que cela signifie?

Est-ce que tout devrait être anglais américain?

J'aurais tendance à utiliser l'anglais américain car c'est devenu la norme dans d'autres API. Parlant en tant que programmeur anglais, je n'ai aucun problème à utiliser "color", par exemple.

Je ne suis pas un locuteur natif. Dans l'écriture, j'essaie toujours d'utiliser en-gb. Cependant, dans la programmation, j'utilise toujours à la en-usplace de l'anglais britannique pour la même raison que je n'utilise ni l'allemand ni le français pour mes identifiants.

Cela dépend de l'endroit où vous voyez la plupart de vos clients. Personnellement, je préfère utiliser English-GB (par exemple Color) dans mon code privé, mais je vais à Color pour les applications / API / code publiés en externe!

En général, je serais un adepte de l'orthographe GB mais je pense que le code se lit beaucoup mieux s'il est cohérent et je trouve:

Color lineColor = Color.Red;

pour paraître beaucoup mieux que:

Color lineColour = Color.Red;

Je suppose qu'en fin de compte, cela n'a pas vraiment d'importance.

Même si je suis généralement très pédant sur l'orthographe correcte, en tant que développeur britannique, j'opterais toujours pour l'orthographe américaine «couleur». Dans tous les langages de programmation que j'ai rencontrés, c'est comme ça, donc pour des raisons de cohérence, utiliser «couleur» a beaucoup de sens.

En supposant qu'il s'agisse d'une API Java ou C #, cela n'a probablement pas d'importance étant donné l'omniprésence de la fonctionnalité de saisie semi-automatique dans les IDE. Si c'est pour un langage dynamique ou un langage où les IDE modernes ne sont pas la norme, j'irais avec les orthographes américaines. Bien sûr, je suis un Américain et je suis donc manifestement biaisé, mais il semble que la plupart des codes que je vois de développeurs qui ne sont pas de langue maternelle anglaise utilisent des orthographes américaines pour leurs noms de variables, etc.

En tant que programmeur anglais, j'utilise en-US pour mon développement logiciel. L'anglais américain domine si bien dans presque toutes les autres API qu'il est beaucoup plus facile de s'en tenir à un type d'orthographe et de supprimer l'ambiguïté. C'est une perte de temps à chercher une méthode uniquement pour trouver que l'orthographe est décalée d'une lettre en raison de la localisation de l'orthographe.

J'irais avec les normes actuelles et choisirais l'orthographe anglaise américaine. HTML et CSS sont des normes reconnues avec l'orthographe "couleur", deuxièmement, si vous travaillez avec un framework comme .NET, il y a de fortes chances que vous ayez déjà des couleurs disponibles dans différents espaces de noms.

La taxe mentale sur le fait d'avoir à traiter deux orthographes entraverait plutôt que d'aider les développeurs.

Label myLabel.color = setColour();

J'ai des problèmes avec les API qui ne sont pas en anglais américain. Juste à cause des différences d'orthographe. Je sais ce que signifient les mots mais les différentes orthographes me trébuchent.

La plupart des bibliothèques et des frameworks que je connais utilisent les orthographes américaines. Bien sûr, je suis américain, donc ... l'anglais américain est ma langue maternelle.

La majorité de la documentation de développement (tout comme MSDN) est en anglais américain.

Il serait donc préférable de rester avec le flux principal et d'utiliser l'anglais américain dans votre API si vous ciblez un public international.

J'ai un autre échantillon: Serialise et Serialize. :)

Personnellement, je ne pense pas que cela compte beaucoup. J'ai travaillé sur des projets qui utilisaient des pays d'orthographe anglais-britannique et ils utilisent l'orthographe britannique. C'est toujours l'anglais et cela n'a pas vraiment d'importance à cause d'Intellisense.

En tant que Canadien, je rencontre cela tout le temps. Il m'est très difficile de taper «couleur» car ma mémoire musculaire continue d'atteindre le «u».

Cependant, j'ai tendance à adopter le langage des bibliothèques. Java a la classe Color, donc j'utilise la couleur.

J'essaie de trouver des mots alternatifs si possible. Je vais laisser glisser -ize. Pour la couleur, je pourrais éventuellement utiliser la teinte, l'encre, le premier plan / l'arrière-plan ...

Sinon, en tant qu'Anglais, j'utiliserai en-GB car j'ai une certaine fierté de mon pays et de mes origines.

Si cela devait faire partie d'un projet plus grand, en particulier un projet international, je garderais le projet entier cohérent au-dessus d'avoir une petite partie dans une variante de langue et le reste dans une autre.

Je vais également devoir me ranger du côté de l'anglais américain, simplement pour garder les choses cohérentes (comme d'autres l'ont déjà noté ici). Bien que je parle anglais américain, j'ai réalisé des projets logiciels avec des sociétés de logiciels allemandes et suédoises, et dans les deux cas, la tentation pouvait parfois frapper mes coéquipiers d'utiliser du texte allemand ou suédois dans le code - généralement pour des commentaires, mais parfois aussi pour les noms de variables ou de méthodes. Même si je peux parler ces langues, c'est vraiment choquant pour les yeux et il est plus difficile d'amener un nouveau non-locuteur dans le projet.

La plupart des éditeurs de logiciels européens (du moins ceux avec lesquels j'ai travaillé) se comportent de la même manière - le code reste en anglais, simplement parce que cela rend le code plus convivial si un autre programmeur se joint à lui. Cependant, la documentation interne a généralement tendance à être rédigée dans la langue maternelle.

Cela dit, la distinction ici concerne deux dialectes différents de l'anglais, ce qui n'est pas aussi extrême que de voir deux langues totalement différentes dans le même fichier de code source. Donc, je dirais, gardez l'API en anglais américain, mais vos commentaires en GB-anglais si cela vous convient mieux.

Je dirais de regarder comment les autres bibliothèques de votre langue choisissent et suivent leur convention.

Les concepteurs du langage de programmation et de ses API intégrées ont fait un choix, et que les utilisateurs soient internationaux ou non, ils ont l'habitude de voir des orthographes cohérentes avec ce choix. Vous ne ciblez pas les locuteurs d'une langue différente mais les utilisateurs d'un langage de programmation. Il y a de fortes chances qu'ils aient appris pas mal de mots dans la langue étrangère à partir des API intégrées, et ils ne sont peut-être pas conscients des différences entre l'anglais américain et l'anglais britannique. Ne les confondez pas en changeant de côté de l'étang.

J'utilise principalement les langages .NET et le .NET Framework utilise des orthographes en anglais américain. Sur cette plate-forme, je m'en tiendrai à l'anglais américain. Je ne connais aucune langue normalisée sur l'anglais GB, mais si la vôtre l'a fait, alors restez cohérent avec la langue.

Je suis d'accord avec la troupe "go for American". Je préfère moi-même en-GB pour écrire des e-mails et autres, mais l'anglais américain est à peu près la norme dans tous les cercles de programmation.

Même si l'anglais britannique est ce qui est parlé dans le monde entier, je recommande d'utiliser l'anglais américain qui, comme d'autres personnes l'ont dit, domine le marché.

Certainement l'anglais américain.

Premièrement, je suis aux États-Unis. Dans mon projet actuel, c'est toujours «couleur» cependant, le mot pour lequel nous ne parvenons pas à choisir une orthographe est «gris» contre «gris».

C'est en fait devenu assez ennuyeux.

La sélection de la langue pour les noms d'identifiant n'a rien à voir avec l'audience et tout à voir avec la langue d'origine dans laquelle le framework ou l'API a été développé.

Je ne connais pas beaucoup de langues mais je ne peux pas penser à une seule qui utilise autre chose que l'anglais américain.

Les dangers d'introduire des bogues subtils dus à des orthographes différentes sont trop grands à mon humble avis.

Un remplacement de fonction peut facilement devenir une pseudo-surcharge.

Un fichier de configuration peut devenir invalide en raison d'une différence d'orthographe.

Une situation peut survenir où le même objet conceptuel a été défini en utilisant plusieurs classes, en utilisant à la fois en-US et en-GB.

Ainsi donc, qu'un morceau de code soit purement à usage interne ou destiné à un usage externe également, les orthographes utilisées doivent toujours correspondre à la langue d'origine de la plateforme / du framework / du compilateur / de l'API.

Si tous vos programmeurs sont britanniques, utilisez en-gb. Si votre code est vu par des programmeurs en dehors de la Grande-Bretagne, alors en-nous serait un meilleur choix.

Un point mineur, nous comptons sur un service de traduction pour copier notre documentation dans d'autres langues. Nous avons constaté que nous obtenons de meilleures traductions en utilisant en-us comme source.

Vous devez tenir compte de votre public. Qui va utiliser le code et qu'attendent-ils de voir?

Je travaille dans une entreprise qui a des bureaux au Canada et aux États-Unis. Nous utilisons l'orthographe canadienne (très similaire à l'anglais britannique) lors de la production de documentation et de code au Canada et aux États-Unis pour ce qui est utilisé aux États-Unis.

Certaines choses traversent les frontières, mais la différence d'orthographe est rarement un problème. Cela peut réellement générer des dialogues intéressants lorsque les Américains ne sont pas conscients des différentes orthographes du candien et de l'anglais britannique. Parfois, ils sont d'accord avec cela, d'autres fois ils insistent pour qu'il passe à l'orthographe "correcte". Cela affecte également les formats de date (jj / mm / aaaa au Canada et mm / jj / aaaa aux États-Unis)

Lorsqu'il y a une impasse, nous utilisons généralement l'orthographe américaine, car les Canadiens connaissent les deux variantes.

La principale raison que j'ai entendue pour choisir les États-Unis plutôt que l'anglais britannique est que le public britannique, confronté à l'orthographe américaine, se rend compte que c'est une application américaine (ou présume qu'il en est ainsi), alors qu'un public américain confronté à l'orthographe britannique pense '... . hé, c'est faux ... c'est la couleur pas la couleur '

Mais comme d'autres l'ont dit, standardisez. Choisissez et respectez-le.

Il me vient naturellement de travailler en anglais britannique sans même y penser. Cependant, si vous développez des procédures internes, cela n'a pas vraiment d'importance. Si vous créez des API qui seront utilisées publiquement et que votre public est international, pourquoi ne pas mettre en œuvre les deux?

Je préfère l'anglais américain.

Je fais partie de ces personnes dont la fréquence cardiaque et la tension artérielle augmentent chaque fois que je suis obligé d'utiliser l'anglais américain dans les fichiers de configuration, etc., en raison du fait que le logiciel ne donne pas l'option pour l'anglais britannique, mais c'est juste moi :)

Mon opinion personnelle sur celui-ci serait cependant de fournir les deux orthographes, de leur donner setColor () et setColour (), d'écrire le code dans l'un d'entre eux et de laisser passer les paramètres par le second.

De cette façon, vous gardez les deux groupes heureux, à condition que votre intellisense s'allonge un peu, mais au moins les gens ne peuvent pas se plaindre que vous utilisez le «mauvais» langage.

Si vous regardez quelques centaines d'années en arrière, vous constaterez que le changement n'a rien à voir avec les États-Unis, autant que beaucoup le pensent. Les changements proviennent d'influences européennes, notamment françaises. Auparavant, le mot anglais «couleur» était alors orthographié «couleur».

Essayer de standardiser serait vain car la moitié des enfants chinois apprennent l'influence pré-européenne et la compréhension américaine de l'anglais, tandis que l'autre moitié le prend tel qu'il est aujourd'hui, en tant que langue anglaise.

Si vous pensez que la langue est un problème, alors vous devriez considérer le Taiwan Kg qui pèse 600g. Je n'ai pas encore découvert comment ils ont réussi celui-là, mais j'espère qu'ils ne seront jamais employés comme personnel de ravitaillement en avion!

J'utilise toujours en-GB pour toute ma programmation. Je suppose que c'est dû à une forte influence des romans britanniques.

Cependant, ne serait-il pas possible d'avoir deux ensembles différents d'API (un pour en-US, un pour en-GB) qui appellent en interne la même fonction? Cela pourrait cependant gonfler les fichiers d'en-tête, donc peut-être en fonction d'une définition de préprocesseur, d'une compilation conditionnelle? Si vous utilisez C ++, vous pouvez faire quelque chose comme ci-dessous ...

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

Selon que le programmeur client définit ou non ENGB comme ci-dessous

#define ENGB

il pourrait utiliser les API dans la culture qu'il préfère. Peut-être exagéré pour un objectif aussi trivial, mais bon, si cela semble important, pourquoi pas! :)