Codificación en otros idiomas (hablados)

https://stackoverflow.com/questions/202723

03-07-2019
|

Pregunta

Esto es algo que siempre me he preguntado y no encuentro ninguna mención al respecto en ninguna parte de Internet.Cuando una tienda de, digamos, Japón, escribe código, ¿podré leerlo en inglés?¿O los idiomas, como C, PHP, cualquier cosa, tienen traducciones al japonés que escriben?

Supongo que lo que pregunto es si todos los programadores del mundo saben suficiente inglés para usar exactamente las mismas palabras reservadas que yo.

¿Este código sería:

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 ahora en inglés, o alguna otra persona que no hable inglés vería las palabras "if", "switch", "case", "default", "print" y " más" en su lengua materna?

EDITAR: sí, esto es serio.No sabía si diferentes localizaciones de un idioma tienen diferentes palabras clave.o incluso si existen localizaciones diferentes.

Solución

Si entendí bien, la pregunta en realidad es: " ¿cada codificador del mundo sabe suficiente inglés para usar exactamente las mismas palabras reservadas que yo? "

Bueno ... el inglés no es el tema aquí, sino palabras reservadas del lenguaje de programación. Quiero decir, cuando comencé hace unos 10 años, no tenía ni idea de inglés, y aún así podía programar cosas simples aprendiendo el lenguaje de programación, incluso cuando no sabía lo que significaban (en inglés). De hecho, esto me ayudó a aprender inglés.

Por ejemplo. Sé hacer un & Quot; iteraci & # 243; n & Quot; (iteración, por supuesto) tuve que escribir:

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

Para mí, el " para " ;, el " ;; " y el " ++ " donde simples palabras o símbolos extranjeros. Más tarde aprendo que & Quot; para & Quot; significaba " para " y " mientras que " 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 cosas, tenía que aprender inglés, porque la documentación está escrita en ese idioma.

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

Es como la instrucción switch en bash: case .. esac. ¿Qué es & Quot; esac & Quot; ... para mí el final de la instrucción switch en bash.

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

Otros consejos

Tengo problemas para encontrar referencias, pero recuerdo tres historias.

Un hacker de Lisp defiende funciones sin sentido como " cdr " y " car " comparándolos con la programació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 ¡aunque estaba escribiendo toda la documentación en japonés! . No hubo documentación en inglés para Ruby durante un par de años, y muy pocos estadounidenses usaron el idioma. Pero ahora es un idioma de clase mundial, y el hecho de que haya nacido en Japón es solo de interés histórico. Si el idioma hubiera estado usando palabras clave en hiragana, le habría resultado mucho más difícil ganar popularidad.

Leí un ensayo una vez, tal vez alguien más pueda encontrarlo, Google no es de ayuda hoy, eso sugirió que la traducción de palabras clave fue errónea porque las palabras no son en realidad inglés, son jerga. No solo (para usar los ejemplos anteriores) para y pour no tiene el significado exacto que para tiene en inglés, para los no programadores la frase " para loop " es una tontería. Incluso los estadounidenses tienen que aprender un nuevo significado. Por lo tanto, traducir el significado superficial de las palabras a otro idioma es más como hacer un juego de palabras entre idiomas en lugar de ser realmente útil.

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 se establezca una propiedad X mediante un par de métodos getX () y setX (). Aquí en Francia-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);
}

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

Usando solo las declaraciones del 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だ:
         「もしもし。」を書く;
     省略時値:
         「いいえ、いいですよ。」を書く;
     }
} ない {
     「はい、ありがとうございます。」を書く;
}

Como ya señalaron muchas personas, en la mayoría de los lenguajes de programación solo tienes que aprender algunas palabras clave, por lo que no importa mucho si están en inglés (o en un idioma que no sea el tuyo). Es solo un símbolo que asocias con alguna construcción. Por ejemplo, en VB tienes & "; ENTONCES &"; Que en muchos lenguajes de estilo C sería & "; {&"; y no hace una gran diferencia en la legibilidad (bueno, al menos así es como lo veo, ser un hablante nativo no inglés).

Pero donde las cosas a veces pueden ponerse difíciles, y donde la elección del lenguaje (natural) importa es nombrar identificadores. Si los nombres de variables, funciones, clases, etc., no tienen un nombre significativo para usted debido a una barrera del 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 también podrían haberse llamado var_123, var_562 o func_333 (y probablemente me habría 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 breve y autónomo, utilicé un traductor en línea para dar a esos vars 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) extra justo cuando superé la barrera del idioma.

