Codificación en otros idiomas (hablados)

Esto es algo que siempre me he preguntado, y no puedo encontrar ninguna mención en línea en ningún lugar. Cuando una tienda de, digamos Japón, escribe código, ¿podría leerlo en inglés? ¿O los idiomas, como C, PHP, cualquier cosa, tienen traducciones japonesas que escriben?

Supongo que lo que estoy preguntando es si cada codificador en el mundo sabe suficiente inglés para usar exactamente las mismas palabras reservadas que yo.

¿Este código:

If (i < size){ switch case 1: print "hi there" default: print "no, thank you" } else { print "yes, thank you" } 

mostrar exactamente lo mismo que lo estoy viendo en este momento en inglés, o alguna otra persona que no habla inglés vea las palabras “si”, “cambiar”, “caso”, “predeterminado”, “imprimir” y ” else “en su lengua materna?

EDITAR – sí, esto es serio. No sabía si las diferentes localizaciones de un idioma tienen diferentes palabras clave. o si hay incluso localizaciones diferentes en absoluto.

    Si entendí bien, la pregunta en realidad es: “¿todos los codificadores del mundo saben suficiente inglés como para usar exactamente las mismas palabras reservadas que yo?”

    Bueno … Inglés no es el tema aquí, pero el lenguaje de progtwigción reserva palabras. Quiero decir, cuando comencé hace unos 10 años, no tenía ni idea de inglés, y aun así fui capaz de progtwigr cosas simples aprendiendo el lenguaje de progtwigción, incluso cuando no sabía lo que querían decir (en inglés). De hecho, esto me ayudó a aprender inglés.

    Por ejemplo. Sé hacer una “iteración” (iteración del curso) que tuve que escribir:

      for( i = 0 ; i < 100 ; i++ ) {} 

    Para mí el "para", el ";" y el "++" donde palabras o símbolos extranjeros simples. Más tarde me enteré de que "para" significaba "para" y "mientras" significaba "mientras" etc. pero mientras tanto no necesitaba saber inglés, pero en mi caso lo que necesitaba era saber "C".

    Por supuesto, cuando necesitaba aprender más, tenía que aprender inglés, ya que la documentación está escrita en ese idioma.

    Entonces la respuesta es: No, no veo si, mientras, etc. en mi lengua materna. Los veo en inglés, pero no significaron para mí ninguna otra cosa que significaran para el lenguaje de progtwigción.

    Es como la statement de cambio en bash: case ... esac. ¿Qué es "esac" ... para mí el final de la instrucción switch en bash.

    Supongo que eso es lo que llamamos "abstracción"

    Tengo problemas para encontrar referencias, pero me acuerdo de tres historias.

    Un hacker Lisp defiende funciones sin sentido como “cdr” y “car” al compararlas con la progtwigción en su idioma no nativo: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg01171. html

    Cuando Yukihiro Matsumoto (“Matz”) comenzó a desarrollar Ruby, usó palabras clave en inglés a pesar de que estaba escribiendo toda la documentación en japonés. . No había documentación en inglés para Ruby durante un par de años, y muy pocos estadounidenses usaban el idioma. Pero ahora es un lenguaje de clase mundial, y el hecho de que nació en Japón solo tiene un interés histórico. Si el lenguaje hubiera estado usando palabras clave en hiragana, habría sido mucho más difícil ganar popularidad.

    Leí un ensayo una vez, tal vez alguien más puede encontrarlo, Google no es de ayuda hoy, que sugirió que la traducción de palabras clave estaba equivocada porque las palabras no son en realidad inglés, son jerga. No solo (para usar los ejemplos anteriores) para y verter no tiene exactamente el significado que tiene en inglés, para los que no son progtwigdores, la frase “for loop” es jibberish. Incluso los estadounidenses deben aprender un nuevo significado. Entonces, traducir el significado superficial de las palabras a otro idioma es más parecido a hacer un juego de palabras en varios idiomas en lugar de ser realmente útil.

    Realmente no había pensado demasiado en progtwigr en japonés antes, pero aquí vamos, usando el ejemplo del código de la pregunta.

    Usar solo las declaraciones de idioma en japonés con las variables en inglés:

     // In Japanese, it makes more sense to put the keywords/modifiers as // postfix expressions rather than prefix expressions. (i < size)か { (l[i])は { 1だ: 「もしもし。」を書く;省略時値: 「いいえ、いいですよ。」を書く; } } ない { 「はい、ありがとうございます。」を書く; } 

    En el lenguaje Java, algunos métodos deben nombrarse (al menos parcialmente) utilizando el idioma inglés debido a la convención JavaBeans.

    Esta convención requiere que una propiedad X se establezca a través de un par de métodos getX () y setX (). Aquí en francés-canadá, donde algunos desarrolladores están obligados a codificar en el idioma francés, esto lleva a la siguiente parodia:

     interface Foo { Color getCouleur(); void setCouleur(Color couleur); } 

    Como muchas personas ya señalaron, en la mayoría de los lenguajes de progtwigción solo tienes que aprender algunas palabras clave, por lo que no importa tanto si están en inglés (o un idioma que no sea el tuyo, para el caso). Es solo un símbolo que asocias con algún constructo. Por ejemplo, en VB tienes “THEN”, que en muchos lenguajes tipo C sería “{” y no hace una gran diferencia en la legibilidad (bueno, al menos así es como yo lo veo, siendo un no inglés) hablante nativo).

    Pero donde a veces las cosas se ponen peludas, y donde la elección del lenguaje (natural) es importante al nombrar identificadores. Si los nombres de variables, funciones, clases, etc. no tienen un nombre significativo para usted debido a una barrera de idioma, seguir incluso el código más simple puede ser bastante desafiante.

    Recuerdo que alguien una vez me dio un pequeño fragmento de Actionscript tomado de algún blog. Los nombres estaban en alemán y dado que no hablo una palabra de ese idioma, las cosas podrían haber sido llamadas var_123, var_562 o func_333 también (y probablemente me hubiera sido más fácil recordar los nombres o al menos tener un posibilidad de deletrearlos correctamente sin copiar y pegar). Como se trataba de un fragmento corto y autónomo, utilicé un traductor en línea para dar a esos nombres y funciones nombres significativos en mi idioma nativo (español) y después de eso, todo quedó claro. El punto es que el código era realmente simple, pero solo pude darle sentido sin demasiado esfuerzo innecesario justo cuando superaba la barrera del idioma.

    Desde entonces, he cambiado al uso del inglés para nombrar identificadores. Te guste o no, es el “koine” para progtwigción, ingeniería y cosas generalmente técnicas. La mayoría de las API están escritas en inglés y también lo es la documentación (y probablemente los mejores recursos que puedes encontrar también están en inglés). Como buen detalle, mantiene el código más coherente con el código con el que probablemente interactúes, y creo que tiende a ser más compacto y breve que otros idiomas como el español (que de lo contrario sería mi elección natural).

    Por supuesto, si no puede entender al menos algo de inglés, el problema sigue siendo el mismo, por lo que no es una solución perfecta. Pero, dado un número de desarrolladores de muchos países diferentes, es probable que el idioma común para comunicarse (a través del código y, por supuesto, de otros medios) sea el inglés. Entonces, elegir inglés es quizás la mejor opción, aunque no sería la solución perfecta para este problema.

    El lenguaje de progtwigción define las palabras clave y los nombres de clase estándar, y es una buena práctica dar a los tipos definidos por el usuario, variables y funciones también nombres en inglés (como un hablante no nativo puedo decir ;-).

    Entonces sí, si todo está bien, podrás leer el código.

    Sin embargo, idiomas como Java y Perl permiten el conjunto completo de Unicode para los identificadores, por lo que si alguien escribe sus nombres de clase en kanji, es probable que tenga un problema.

    Actualización: para Perl hay un módulo de broma que le permite escribir Perl en latín. Pero es realmente solo eso, una broma. Nadie usa cosas como esta en serio.

    Segunda actualización: la idea de los lenguajes de progtwigción localizados no es tan ridícula. El macro lenguaje de Excel está localizado, pero por suerte está almacenado en un idioma canónico (inglés) en el archivo, por lo que la localización es solo una capa superior a lo normal. Tales cosas solo tienen sentido para pequeños “progtwigs”, para progtwigs “reales” se vuelve difícil de mantener.

    En realidad, hay algunos lenguajes de progtwigción no basados ​​en el inglés (Wikipedia)

    Soy noruego, pero siempre he usado el inglés para todo el código excepto para la salida (ignorando algún código tonto de la escuela). En realidad, generalmente escribo todo en inglés y luego lo traduzco a mi idioma nativo, usando gettext (o algo así).

    Soy británico y un problema con el que nos topamos a menudo es el choque de ortografía estadounidense / británico. Esto ocurre a menudo con términos relacionados con la progtwigción como Inicializar () o Inicializar (), Analizar () o Analizar (), etc. Esto puede (ha) dar lugar a problemas al intentar anular los métodos y, a veces, es difícil de detectar.

    Dado que el marco (en nuestro caso, C #) fue diseñado por los estadounidenses, descubrimos que lo mejor es ser coherentes y utilizar la ortografía estadounidense. Incluso adoptamos Color.

    Tenemos una mezcla de nacionalidades en nuestros equipos de desarrollo y la mayoría de las personas que no son británicas tienden a la ortografía estadounidense de forma natural.

    AppleScript alguna vez estuvo disponible en dialectos francés y japonés. No sé por qué fue retirado.

    Llevando esto al siguiente nivel, ¿qué hay de poder sustituir los símbolos?

    Después de ver idiomas como Brainf ** k y Whitespace , pensé en hacer un lenguaje como este: sería idéntico a C, excepto que usa llaves de cierre para abrir, abrir llaves para cerrar, intercambiar los significados de + y -, * y / ,; y:,> y < , etc.

    El concepto no es más que un comstackdor de C alterado. Pero, al igual que pensar en las palabras clave de manera diferente, te reta a reconsiderar algunas suposiciones básicas si nunca antes has pensado en esas cosas. Ex:

     int foo)int i, char c( } int six = 2 / 3: int two = six + 4: if )i > 0( } printf)"i is negative"(: { { 

    Estoy en un equipo francés desarrollando un sistema de software en C #. A pesar de que las palabras clave del lenguaje de progtwigción son ostensiblemente inglesas, imagino que tendrías una gran dificultad para leer el código ya que todos los nombres de funciones, variables, comentarios de código, tablas y columnas de base de datos, especificaciones técnicas, protocolos, etc. Francés, incluidos los adorables caracteres acentuados ç, é, è, ù, etc. Ni siquiera estoy seguro de si el sistema se ejecutará en otro lugar debido a errores de localización, como confiar en que la coma sea el separador decimal predeterminado.

    De lo contrario, WinDev es una plataforma de progtwigción popular en Francia, y su lenguaje de progtwigción WLanguage tiene palabras clave en francés o inglés, vea y ejemplifique aquí: texto del enlace

    He visto traducir VBA a comandos de estilo español. es una de las cosas más feas jamás vistas. Me avergonzaría tener algo así en mi computadora.

    PD: creo que el español es un idioma mucho más agradable que el inglés; pero traducir es INCORRECTO

    Bueno, como señalaron otros, las palabras clave y las llamadas al sistema probablemente permanecerán en inglés.

    Sin embargo, comprender las palabras clave del lenguaje es solo una pequeña parte para entender el código. Los nombres de variables, nombres de funciones y comentarios corren el riesgo de estar en el idioma nativo del autor.

    Editar : Acabo de volver a mi juventud donde fui a las tablas de mapeo de mi BASIC incorporado TRS-80 para cambiar las palabras clave al francés. Podría cambiar todas las palabras clave pero no podría agrandarlas. Hecho para progtwigs divertidos.

    No te burles de esto Hace algunos años, Microsoft había anunciado G # (Sharp alemán) – C # con palabras clave alemanas y API. Por supuesto, era una broma de April Fools, pero todo el sitio parecía muy real y profesional (y estaba en microsoft.com). De miedo.

    En el trabajo, utilizamos dos sistemas de bus de campo, ambos desarrollados en países de habla alemana, que tienen una combinación aterradora de alemán e inglés para identificadores, incluidos algunos adorables falsos amigos. Es un desastre.

    No, las palabras clave e identificadores en inglés están bien. Aunque algunos podrían discutir si debería ser Color o Color 🙂

    En varios proyectos de VBA en los que he trabajado (sí, al principio de mi carrera) tuvimos que detectar la versión de la oficina que estaba instalada en la máquina del usuario y cambiar las fórmulas utilizadas en las hojas de especificaciones en consecuencia.

    Como programo en portugués, “SUM” tendría que traducirse en “SOMA” y así sucesivamente. Simplemente no puedo imaginar el trabajo necesario para que esto ocurra en varios idiomas. ¿Alguien más ha sufrido este problema?

    El único lenguaje que vi localizado es Excel con sus macros. Si intenta sumr una columna utilizando una versión italiana de Office, debe escribir SOMMA(A1:A10) y no SUMA. Es una pena.

    Por cierto, solo porque es divertido, así es como se verá tu código con las palabras clave italianas:

     se (i < size){ commuta caso 1: stampa "hi there" normalmente: stampa "no, thank you" } altrimenti { stampa "yes, thank you" } 

    Hay algunos idiomas que tienen palabras clave traducidas. Fórmulas de Excel, por ejemplo. Si escribe algunos cálculos en una hoja de cálculo, esto estará en su idioma.

    Afortunadamente, esta no es una práctica general, e incluso los que no hablan inglés como yo agradecemos a Dios que haya un lenguaje estándar para las palabras clave:

    • es más fácil compartir tu trabajo.
    • evita que la documentación se convierta en una pesadilla más grande de lo que ya es.
    • Las palabras y oraciones en inglés son generalmente cortas y sintácticamente pragmáticas. En literatura, los idiomas latinos son mucho más bellos, pero para cosas técnicas, rocas inglesas.

    ¿Y dónde parar? ¿Puedes imaginar una C en griego antiguo?

    Las palabras clave deben permanecer en un idioma, y ​​bueno, comenzó con el inglés, que así sea. Esto podría haber sido peor (¿idioma asiático?). Y entonces tenemos que escribir métodos y comentarios en inglés. Ok, más trabajo para nosotros, pero al menos la base de código internacional sigue siendo congruente.

    Sin embargo, hay un caso en el que el uso de nombres y comentarios de métodos de idioma nativo puede ser una buena práctica: en un país del tercer mundo. Voy a Senegal en algunos meses para administrar un proyecto de Django. Senegal tiene una tasa de analfabetización enorme, y por eso es grandioso que gasten energía para mejorar el conocimiento de progtwigción. El francés es el idioma nativo aquí, por lo que sería ineficiente obligarlos a aprender informática Y una nueva lengua al mismo tiempo.

    Por cierto, ese sería su código con palabras clave francesas:

     Si (i < taille) { cas par cas : cas 1: afficher "salut" défaut: afficher "non merci" } sinon { afficher "oui, merci" } 

    No es que la traducción de las palabras clave no tenga nada que ver con la traducción de las cadenas. Por supuesto, tenemos "hola, allí" traducido en nuestro idioma. Los codificadores europeos incluso tienden a usar I18N mucho más que los estadounidenses, ya que su servicio puede llegar a un público más amplio.

    En general, la mayoría de los progtwigdores se adaptan a la forma en inglés. Aprendí a progtwigr cuando tenía 7 años y solo hablaba hebreo (que es de derecha a izquierda) y sin inglés, lo que lo convertía en una experiencia fascinante.

    El problema que generalmente obtendría es con documentación, variables y nombres de funciones. He visto mi cuota de variables en otros idiomas usando el alfabeto inglés.

    El único idioma con el que estoy familiarizado y que realmente se tradujo fue el logo viejo y bueno (aún sorprendente hasta el día de hoy).

    Cuando era niño fuimos a Francia, y en un museo al que fuimos, recuerdo haber encontrado una pantalla que mostraba cómo escribir progtwigs de computadora. El lenguaje era una especie de variante BÁSICA y la recuerdo claramente usando POUR en lugar de FOR, y así sucesivamente. ¡Tenía 7 años y acababa de aprender BÁSICO, y me parecía completamente natural que los franceses tuvieran su propio dialecto como este!

    Supongo que puede haber sido LSE que vi?

    El lenguaje de scripting de Filemaker está localizado. Los scripts (¡y los datos!) Se almacenan en una terrible forma “sorta canónica”.

    Por lo tanto, si escribe un guión en la versión estadounidense, luego lo abre en la versión francesa, todas las palabras clave y los nombres de función incorporados estarán en francés. ¿Pero por qué no se ejecutará? Aha! La versión francesa usa “,” como el punto decimal, y por lo tanto para evitar ambigüedades usa “;” para separar argumentos de funciones, donde la versión estadounidense usa “.” y “,” respectivamente. Esta conversión debes hacerlo tú mismo.

    Así que trabajas a través de la increíblemente mala interfaz de edición de scripts (no puedes escribir scripts como archivos de texto) para arreglar todo esto. ¡Corre! ¡Estupendo! ¡Los resultados son todos incorrectos! ¡Oh no! Aha! La fecha del 7 de enero de 2004 que ingresó en la versión estadounidense se está interpretando como julio-1-2004; aparentemente, las fechas no solo se muestran sino que se almacenan en un orden dependiente de la ubicación. ¿Estoy bromeando ? No.

    [Nota: Filemaker 8 y 9 pueden estar cuerdos; solo he trabajado con 3 – 7.]

    Su pregunta es interesante con respecto a Perl porque su syntax está diseñada para seguir el lenguaje natural (inglés). Me pregunto si eso hace que sea más difícil para los que no hablan inglés …

    Por supuesto, Perl y Perlers se niegan a jugar según las reglas convencionales. El científico loco Damian Conway escribió el módulo Lingua :: Romana :: Perligata que utiliza la magia negra de los filtros fuente para permitirle escribir Perl en latín.

    Aquí en Australia todavía necesitamos deletrear color como color . Sin embargo, sí me resulta molesto cuando otros desarrolladores (australianos), que trabajan en un proyecto australiano, deciden que los nombres de las variables internas deben escribirse al estilo estadounidense.

    Sería inútil, en mi humilde opinión, tener una syntax de lenguaje. Simplemente mataría cualquier tipo de portabilidad.

    La única excepción son los lenguajes educativos, como LOGO. Fueron diseñados para facilitar el aprendizaje, por lo que la portabilidad no es un problema.

    Leí un montón de código, pero el problema siempre está en los nombres y comentarios de variables / métodos, si están comentando su código en su propio idioma, usando un lenguaje con caracteres especiales como el japonés o el cirílico, ¡tenemos problemas! pero las palabras clave creo que permanecerán en inglés tal como están.

    en italiano

     se (i < dimensione){ scegli caso 1: stampa "ciao" mancante: stampa "no, grazie" } altrimenti { stampa "sì, grazie" } 

    Para confirmar las preocupaciones de algunos carteles anteriores, he visto incluir un código Fortran con una macro para traducir todas las palabras clave del inglés al francés. Permítame no continuar con esto.

    También tuve que trabajar con un código que contenía identificadores simultáneamente en italiano, alemán, inglés y francés, no solo porque se desarrolló en muchos lugares diferentes, sino también porque el desarrollador principal pensó que era divertido y le ayudó a no duplicar los nombres de los identificadores ( por supuesto, con una rutina de 2000 líneas de largo ...)

    Creo que WordBasic fue localizado. WordBasic se usó para escribir macros en Word antes de usar VBA.

    Si lo recuerdo correctamente, solo WordBasic escrito en la versión en inglés se ejecutará en todas las versiones localizadas. Si escribiera una versión holandesa, solo podría ejecutarla en una palabra holandesa.