"Es mejor no leer en absoluto que eso".¿Lees a menudo literatura técnica? ¿Es literatura, y no manuales en el centro o informes de errores en el github? Y cuando lees, ¿en qué idioma prefieres hacer esto (si puedes elegir, por supuesto)? ¿Qué versión prefieres, en ruso o en inglés?
En algunos círculos, hay una opinión tan presuntuosa y elitista de que leer (ver una película, jugar juegos) solo está en el idioma de Shakespeare y nada más. Para muchos otros, es bastante difícil verificar el primero sobre el tema de si son simplemente arrogantes o si hay algún problema serio con la literatura técnica traducida. Trillado debido a las malas habilidades del lenguaje en el original.
Otra complicación es agregada por el área de conocimiento en torno a la cual todo esto sucede. A menudo no es fácil reconocer una frontera donde un malentendido de estructuras de datos complejas o nuevas metodologías de desarrollo entra en un malentendido del texto que compuso el traductor. Aquí, por ejemplo, hay una cita de un libro bastante reciente:
En la escuela secundaria, comenzó a crear sitios web dinámicos cuando Internet todavía era relativamente joven. Luego pasó a desarrollar software para la industria de la salud y las telecomunicaciones en una empresa local, estudiando informática en la Universidad de Ljubljana, Eslovenia. Al final, pasó a trabajar en Red Hat, desarrollando inicialmente la implementación de código abierto de la API de Google App Engine, que utilizaba productos Red Hat JBoss de nivel medio. También trabajó o participó en proyectos como CDI / Weld, Infinispan / Jboss DataGrid, etc.
Desde finales de 2014, ha formado parte del equipo de Red Hat Cloud Enablement, donde sus responsabilidades incluyen actualizar nuevos desarrollos en Kubernetes y tecnologías relacionadas y maximizar el potencial de Kubernetes y OpenShift en software de nivel medio.
Si no se ha enfermado por el pasaje "inicialmente desarrollando una implementación de código abierto de la API de Google App Engine", entonces probablemente tenga preguntas sobre qué tipo de "empresa de nivel medio" surgió de repente. O lo que, por ejemplo, significa "actualizar nuevos desarrollos". Pase al texto original:
Desde finales de 2014, ha formado parte del equipo de Red Hat's Cloud Enablement, donde sus responsabilidades incluyen mantenerse actualizado sobre los nuevos desarrollos en Kubernetes y tecnologías relacionadas y garantizar que el software de middleware de la compañía utilice las características de Kubernetes y OpenShift en todo su potencial. .
Resulta que, de hecho, esta no es una empresa de nivel medio. Y estamos hablando del middleware de la empresa. Y nadie lo obligó a "actualizar nuevos desarrollos"; de hecho, necesita estar constantemente informado de todos los nuevos desarrollos.
O otro ejemplo, de otro libro:
En 2007, contacté a ejecutivos de Yahoo acerca de una posición relacionada con "un poco de desarrollo" y "un poco de explotación". Se trataba de la vacante de un ingeniero de servicio superior responsable de crear y mantener un almacén de datos de clave / valor multiempresa, alojado, distribuido y replicado geográficamente llamado Sherpa.
“Un almacén de datos multiempresa, alojado, distribuido y replicado geográficamente”: ¿puede comprender de inmediato qué es exactamente este lío, o primero tendrá que traducirlo nuevamente al inglés para darse cuenta de qué términos familiares estaban localizados con tanto glamour para los grandes y poderosos?
¿Ayuda esto al aprendizaje simple? Honestamente, no realmente. ¿Desea gastar dinero considerable, en general, en una densa jungla lingüística, en cuyas profundidades hay una cabaña con preciadas tabletas de arcilla? No quiero Me gustaría otro: tener acceso a un conjunto de textos simples y comprensibles, la parte más difícil de las cuales serían las ideas presentadas por el autor, y no construcciones de lenguaje extraño construidas por el traductor.
Tratando de averiguar por qué sucedió
Como sucedio ¿Siempre ha sido así? ¿Podemos de alguna manera evitar tales incidentes en el futuro? Sugeriría dejar las preguntas de bajo nivel de competencia lingüística fuera del alcance de esta discusión, porque no podemos influenciarlo directamente. Solo hay buenos traductores, pero no muy buenos. Como programadores. Y los dentistas. Y en general, cualquiera.
Pero, ¿qué dificultades adicionales enfrentan los bilingües, incluso con una gran comprensión en ambos idiomas, cuando deciden comenzar a traducir literatura de TI? La tecnología de la información en los últimos 10-15 años ha crecido enormemente, tanto horizontal como verticalmente. Un gran número de nuevas profesiones, cada una con su propia especialización. Debido a la inercia lingüística de la percepción humana, muchas profesiones relacionadas usan los mismos términos, que, sin embargo, tienen diferentes significados. Y para comprender cómo usar y traducir adecuadamente un término en particular, no solo necesita un buen dominio del idioma, sino también una buena comprensión de un área específica y subsecciones de la industria de la información.
En términos generales, al mismo tiempo que la forma universal del "programador" (que eleva el servidor y escribe el script, y el conder en la placa base para volver a soldar) dejó de existir, el "traductor técnico" universal también dejó de existir. Por lo tanto, ahora no es suficiente ser "solo un traductor". Sería bueno ser, en primer lugar, un especialista técnico que, además, domina los idiomas. Y esta, como saben, es una historia completamente diferente. No todos los buenos especialistas técnicos tienen suficientes habilidades lingüísticas. Y si lo hacen, está lejos de ser siempre interesante para ellos participar en este tipo de trabajo: se sienten más atraídos por los logros técnicos que por los humanitarios.
"Y antes, antes, ¡qué bueno fue!" (c)
La metodología de "traducir" nuevas palabras ahora está muy extendida simplemente sustituyendo el inglesismo existente. Por ejemplo, commit (la "fijación" de traducción más o menos normal ya está desplazada en casi todas partes), compilar, implementar: la lista se puede mantener sin fin. Lo más probable es que esta situación se haya desarrollado debido al ritmo acelerado de la aparición de nuevas tecnologías. La traducción, como cualquier otro sistema reactivo, simplemente no puede seguir el ritmo dado. Y para cuando cualquier texto llegara a ser traducido por profesionales, los técnicos ya habían formado una jerga profundamente arraigada, y la traducción del término "cometer" con la palabra "fijación" dañaría los ojos del lector.
¡Pero esto no significa en absoluto que uno deba soportar una situación similar! Hay excelentes ejemplos de traducción de alta calidad y bien pensada. De los ejemplos podemos tomar "hilo" - "hilo". La traducción literal - "hilo" - sugiere que, muy probablemente, al comienzo de la formación de la terminología inglesa, era una asociación con un telar con un montón de hilos estirados en paralelo. En el idioma ruso, la "ejecución de múltiples hilos" suena muy incomprensible, pero la "ejecución de múltiples hilos" es un asunto completamente diferente. Aquí se conserva la semántica, porque el flujo es un movimiento constante (cálculo), que el hilo no tiene. Y suena bastante familiar ("los automóviles se mueven en varias corrientes a lo largo de la autopista").
Otro ejemplo de un término bien localizado es "tubería" = "tubería". "Tubería" es una tubería, la esencia del término (tubería de representación, tubería CI / CD) es el proceso de procesamiento, donde se lleva a cabo alguna acción en cada nodo: según las condiciones, las "válvulas" se pueden cerrar y abrir y el procesamiento se realiza a través de otro " la pipa ". A lo largo de toda la tubería, se puede colocar algún tipo de "sensores" que supervisan el proceso. La palabra se eligió muy bien, pero la traducción directa, "canalización de representación" no suena lo suficientemente concisa. "Transportador" en este caso es una palabra perfectamente coincidente, excepto con un tono diferente (transmitir - transmitir, pero "fluye por sí mismo" a través de tuberías), pero sin perder el significado principal.
¿Cómo vivir más?
¿Qué ofrecemos por nuestra parte? Ofrecemos la fusión única de competencias técnicas con habilidades lingüísticas de calidad. Estamos listos para dedicar tiempo a nuestros especialistas técnicos para que el contenido semántico de los textos traducidos se encuentre en perfecto estado.
En el proceso de trabajar en las traducciones, tenemos que pasar mucho tiempo en discusiones sobre el tema de cómo localizar ciertos términos. A este respecto, sería bueno comenzar a compilar un glosario común de nueva terminología, para su uso posterior tanto en nuestras propias traducciones como en las de nuestros colegas. Este glosario no debe ser solo una colección de palabras; En primer lugar, se le pide que explique por qué se eligió ese término, por qué es mejor que otros similares, cómo encaja en el contexto del lenguaje, bueno, y nuestra tradición técnica. Sin rastreo ciego e irreflexivo de terminología extranjera.
Este es el glosario que planeamos hacer. Para empezar, aparentemente, esta será una serie de artículos con una descripción general de las colecciones de términos, la historia de su aparición y desarrollo, así como los objetos detrás de ellos. Posteriormente, cada libro de
nuestra editorial tendrá una sección separada que describe cómo trabajamos en la terminología utilizada en este libro. A medida que se recluta el material, es probable que se publique una publicación por separado sobre los problemas del idioma ruso en la traducción moderna de tecnología de la información. Mientras tanto, puede
preordenar nuestro primer libro, "Diseño de sistemas orientados a eventos", de Ben Stopford.
¿Y qué piensa sobre la situación en la literatura técnica traducida? ¿Hay algún término que sea especialmente querido para el corazón y que, en su opinión, se haya traducido perfectamente al ruso? ¿O tal vez hay odiados especialmente? :)