Desde entonces, he cambiado a usar el inglés para nombrar identificadores. Te guste o no, es el & Quot; koine & Quot; para programación, ingeniería y en general cosas técnicas. La mayoría de las API están escritas en inglés, al igual que la mayoría de la documentación (y probablemente los mejores recursos que puede encontrar también están en inglés). Como comentario aparte, mantiene su código más coherente con el código con el que probablemente esté interactuando, y creo que tiende a ser más compacto y conciso 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 que se comuniquen (a través del código y, por supuesto, por otros medios) será el inglés. Por lo tanto, elegir el inglés es quizás la mejor opción, aunque no sería la solución perfecta para este problema.

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

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

Sin embargo, lenguajes como Java y Perl permiten el conjunto completo de Unicode para 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 en realidad es solo eso, una broma. Nadie usa cosas como esta en serio.

Segunda actualización: la idea de lenguajes de programación localizados no es tan ridícula. El lenguaje macro de Excel está localizado, pero afortunadamente 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 & Quot; programas & Quot ;, para & Quot; real & Quot; programas se hace difícil de mantener.

En realidad ahí son alguno Lenguajes de programación no basados en inglés (Wikipedia)

Soy noruego, pero siempre he usado el inglés para todo el código, excepto para el resultado (ignorando algunos códigos tontos de la escuela).En realidad suelo escribir todo en inglés y luego traducir a mi idioma nativo, usando gettext (o algo así).

Soy británico y un problema con el que nos encontramos a menudo es el choque de ortografía estadounidense / británico. Esto ocurre a menudo con términos relacionados con la programación, como Initialise () o Initialize (), Analyze () o Analyze (), etc. Esto puede (ha) ocasionado 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 estadounidenses, descubrimos que es mejor ser coherente y utilizar la ortografía estadounidense. Incluso adoptamos Color.

Tenemos una mezcla de nacionalidades en nuestros equipos de desarrollo y la mayoría de los no británicos tienden a la ortografía estadounidense de forma natural.

AppleScript estuvo disponible en dialectos franceses y japoneses. No sé por qué fue retirado.

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

Después de ver idiomas como Brainf ** k y Espacio en blanco 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, intercambie los significados de + y -, * y /,; y: > y < ;, etc.

El concepto no es más que un compilador de C alterado con trucos. Pero, al igual que pensar en palabras clave de manera diferente, te reta a repensar algunos supuestos básicos si nunca antes has pensado en esas cosas. Ej:

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 del hecho de que las palabras clave del lenguaje de programación son aparentemente inglesas, imagino que tendría grandes dificultades para leer el código, ya que todos los nombres de funciones, variables, comentarios de códigos, tablas y columnas de bases de datos, especificaciones técnicas, protocolos, etc. Francés, incluidos esos encantadores caracteres acentuados & # 231 ;, & # 233 ;, & # 232 ;, & # 249 ;, etc. Ni siquiera estoy seguro de si el sistema funcionaría en otro lugar debido a errores de localización, como confiar en la coma como separador decimal predeterminado.

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

He visto VBA traducido a comandos similares al español. Es una de las cosas más feas jamás vistas. Me daría vergüenza tener algo como esto en mi computadora.

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

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

Sin embargo, comprender las palabras clave del idioma es solo una pequeña parte para comprender el código. Los nombres de variables, los nombres de funciones y los 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 TRS-80 BASIC incorporado para cambiar las palabras clave al francés. Podría cambiar todas las palabras clave pero no podría ampliar ninguna de ellas. Hecho para programas 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 al respecto parecía tan real y profesional (y estaba en microsoft.com). Miedo.

En el trabajo, utilizamos dos sistemas de bus de campo, ambos desarrollados en países de habla alemana, que tienen una mezcla aterradora de alemán e inglés para identificadores, incluidos algunos amigos falsos encantadores. 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í, muy temprano en mi carrera) tuvimos que detectar la versión de Office que estaba instalada en la máquina del usuario y cambiar las fórmulas utilizadas en las hojas de cálculo en consecuencia.

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

El único idioma Vi localizado Excel con sus macros.Si intentas sumar una columna usando una versión italiana de Office, debes escribir SOMMA(A1:A10) y no SUMA.Es una pena.

