C'est quelque chose que je me suis toujours demandé, et je ne trouve aucune mention de cela nulle part en ligne. Lorsqu'un magasin du Japon, par exemple, écrit du code, pourrais-je le lire en anglais? Ou les langages, comme C, PHP, n'importe quoi, ont-ils des traductions japonaises qu'ils écrivent?
Je suppose que ce que je demande, c'est est-ce que chaque codeur dans le monde connaît suffisamment l'anglais pour utiliser exactement les mêmes mots réservés que je fais?
Est-ce que ce code:
If (i < size){
switch
case 1:
print "hi there"
default:
print "no, thank you"
} else {
print "yes, thank you"
}
afficher exactement la même chose que je le vois en ce moment en anglais, ou une autre personne non anglophone verrait-elle les mots "si", "changer", "cas", "par défaut", "imprimer" et " d'autre "dans leur langue maternelle?
EDIT - oui, c'est grave. Je ne savais pas si différentes localisations d'une langue avaient des mots-clés différents. ou s'il y a même des localisations différentes.
Si j'ai bien compris, la question est en fait: "Est-ce que chaque codeur dans le monde connaît suffisamment l'anglais pour utiliser exactement les mêmes mots réservés que moi?"
Eh bien .. L'anglais n'est pas le sujet ici mais les mots réservés du langage de programmation. Je veux dire, quand j'ai commencé il y a environ 10 ans, je n'avais aucune idée de l'anglais, et j'ai quand même pu programmer des choses simples en apprenant le langage de programmation, même quand je ne savais pas ce qu'ils signifiaient (en anglais). En fait, cela m'a aidé à apprendre l'anglais.
Par exemple. Je sais que pour faire une "iteración" (itération bien sûr) j'ai dû écrire:
for( i = 0 ; i < 100 ; i++ ) {}
Pour moi, le "pour", le ";" et le "++" où de simples mots ou symboles étrangers. Plus tard, j'apprends que "pour" signifiait "para" et "tandis que" signifiait "mientras" etc. mais en attendant je n'avais pas besoin de connaître l'anglais, mais dans mon cas ce dont j'avais besoin était de connaître "C".
Bien sûr, quand j'ai eu besoin d'apprendre plus de choses, j'ai dû apprendre l'anglais, car la documentation est écrite dans cette langue.
La réponse est donc: non, je ne vois pas si, pendant, pour etc. dans ma langue maternelle. Je les vois en anglais, mais ils ne signifiaient pour moi aucune autre chose qu'ils signifiaient pour le langage de programmation à leur tour.
Est comme une instruction switch dans bash: case .. esac. Qu'est-ce que "esac" ... pour moi la fin de l'instruction switch dans bash.
Je suppose que c'est ce que nous appelons "abstraction"
Dans la langue Java Java, certaines méthodes doivent être nommées (au moins partiellement) en utilisant la langue anglaise en raison de la convention JavaBeans.
Cette convention nécessite qu'une propriété X soit établie via une paire de méthodes getX () et setX (). Ici au Canada français, où certains développeurs sont obligés de coder en français, cela conduit à la parodie suivante:
interface Foo {
Color getCouleur();
void setCouleur(Color couleur);
}
J'ai du mal à trouver des références, mais je me souviens de trois histoires.
Un pirate LISP défend des fonctions dénuées de sens comme "cdr" et "car" en les comparant à la programmation dans votre langue non native: http://people.csail.mit.edu/gregs/ll1-discuss-archive- html/msg01171.html
Lorsque Yukihiro Matsumoto ("Matz") a commencé à développer Ruby, il a utilisé des mots-clés anglais même s'il écrivait toute la documentation en japonais!. Il n'y avait pas de documentation en anglais pour Ruby pendant quelques années, et très peu d'Américains utilisent la langue. Mais maintenant c'est une langue de classe mondiale, et le fait qu'elle soit née au Japon n'est que Si la langue avait utilisé des mots clés en hiragana, elle aurait eu beaucoup plus de mal à gagner en popularité.
J'ai lu un essai une fois - peut-être que quelqu'un d'autre peut le trouver, Google ne nous aide pas aujourd'hui - qui suggérait que la traduction de mots clés était erronée parce que les mots n'étaient pas réellement anglais - ils étaient du jargon. Non seulement (pour utiliser les exemples ci-dessus) para et verser pas tout à fait le sens exact que for a en anglais, pour les non-programmeurs, l'expression "for loop" est du charabia. Même les Américains doivent apprendre une nouvelle signification. Donc, traduire le sens superficiel des mots dans une autre langue revient plus à faire un jeu de mots cross-language qu'à être réellement utile.
Je n'ai vraiment pas trop pensé à la programmation en japonais auparavant, mais c'est parti, en utilisant l'exemple de code de la question.
En utilisant uniquement les instructions de langue en japonais avec les variables en anglais:
// In Japanese, it makes more sense to put the keywords/modifiers as
// postfix expressions rather than prefix expressions.
(i < size)か {
(l[i])は {
1だ:
「もしもし。」を書く;
省略時値:
「いいえ、いいですよ。」を書く;
}
} ない {
「はい、ありがとうございます。」を書く;
}
Comme de nombreuses personnes l'ont déjà souligné, dans la plupart des langages de programmation, il suffit d'apprendre quelques mots clés, donc peu importe s'ils sont en anglais (ou dans une langue autre que la vôtre, d'ailleurs). C'est juste un symbole que vous associez à une construction. Par exemple, dans VB vous avez "THEN", qui dans de nombreux langages de style C serait "{" et cela ne fait pas une grande différence de lisibilité (enfin, du moins c'est comme ça Je le vois, étant un locuteur natif non anglais).
Mais là où les choses peuvent parfois devenir poilues, et où le choix du langage (naturel) est important dans la dénomination des identificateurs. Si les noms des variables, fonctions, classes, etc., n'ont pas de nom significatif pour vous en raison d'une barrière de langage, suivre même le code le plus simple peut être plutôt difficile.
Je me souviens que quelqu'un m'a donné un court extrait d'Actionscript extrait d'un blog. Les noms étaient en allemand et comme je ne parle pas un mot de cette langue, les choses auraient pu s'appeler également var_123, var_562 ou func_333 (et il aurait probablement été plus facile pour moi de me souvenir des noms ou du moins d'avoir un chance de les épeler correctement sans copier ni coller). Comme il s'agissait d'un court extrait autonome, j'ai utilisé un traducteur en ligne pour donner à ces variables et fonctions des noms significatifs dans ma langue maternelle (l'espagnol) et après cela, tout était clair. Le fait est que le code était en fait simple, mais je n'ai pu le comprendre que sans trop d'effort (inutile) supplémentaire au moment où j'ai surmonté la barrière de la langue.
Depuis lors, je suis passé à l'utilisation de l'anglais pour nommer les identifiants. Que cela vous plaise ou non, c'est le "koine" pour la programmation, l'ingénierie et généralement les trucs techniques. La plupart des API sont écrites en anglais, tout comme la plupart de la documentation (et probablement les meilleures ressources que vous pouvez trouver sont également en anglais). En plus de Nice, il garde votre code plus cohérent avec le code avec lequel vous êtes susceptible d'interagir, et je pense qu'il a tendance à être plus compact et succinct que d'autres langues comme l'espagnol (qui autrement serait mon choix naturel).
Bien sûr, si vous ne comprenez pas au moins un peu d'anglais, le problème reste le même, donc ce n'est pas une solution parfaite. Mais, étant donné un certain nombre de développeurs de nombreux pays différents, les chances sont que la langue commune pour eux de communiquer (par le biais du code et bien sûr d'autres moyens) sera l'anglais. Donc, choisir l'anglais est peut-être la meilleure option, même si ce ne serait pas la solution parfaite à ce problème.
Le langage de programmation définit des mots clés et des noms de classe standard, et il est préférable de donner aux types définis par l'utilisateur, aux variables et aux fonctions des noms anglais (en tant que locuteur non natif, je peux le dire ;-).
Alors oui, si tout va bien, vous pourrez lire le code.
Cependant, des langages comme Java et Perl autorisent l'ensemble Unicode complet pour les identificateurs, donc si quelqu'un écrit ses noms de classe en Kanji, vous aurez probablement un problème.
Mise à jour: Pour Perl, il y a un module de blague qui vous permet d'écrire Perl en latin. Mais c'est vraiment juste ça, une blague. Personne n'utilise des choses comme ça au sérieux.
Deuxième mise à jour: L'idée de langages de programmation localisés n'est pas si ridicule. Le langage macro d'Excel est localisé, mais heureusement, il est stocké dans un langage canonique (anglais) dans le fichier, donc la localisation n'est qu'une couche au-dessus de la chose normale. De telles choses n'ont de sens que pour les petits "programmes", pour les "vrais" programmes, cela devient difficile à maintenir.
En fait, il y a certains langages de programmation non basés sur l'anglais (Wikipedia)
Je suis norvégien mais j'ai toujours utilisé l'anglais pour tout le code, sauf la sortie (en ignorant un code stupide de l'école). En fait, j'écris habituellement tout en anglais, puis je le traduis dans ma langue maternelle, en utilisant gettext (ou quelque chose).
Je suis britannique et un problème que nous rencontrons souvent est le choc orthographique américain/britannique. Cela se produit souvent avec des termes liés à la programmation tels que Initialize () ou Initialize (), Analyze () ou Analyze () etc.
Étant donné que le cadre (dans notre cas, C #) a été conçu par des Américains, nous avons constaté qu'il était préférable d'être cohérent et d'utiliser des orthographes américaines. Nous adoptons même la couleur.
Nous avons un mélange de nationalités dans nos équipes de développement et la plupart des personnes non britanniques tendent naturellement vers l'orthographe américaine.
AppleScript était autrefois disponible dans les dialectes français et japonais. Je ne sais pas pourquoi il a été retiré.
Pour passer au niveau supérieur, qu'en est-il de la possibilité de substituer des symboles?
Après avoir vu des langages comme Brainf ** k et Whitespace j'ai pensé à faire un langage comme celui-ci: il serait identique à C sauf que vous utilisez des accolades fermantes pour ouvrir, des accolades ouvrantes pour fermer, permutez les significations + et -, * et /,; et:,> et <, etc.
Le concept n'est rien de plus qu'un compilateur C modifié par gadget. Mais, comme penser les mots clés différemment, cela vous met au défi de repenser certaines hypothèses de base si vous n'avez jamais pensé à de telles choses auparavant. Ex:
int foo)int i, char c( }
int six = 2 / 3:
int two = six + 4:
if )i > 0( }
printf)"i is negative"(:
{
{
Je fais partie d'une équipe française développant un système logiciel en C #. Malgré le fait que les mots clés du langage de programmation soient ostensiblement anglais, j'imagine que vous auriez beaucoup de difficulté à lire le code car tous les noms de fonction, variables, commentaires de code, tables et colonnes de base de données, spécifications techniques, protocoles et ainsi de suite, sont tous dans Français, y compris ces jolis caractères accentués ç, é, è, ù, etc. Je ne suis même pas certain que le système fonctionnerait même ailleurs en raison de bogues de localisation, comme s'appuyer sur la virgule pour être le séparateur décimal par défaut.
Sinon, WinDev est une plateforme de programmation populaire en France, et son langage de programmation WLangage a des mots-clés en français ou en anglais, voir et exemple ici: texte du lien
Eh bien, comme d'autres l'ont souligné, les mots clés et les appels système resteraient probablement en anglais.
Cependant, la compréhension des mots clés de la langue n'est qu'une petite partie de la compréhension du code. Les noms de variable, les noms de fonction et les commentaires risquent tous d'être dans la langue maternelle de l'auteur.
Edit: Je viens de revenir à ma jeunesse où je suis allé dans les tables de mappage de mon TRS-80 BASIC intégré pour changer les mots-clés en français. Je pouvais changer tous les mots clés mais je ne pouvais pas les agrandir. Conçu pour des programmes amusants.
Ne te moque pas de ça. Il y a quelques années, Microsoft avait annoncé G # (German Sharp) - C # avec des mots clés et une API allemands. Bien sûr, c'était une blague des poissons d'avril, mais tout le site à ce sujet avait l'air si réel et professionnel (et était sur Microsoft.com). Effrayant.
Au travail, nous utilisons deux systèmes de bus de terrain, tous deux développés dans les pays germanophones, qui ont un mélange effrayant d'allemand et d'anglais pour les identifiants, y compris de beaux faux amis. C'est le bordel.
Non, les mots-clés et identifiants anglais conviennent. Bien que certains puissent se demander si ce devrait être Couleur ou Couleur :)
Dans plusieurs projets VBA sur lesquels j'ai travaillé (oui, très tôt dans ma carrière), nous avons dû détecter la version de bureau qui était installée sur la machine de l'utilisateur et modifier les formules utilisées dans les feuilles de calcul en conséquence.
Comme je programme en portugais, "SUM" devrait être traduit en "SOMA" et ainsi de suite. Je ne peux tout simplement pas imaginer le travail nécessaire pour que cela se produise dans plusieurs langues. Quelqu'un d'autre a-t-il souffert de ce problème?
Le seul langue que j'ai vu localisé est Excel avec ses macros. Si vous essayez de résumer une colonne à l'aide d'une version italienne d'Office, vous devez écrire SOMMA(A1:A10)
et non SUM. C'est une honte.
Au fait, juste parce que c'est amusant, voici à quoi devrait ressembler votre code avec des mots-clés italiens:
se (i < size){
commuta
caso 1:
stampa "hi there"
normalmente:
stampa "no, thank you"
} altrimenti {
stampa "yes, thank you"
}
Certaines langues ont traduit des mots clés. Les formules Excel, par exemple. Si vous écrivez des calculs dans une feuille de calcul, ce sera dans votre langue.
Heureusement, ce n'est pas une pratique générale, et même les non-anglophones comme moi remercient Dieu qu'il existe une langue standard pour les mots clés:
Et où s'arrêter? Pouvez-vous imaginer un C en grec ancien?
Les mots-clés doivent rester dans une langue, et bien, ça a commencé avec l'anglais, laissez-le rester. Cela aurait pu être pire (langue asiatique?). Et donc nous devons écrire des méthodes et des commentaires en anglais. Ok, plus de travail pour nous, mais au moins la base de code internationale reste cohérente.
Il existe cependant un cas où l'utilisation de noms et de commentaires de méthodes en langue maternelle peut être une bonne pratique: dans les pays du tiers monde. Je vais au Sénégal dans quelques mois pour gérer un projet Django. Le Sénégal a un taux d'analphabétisation énorme, et c'est donc déjà formidable qu'ils déploient de l'énergie pour améliorer leurs connaissances en programmation. Le français est le natif ici, il serait donc inefficace de les forcer à apprendre l'informatique ET une nouvelle langue en même temps.
BTW, ce serait votre code avec des mots-clés français:
Si (i < taille) {
cas par cas :
cas 1:
afficher "salut"
défaut:
afficher "non merci"
} sinon {
afficher "oui, merci"
}
Ce n'est pas que la traduction des mots-clés n'a rien à voir avec la traduction des chaînes. Bien sûr, nous avons traduit "salut, là" dans notre langue. Les codeurs européens ont même tendance à utiliser I18N beaucoup plus qu'aux États-Unis, leur service peut atteindre un public plus large.
j'ai vu VBA traduit en commandes de type espagnol. c'est l'une des choses les plus laides jamais vues. j'aurais honte d'avoir quelque chose comme ça sur mon ordinateur.
PD: je pense que l'espagnol est une langue beaucoup plus agréable que l'anglais; mais traduire est MAUVAIS
Le langage de script de Filemaker est localisé. Les scripts (et les données!) Sont stockés sous une terrible forme "canonique sorta".
Donc, si vous écrivez un script dans la version américaine, puis l'ouvrez dans la version française, tous les mots-clés et noms de fonction intégrés seront en français. Mais pourquoi ça ne fonctionnera pas?! Aha! La version française utilise "," comme point décimal, et donc pour éviter toute ambiguïté, utilise ";" pour séparer les arguments de fonction - où la version américaine utilise "." et "," respectivement. Cette conversion, vous devez la faire vous-même.
Donc, vous travaillez à travers l'interface d'édition de script incroyablement mauvaise (vous ne pouvez pas écrire de scripts sous forme de fichiers texte) pour corriger toutes ces choses. Ça marche! Génial! Les résultats sont tous faux! Oh non! Aha! La date du 7 janvier 2004 que vous avez entrée dans la version américaine est interprétée comme le 1er juillet 2004 - apparemment, les dates ne sont pas seulement affichées mais stockées dans un ordre dépendant des paramètres régionaux. Je plaisante? Non.
[Remarque: Filemaker 8 et 9 peut être sain d'esprit - je n'ai jamais travaillé qu'avec 3 - 7.]
De manière générale, la plupart des programmeurs s'adaptent au formulaire anglais. J'ai appris à programmer quand j'avais 7 ans et ne parlais que l'hébreu (qui est de droite à gauche) et sans anglais, ce qui en a fait une expérience assez fascinante.
Le problème que vous rencontrez généralement est lié à la documentation, aux variables et aux noms de fonction. J'ai vu ma part de variables dans d'autres langues en utilisant l'alphabet anglais.
La seule langue que je connais et qui a été traduite était le bon vieux logo (toujours incroyable à ce jour).
Votre question est intéressante en ce qui concerne Perl car sa syntaxe est conçue pour suivre le langage naturel (anglais). Je me demande si cela complique la tâche des non-anglophones ...
Bien sûr, Perl et Perlers refusent de jouer selon les règles conventionnelles. Le savant fou Damian Conway a écrit le module Lingua :: Romana :: Perligata qui utilise la magie noire des filtres sources pour vous permettre d'écrire Perl en latin!
Quand j'étais enfant, nous sommes allés en France, et dans un musée où nous sommes allés, je me souviens avoir trouvé un affichage qui vous montrait comment écrire des programmes informatiques. La langue était une sorte de variante BASIC et je m'en souviens très bien en utilisant POUR au lieu de FOR, et ainsi de suite. J'avais 7 ans et je venais tout juste d'apprendre le BASIC, et il me semblait tout à fait naturel que les Français aient leur propre dialecte comme ça !!
Je suppose que c'est peut-être LSE que j'ai vu?
Ici, en Australie, nous devons encore épeler couleur comme couleur. Cependant, je trouve cela ennuyeux lorsque d'autres développeurs (australiens), travaillant sur un projet australien, décident que les noms de variables internes doivent être orthographiés à l'américaine.
J'ai lu beaucoup de code, mais le problème concerne toujours les noms de variable/méthode et les commentaires, s'ils commentent leur code dans leur propre langue, en utilisant une langue de caractères spéciaux comme le japonais ou le cyrillique, nous sommes en difficulté! mais les mots-clés, je pense qu'ils resteront en anglais tels quels.
en italien
se (i < dimensione){
scegli
caso 1:
stampa "ciao"
mancante:
stampa "no, grazie"
} altrimenti {
stampa "sì, grazie"
}
Pour confirmer les inquiétudes d'une affiche précédente, j'ai vu un code Fortran avec une macro inclure pour traduire tous les mots clés de l'anglais vers le français. Permettez-moi de ne pas continuer là-dessus.
J'ai également dû travailler avec un code contenant simultanément des identifiants en italien, allemand, anglais et français, non seulement parce qu'il a été développé dans de nombreux endroits différents, mais aussi parce que le développeur principal l'a trouvé amusant et l'a aidé à ne pas dupliquer les noms d'identifiants ( bien sûr, avec une routine de 2000 lignes de long ....)
Il serait inutile, à mon humble avis, d'i18n une langue syntaxe. Cela tuerait tout type de portabilité.
La seule exception concerne les langues éducatives, comme le LOGO. Ils ont été conçus pour faciliter l'apprentissage, donc la portabilité n'est pas un problème.
Je pense que WordBasic a été localisé. WordBasic a été utilisé pour écrire des macros pour dans Word avant d'utiliser VBA.
Si je m'en souviens bien, seul WordBasic écrit dans la version anglaise s'exécuterait sur toutes les versions localisées. Si vous voulez écrire une version néerlandaise, vous ne pouvez l'exécuter que sur un mot néerlandais.