Chapter 15: Notas de traducción

Notas de traducción

Traducción de terminología especializada

  • Es muy común en la literatura técnica y especialmente en el caso de la programación para internet, el uso de terminología específica y neologismos que, o bien no tienen una traducción directa, o su traducción típica para otras clases de textos resultaría ambigua. Entre otros casos se pueden mencionar el término serialize y sus derivados (serialization, serialized, ...), tutorial, indentation, o typed. Para estos casos hemos optado frecuentemente por el uso de neologismos análogos para el idioma español (por ejemplo, serializar para el caso de serialize), teniendo en cuenta que esta técnica permite evitar la construcción de frases ambiguas que dificultarían la lectura y además seguir la costumbre generalizada para la escritura de textos especializados de informática.
  • Para los términos cuya traducción es vaga o no hemos podido encontrar una expresión adecuada en español, en general se agregó el término original del idioma inglés entre paréntesis.
  • Escaping, escape, y otras palabras especiales se han traducido como escapar. http://en.wikipedia.org/wiki/Escape_character
  • Para frases como response body se optó por la traducción directa (para este caso el cuerpo de la respuesta) en lugar de referir a los objetos de la API, que son fácilmente identificables. De otra forma hubiese sido necesario usar el body de la response o el response.body.
  • Render se traduce frecuentemente como convertir o conversión y según lo requiera la frase, como procesar o procesamiento.
  • Named arguments (del lenguaje Python): se ha traducido como pares nombre-valor o pares de argumentos de nombre-valor
  • El identifier de Python se traduce como nombre
  • Palabras como callback se conservan en el original, porque no se encontró una traducción convencional, salvo, para este ejemplo, el uso de llamada de retorno, que en algunas situaciones puede resultar confuso.
  • El verbo link <algo> para el embebido de script o style en un documento web (que posiblemente no tenga al día de hoy una traducción) se cambió por el término poco ortodoxo pero mucho más familiar, linkear.
  • Para elementos HTML se prefirió usar la traducción literal hijo (child), en lugar de anidado. La razón es que cualquier elemento contenido en otro se puede clasificar como anidado, pero los hijos, si se toma como referencia la estructura de un documento web, son aquellos que descienden de un elemento específico.
  • Layout se traduce como Diseño o se mantiene el original en caso de hablar de la estructura de vistas, para conservar la nomenclatura para archivos utilizada en la aplicación de andamiaje welcome. (layout.html)
  • Para factory (por ejemplo helper factory) se usa el término creador, en lugar de la traducción literal factoría, que es confusa.
  • Se utilizó agregado para plugin en el título, según la traducción de la tercera edición, pero nótese la ambigüedad del uso:

...Debes instalar el agregado.... Un agregado puede ser un simple widget, validador o archivo estático, o un plugin. En el texto se prefiere el término original en inglés por su precisión y brevedad (aunque no existe como término del español). Quizás lo más adecuado sería castellanizarlo usando plugín, pero en este caso podría resultar de difícil comprensión.

  • Slug se traduce como titular por su semejanza con el término utilizado para títulos de periódicos
  • Verbatim text es traducido según el significado utilizado en trac (texto sin conversión)
  • Deployment se tradujo como implementación para mantener la coherencia con la versión anterior, aunque la traducción no es precisa. En algunas oraciones se utilizó la traducción literal desplegar. En el capítulo 13 se prefirió el uso de despliegue para referirse a la instalación en producción en los distintos sistemas de alojamiento.
  • Master-slave no se traduce, por no haberse encontrado una traducción ampliamente utilizada.
  • Para los formularios self-submited, a falta de una traducción comúnmente adoptada, se utilizó autoenviados. Otra traducción menos literal sería autoreferentes, pero también puede dar lugar a confusiones.
  • A falta de una traducción para subsection, se reemplaza simplemente por sección.
  • Label se ha traducido como etiqueta en lugar del (quizás más apropiado) rótulo, porque este último término es poco usual.
  • Deprecated se tradujo como obsoleto/a.
  • Self-identifying para algoritmos se tradujo como diferenciable, ya que se trata de un algoritmo que se puede separar del conjunto y sustituir. (ver Cap. 07 en descripción del validador CRYPT)
  • Back end (de base de datos) es traducido como servicio, aunque un database back end puede no ser un servicio. En el libro en inglés se utiliza database back-end tanto para referirse a motores de bases de datos como a una instalación de una base de datos concreta. Para el primer caso se usó motor y para el segundo servicio.
  • Join: La traducción como junta encontrada en ArPug (usuarios de PostgreSQL) no se adoptó en otros textos, por lo que se conserva el nombre original.
  • Multi-tenant y multi-tenancy no tienen una traducción convencional y se reemplazaron por aplicaciones compartidas, porque esta definición es acorde al significado de esos términos para su uso en web2py.
  • Request se tradujo como solicitud, en lugar del término más usado petición. Esta convención se podría modificar en caso de que solicitud resulte confuso o inapropiado.
  • El Dispatcher se traduce como administrador de direcciones, para ilustrar su funcionalidad (también se podría traducir como despachador o despachante).
  • logging se traduce como historial, siguiendo un artículo anónimo en wikipedia con esa traducción, a falta de una traducción autorizada.
  • Para traducir framework se utilizó marco de desarrollo, igual que para la 3a edición (Latinux).
  • Traducción de ejemplos de código fuente: En el caso de uso de variables típicas de la aplicación de andamiaje se conservaron los términos en inglés para que el código mantenga su funcionalidad al ejecutarlo (es decir, para que no se produzcan errores al interactuar con funcionalidades de la aplicación de andamiaje o incluso con funciones del núcleo que esperan definiciones de nombres específicas). Un caso típico es el de index, la función de inicio por defecto del controlador default.py. Para términos convencionales que no requieren un cambio de las variables específicas de la app welcome, se prefirió el uso de su traducción para una mejor legibilidad (salvo casos en los de algunos nombres cuya abreviación coincide con la abreviación del español, como concat). Por ejemplo, los objetos row y form, se han traducido como registro y formulario.

Acerca de los nombres de argumentos

En los ejemplos de funciones incorporadas que aceptan argumentos posicionales, las traducciones pueden generar conflictos en ciertas implementaciones de los ejemplos. Esto se debe a que el signature o lista de argumentos aceptados de una función especifica argumentos de tipo positional-or-keyword. En cada ejemplo a implementar en producción se deberían sustituir los parámetros traducidos por sus originales en inglés. Por ejemplo, para el caso de la palabra query:

salida = nombre_de_funcion(consulta, ...)

Se debería reemplazar por

salida = nombre_de_funcion(query, ...)

Esto evitará, por ejemplo, que al trabajar en colaboración con otros desarrolladores, no se intente utilizar el comando análogo (pero incompatible con la definición de la función):

salida = nombre_de_funcion(consulta=db.tabla.id > 0)
 top