Por cierto, sólo porque es divertido, así es como debería verse tu código con 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 escribes algunos cálculos en una hoja de cálculo, ésta estará en tu idioma.

Afortunadamente, esta no es una práctica generalizada, e incluso las personas que no hablan inglés como yo agradecen a Dios que exista 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 mayor de lo que ya es.
Las palabras y oraciones en inglés suelen ser cortas y sintácticamente pragmáticas.En literatura, las lenguas latinas son mucho más hermosas, pero en cuestiones técnicas, el inglés es genial.

¿Y dónde parar?¿Te imaginas una C en griego antiguo?

Las palabras clave deben permanecer en un idioma, y bueno, empezó con el inglés, que siga así.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 del código internacional se mantiene congruente.

Sin embargo, existe un caso en el que utilizar nombres y comentarios de métodos en el idioma nativo puede ser una buena práctica:en un país del tercer mundo.Me voy a Senegal dentro de unos meses para gestionar un proyecto de Django.Senegal tiene una tasa de analfabetización enorme y, por lo tanto, ya es fantástico que dediquen energía a mejorar sus conocimientos de programación.El francés es el idioma nativo aquí, por lo que sería ineficaz obligarlos a aprender informática Y una nueva lengua al mismo tiempo.

Por cierto, ese sería su código con palabras clave en francés:

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

No es que traducir las palabras clave no tenga nada que ver con traducir las cadenas.Por supuesto, tenemos "hola" traducido a nuestro idioma.Los codificadores europeos incluso tienden a utilizar I18N mucho más que los estadounidenses, por lo que su servicio puede llegar a un público más amplio.

En términos generales, la mayoría de los programadores se adaptan a la forma en inglés. Aprendí a programar cuando tenía 7 años y solo hablaba hebreo (de derecha a izquierda) y sin inglés, lo que lo convirtió en una experiencia bastante fascinante.

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

El único idioma con el que estoy familiarizado y que realmente se tradujo fue un buen logotipo antiguo (aún increíble 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 te mostraba cómo escribir programas de computadora. El lenguaje era algún tipo de variante BÁSICA y lo recuerdo claramente usando POUR en lugar de FOR, y así sucesivamente. ¡Tenía 7 años y acababa de aprender BASIC, 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 script de Filemaker está localizado. Los scripts (¡y los datos!) Se almacenan en un terrible & Quot; más o menos canónico & Quot; formulario.

Entonces, si escribe un script en la versión estadounidense, luego lo abre en la versión francesa, todas las palabras clave y los nombres de las funciones incorporadas estarán en francés. ¿Pero por qué no corre? ¡Ajá! La versión francesa usa & Quot;, & Quot; como punto decimal y, por lo tanto, para evitar ambigüedades, use " ;; " para separar argumentos de funciones, donde la versión estadounidense usa ". " y ", " respectivamente. Esta conversión la tienes que hacer tú mismo.

Entonces 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 todas estas cosas. ¡Corre! ¡Excelente! ¡Los resultados están todos equivocados! ¡Oh no! ¡Ajá! La fecha del 7 de enero de 2004 que ingresó en la versión estadounidense se interpreta como del 1 de julio de 2004, aparentemente las fechas no solo se muestran sino que se almacenan en orden dependiente de la localidad. ¿Te estoy tomando el pelo ? No.

[Nota: Filemaker 8 y 9 pueden ser razonables, solo trabajé con 3 - 7.]

Su pregunta es interesante con respecto a Perl porque su sintaxis 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 Lingua :: Romana :: Perligata módulo ¡que usa la magia negra de los filtros fuente para permitirte escribir Perl en latín!

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

No tendría sentido, en mi humilde opinión, utilizar una sintaxis de idioma . Simplemente mataría cualquier tipo de portabilidad.

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

Leí mucho código, pero el problema siempre está en los nombres de variables / métodos y comentarios, si están comentando su código en su propio idioma, usando un idioma con caracteres especiales como japonés o cirílico, ¡estamos en problemas! pero creo que las palabras clave 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 algún póster anterior, he visto un código Fortran con una macro incluida 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 simultáneamente identificadores 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 lo ayudó a no duplicar nombres de 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 quisieras escribir una versión holandesa, solo podrías ejecutarla en una palabra holandesa.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow