Code "internationalisation"

Question

j'ai travaillé sur différents projets dans différents pays et a fait remarquer que, parfois, le code est devenu internationalisé, comme

Set LargeurEtHauteur()                                                     (pour SetWidthAndHeight, fr)
Dim _ListaDeObiecte sous forme de liste (de l'objet)     (pour _ObjectList, ro)
vide interne Sohranenie utilisateur ov()                         (pour SaveUsers, ru)
etc.

Il arrive que dans les pays où l'alphabet latin ce mélange est plus prononcé, parce qu'il n'y a pas besoin de translittération.

Plus que cela, souvent le "jargon" de programmation est inspiré par le langage de spécifications du projet. Il y a des cas où les termes dans la «langue du projet» ont une signification qui n'est pas «traduisible» en anglais.

Il existe également des projets sur lesquels seulement des travaux, disons une équipe française, utilisent des mots français (par exemple, Personne, Véhicule, Projet etc).

Dans ce cas, j'ajoute personnellement dans les spécifications un «dictionnaire» qui explique tous les noms d'objets de gestion et seulement ces objets sont utilisés dans une autre langue (française).

Dis:

Collectif - Ensemble des Personnes;

Toutes les actions (Obtenir, Définir, Mettre à jour, Modifier, Charger, etc.) sont en anglais.

Maintenant que les noms "forts" peuvent être utilisés dans le code: Ajouter Pour Personne Collectif.

• Quelle est votre approche de «l'internationalisation»?

_{PS.
Je me suis amusé que VisualStudio compile et exécute des projets en .NET avec des boutons nommés à la "btnAdd É l è ve" ou "кпкСтоп" ...}

Answer 1

Mon approche personnelle, qui est partagée par beaucoup mais pas tous dans la communauté de programmation, est que le code source devrait être en anglais et, si possible, tous les outils de développement devraient être aussi en anglais.

La raison la plus importante est d'être capable de part vos problèmes et solutions avec le monde (comme nous le faisons maintenant StackOverflow, pas moins) sans avoir à traduire les noms de classe, des messages d'erreur, chemins et autres artefacts à chaque fois.

Il contribue également à la cohérence, parce que la plupart des bibliothèques sont écrites en anglais et en ayant des noms d'éléments qui se mélangent deux langues ne contribue pas vraiment à personne, en plus d'être une préoccupation constante des conflits internes quand un verbe comme Ajouter est pas toujours traslated.

Anglais code permet également d'ajouter plus facilement les étrangers à un projet sans se soucier de la compréhension et les malentendus (surtout entre, comme l'espagnol et le portugais langues apparentées, qui ont beaucoup de faux amis)

Un bon lien sur ce sujet: http://www.codinghorror.com/blog/2009/03/the-ugly-american-programmer.html

(au cas où quelqu'un se demande, je suis sud-américain et l'anglais est pas ma langue maternelle)

Answer 2

Je pense que je appeler une base de code comme "abysmal" plutôt que "internationalisé", mais la règle générale que j'ai toujours entendue est que si vous pensez que quelqu'un d'autre que votre langue pourrait toucher le code, faites-le en anglais.

Answer 3

J'ai le même problème avec norvégien actuellement. Je suppose que cela dépend de votre position dans le projet, du temps disponible et du rôle du logiciel. Dans mon cas, j'ai décidé de conserver tous les termes d'un protocole et d'une bibliothèque avec lesquels je travaille en norvégien, car je peux raisonnablement m'attendre à ce que des générations d'employés administratifs s'y soient habitués, et puisque la bibliothèque dépend de le protocole. Dans un encapsuleur de bibliothèque pour un projet international, j'ai traduit littéralement chaque nom de méthode et ajouté une documentation en langue anglaise de la méthode.

Les commentaires et la documentation sur le code sont en anglais.

Si vous concevez un logiciel à partir de zéro, j'essaierais de trouver des termes anglais pour tous les noms de méthodes et même des termes commerciaux (si raisonnable, je peux difficilement penser à un exemple où aucun terme ne peut être trouvé). "portable".

Answer 4

Même si tout le monde dans l'équipe est un bon anglophone (ce qui n'est pas une donnée), ils ne peuvent pas nécessairement connaître l'équivalent anglais de toute la terminologie de l'entreprise.

