Code "Internationalisation"

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 dans un protocole et une bibliothèque existants, je travaille avec Norvégien, car je peux raisonnablement vous attendre à ce que les générations de travailleurs administratifs soient habituées à celles-ci et que la bibliothèque dépend de la protocole. Dans une emballage de bibliothèque pour un projet international, j'ai traduit chaque nom de méthode littéralement et ajouté une documentation en anglais de la méthode.

Commentaires et documentation sur le code sont en anglais.

Si 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 conditions commerciales (si raisonnables. Je ne peux guère penser à un exemple où aucun terme ne peut être trouvé.), pour le garder " portable".

Même si tout le monde de l'équipe est un bon orateur anglais (qui n'est pas donné), ils ne connaissent pas nécessairement l'équivalent anglais de toute la terminologie des entreprises.

Je pense que c'est une décision spécifique au projet, quoi permettre, mais je tolérerais généralement et encouragerais des termes métier (par exemple, les noms d'entités) dans la langue locale, mais pas des termes techniques (c'est-à-dire pas grandeur / Hauteduc au lieu de la 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 essayez des traductions anglaises, vous risquez de vous retrouver avec plus de malentendus que vous ne le faites en laissant des langages mixtes.

Si vous écrivez le code que vous pouvez être utilisé à l'échelle internationale un jour, écrivez-le en anglais. De doute, écrivez-le en anglais, même des commentaires si vous le pouvez (bien que je suppose que vous pouvez ajouter quelques commentaires dans la langue de votre lieu de travail).

Ce n'est pas spécifique au codage malheureusement. L'anglais n'est pas ma langue maternelle, mais j'ai été en mesure de lire un certain nombre de documents techniques et de participer à des conférences internationales avec des personnes du monde entier. Ces collaborations ne fonctionnaient tout simplement pas si toutes les personnes publiaient dans leurs langues indigènes respectives.

Cela 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 sexe pour les noms, aucune conjugaison, aucun cas.

Généralement, le code faisant référence aux concepts de langue devrait être dans la même langue maternelle que le langage de programmation (c'est-à-dire anglais - pour, tandis que la chaîne sont tous des mots anglais).

C'est bien (mais pas génial) d'avoir des variables et des concepts de domaine dans une langue locale, mais vous ne voulez certainement pas traduire la liste, l'objet, la décimale, etc. dans des termes qui entraînent davantage les programmeurs de réconcilier deux langues . Même toujours, je serais fortement lobby pour limiter les concepts de domaine très courants tels que la collection, l'adhésion, la personne, l'utilisateur et éventuellement des concepts de domaine moins commun tels que la facturation, la réception à l'anglais, où cela est possible.

Il serait comme coder la moitié de vos classes en VB et la moitié en C # - votre cerveau doit faire un changement cognitif. Bien que cela soit bon pour les applications hybrides (JavaScript sur le Web et C # sur le backend) car cela vous aide à garder ce qui fonctionne si clair, ce n'est pas bon pour une programmation générale.

En outre, l'utilisation de l'anglais pour tout fait fonctionner le domaine et les mots de langue fonctionnent mieux.

Il y a toujours des exceptions. Il y a certains cas où vous utiliseriez de toute façon un mot natif - où le mot décrit le mieux le domaine. Par exemple, dans notre base de code (anglais), nous avons eu des références aux conditions espagnoles mexicaines pour certains concepts qui n'étaient que pertinents pour les personnes qui exécutent nos logiciels au Mexique. Typiquement, les termes japonais ont été épelés phonétiquement / romaji, cependant, il était difficile pour les non-japonais de pouvoir prononcer les pictogrammes; -).

garder les choses cohérentes, je ferais le code la même langue (humaine) que la langue (programmation). C'est-à-dire que si le langage de programmation utilise des mots-clés anglais (comme pour , commutateur , public , etc) puis gardez le reste du code en anglais . Si vous utilisez un compilateur qui reconnaît (disons) les traductions swahili des mots-clés, alors gardez le reste du code dans Swahili.

De nombreuses API ont des schémas de dénomination normalisés suivis quelle que soit la langue (humaine) et la documentation ci-jointe est traduite au besoin (au lieu du code source).

Peu importe la langue (humaine) que vous choisissez, choisissez-en une et colle avec elle. Je préférerais beaucoup essayer de faire l'eau à travers le code source en allemand que le code qui était un mélange d'allemand et d'anglais.