Je pense que c'est une décision spécifique au projet, mais je tolérerais et, dans certains cas, j'encouragerais les termes commerciaux (par exemple les noms d'entités) dans la langue locale, mais pas les termes techniques (Largeur/Hauteur au lieu de Largeur hauteur).Par exemple, dans le monde financier en France, tout le monde sait ce que l'on entend par OPCVM et FCP - si vous tentez des traductions en anglais, vous risquez de vous retrouver avec plus de malentendus qu'en autorisant les langages mixtes.

Answer 5

Si vous écrivez un code qui vous permettra d'être utilisé dans le monde entier un jour, écrivez-le en anglais. En cas de doute, écrivez-le en anglais, même si vous le pouvez des commentaires (bien que je suppose que vous pouvez ajouter quelques commentaires dans la langue de votre lieu de travail).

Ce n'est malheureusement pas spécifique au codage. L'anglais n'est pas ma langue maternelle, mais j'ai pu lire un certain nombre d'articles techniques et participer à des conférences internationales avec des gens du monde entier. Ces collaborations ne fonctionneraient tout simplement pas si tout le monde publiait dans leur langue maternelle respective.

Il peut être triste si vous avez envie de défendre votre langue à tout prix, mais vous devez être réaliste à ce sujet. Je suppose que l'anglais a l'avantage d'être relativement simple pour atteindre un niveau de base: pas de genre pour les noms, pas de conjugaisons, pas de cas.

Answer 6

Généralement, le code se référant aux concepts de langage doit être dans la même langue maternelle que le langage de programmation (c'est-à-dire en anglais - for, while, string étant tous des mots anglais). Il est correct (mais pas génial) d'avoir des variables et des concepts de domaine dans une langue locale, mais vous ne voulez certainement pas traduire List, Object, Decimal, etc. en termes qui obligent les programmeurs à travailler plus en réconciliant deux langues. Même encore, je voudrais vivement faire pression pour restreindre les concepts de domaine très communs comme Collection, Adhésion, Personne, Utilisateur et éventuellement des concepts de domaines moins communs comme Facture, Reçu en anglais lorsque cela est possible. Ce serait comme coder la moitié de vos cours en VB et la moitié en C# - votre cerveau doit faire un changement cognitif. Bien que ce soit bon pour les applications hybrides (JavaScript sur le web et C# sur le backend), car il vous permet de garder ce qui fonctionne là où c'est clair, ce n'est pas bon pour une programmation générale. En outre, l'utilisation de l'anglais pour tout permet de mieux travailler ensemble sur les noms de domaine et de langue.

Il existe toujours des exceptions. Il y a certains cas où vous utiliseriez un mot natif de toute façon - où le mot décrit le mieux le domaine. Par exemple, dans notre base de code (en anglais), nous avions des références à des termes d'espagnol mexicain pour certains concepts qui n'étaient pertinents que pour les personnes qui exécutaient notre logiciel au Mexique. Typiquement, les termes japonais étaient orthographiés phonétiquement/Romaji, cependant - il était difficile pour les non-Japonais de prononcer les pictogrammes ;-).

Answer 7

Pour que les choses restent cohérentes, je ferais du code le même langage (humain) que le langage (programmation). C'est-à-dire, si le langage de programmation utilise des mots-clés anglais (comme for, switch, public, etc.) alors gardez le reste du code en anglais. Si vous utilisez un compilateur qui reconnaît (disons) les traductions swahili de mots-clés, gardez le reste du code en swahili.

De nombreuses API ont des schémas de dénomination standardisés qui sont suivis indépendamment du langage (humain), et la documentation d'accompagnement est traduite si nécessaire (au lieu du code source). Peu importe le langage (humain) que vous choisissez, choisissez-en un et respectez-le. Je préférerais plutôt essayer de parcourir le code source en allemand que le code qui était un mélange d'allemand et d'anglais.

Answer 8

Je pense que la bonne directive de conception est d'écrire le code avec l'utilisation des noms anglais et avec des commentaires anglais seulement (bien sûr si votre équipe est capable de faire ceci, mais dans le cas d'une équipe internationale car c'est une langue très populaire, surtout dans le monde de l'informatique).

bonne explication de cette guidline est que mots-clés dans la plupart des langages de programmation sont prises à partir de l'anglais écrit de sorte que votre code à l'aide des noms anglais donne davantage de cohérence et grâce à cela, vous finissez avec le code qui est plus facile à lire.

Une autre raison est que la plupart des compilateurs ne peut traiter que des caractères ASCII que les noms des classes, méthodes, etc. donc probablement vous finirez avec quelques noms étranges lorsque vous décidez d'utiliser une langue avec l'alphabet contenant les caractères non ascii.

La troisième raison qui me vient à l'esprit est de partager votre code sur site comme SO. Aujourd'hui j'ai ouvert un post avec un morceau de code où les classes avaient des noms espagnols. Il était difficile pour moi de deviner quel était le but de cette classe (même si parfois ce n'est pas nécessaire c'est bien quand vous lisez le code et comprenez tous les mots utilisés :)).

Pour résumer, je pense que l'internationalisation du code n'est pas une bonne idée. Vous pouvez imaginer que les mots clés dans les langages de programmation (classe, par exemple, essayer, tout) pourrait également être localisé et probablement vous pouvez aussi imaginer comment la vie dure pourrait être alors ...