Pautas de Traducción

[miljan-aleksic]

Abro este ticket para ir estableciendo los términos correctos a usar según vayamos traduciendo. Surgirán dudas sobretodo con términos técnicos para los cuales la traducción en Español puede resultar extraña, pero no necesariamente incorrecta. Por ejemplo en la traducción que hice de Vuex 1, el término store traducido como almacén me pareció raro, pero al definirlo desde el principio y usarlo consistemente me pareció correcto.

No tengo mucha experiencia con traducciones técnicas o programando en Español, por lo que espero que entre todos podamos definir la mejor traducción. Según surgan las dudas, exponedlas y cuando las aclaremos las marcamos como referencia.

Resumen Pautas

Las pautas han sido movidas al Wiki

[llops]

Antes de lanzarnos con la traducción, me parece importantísimo definir mejor y enriquecer este apartado, ya que el español es un idioma especialmente delicado para traducir. Así que propongo una discusión sana para lograr un marco donde todos nos sintamos cómodos, y sobretodo lograr una documentación coherente y que no varíe excesivamente de un apartado a otro.

Sobre el español

El elemento más "conflictivo" cuando se hacen traducciones en español suele darse con las palabras y construcciones que utilizamos en nuestro propio país. Estamos tan acostumbrados a ellas que nos parece increíble que en otros lugares suenen raro o no se entienda directamente. Por contra, tenemos a favor que a diferencia de la lengua hablada, el idioma escrito está libre de la musicalidad y la entonación de cada región, y de fallos dialectales (seseo, ceceo, laísmo...) interiorizados en nuestra forma de hablar.

Así que como primer punto fundamental, deberíamos utilizar la forma culta de la lengua y evitar escribir como hablamos normalmente.

También hay que tener cuidado con los modismos y las palabras propias de cada territorio, que muchas veces están aceptadas por la RAE pero fuera de dicho territorio no se entienden.

Y aunque obvio, recordar que hay que acentuar correctamente todas las palabras, y que los signos de admiración e interrogación se utilizan también al principio de la frase.

Documentación técnica

La terminología utilizada es esencial, ya que afecta en gran medida a la calidad de la traducción. Hay que definir los términos más importantes y más utilizados y ceñirse a ellos. Por poner un ejemplo, no deberíamos utilizar ordenador, computadora y PC simultáneamente.

Como comenta Miljan en el ejemplo de almacén <=> store, yo también me inclino por utilizar el término en inglés en conceptos clave, ya que la gran mayoría de usuarios de este tipo de frameworks están bastante familiarizados con ellos.

Pero hay que diferenciar bien entre término (la palabra en sí) y la oración. Hay que evitar ceñirse literalmente a la traducción inglesa, ya que esto genera redacciones poco naturales en nuestro idioma.

Traducción español-inglés

Por diferencia lingüística, solemos cometer errores frecuentes al traducir entre idiomas.
Dejo como referencia esta guía de la GNU en la que se detallan muchos de ellos:
https://www.gnu.org/server/standards/translations/es/recomendaciones.html

También añado otra de Debian, más general, y que abarca algunos de los puntos que he ido comentando:
https://www.debian.org/international/spanish/notas

Revisores

Por último, cualquier proceso de traducción necesita revisores, que corrijan, unifiquen e integren todo el trabajo. Entiendo que Miljan será uno de ellos. Yo también me ofrezco si lo consideráis oportuno.

Aunque sea tedioso, si hacemos una doble revisión por cada apartado tendremos una documentación de mayor calidad.

[llops]

@miljan-aleksic, para empezar, yo tengo mi primera gran duda con esto:

Tutea. Ejemplo: inicia la... en vez de inicie la....

Al igual que tú, por el hecho de ser de España, estoy más acostumbrado y prefiero el tuteo a la tercera persona, pero creo que en el resto de países suena peor. Además, en la mayoría de guías y libros técnicos estoy acostumbrado a ver el usted. Como dice la guía de "Debian" que he pasado:

Tratamiento al lector: Excepto casos contados, ha de tratarse al lector siempre de usted. Por ello se traducirá 'you' por usted, no por tú. Esta fórmula se utiliza para dar un trato formal al lector.

¿Qué os parece al resto?

[miljan-aleksic]

Gracias @llops, excelente aportación!

• Viendo que usar la tercera persona es recomendado, me parece bien hacer el cambio.
• Sí, se harán revisiones antes de aceptar el PR. Estás más que bienvenido a sumarte.
• En cuanto a usar términos en Inglés, podrías poner un ejemplo de cómo usarías el Store en una frase?

[zgudino]

Buena redacción @llops ! 👍

Esta de mas decir que debemos evitar traducir los ejemplos de la documentación original. Ejemplo,

Incorrecto

Vue.config.optionMergeStrategies._mi_opcion = function (padre, hijo, vm) {
    return hijo + 1
  }

const Perfil = Vue.extend({
  _mi_opcion: 1
})

Correcto

Vue.config.optionMergeStrategies._my_option = function (parent, child, vm) {
    return child + 1
  }

const Profile = Vue.extend({
  _my_option: 1
})

Sobre almacén <==> store concuerdo con @llops, es un patron muy utilizado sea el lenguaje que sea.

Finalmente, hehehe, @miljan-aleksic crei tutear es como íbamos a dirigirnos a los lectores 😝

Saludos!

[miljan-aleksic]

@zgudino, tienes razón y personalmente lo prefiero, pero @llops ha dado unas bases solidas que no puedo ignorar :D

[llops]

@miljan-aleksic
En cuanto a usar términos en Inglés, podrías poner un ejemplo de cómo usarías el Store en una frase?

No es un tema sencillo, porque al final es muy opinable, pero aquí van algunos ejemplos para que discutamos :)

---

It serves as a centralized store for all the components in an application

Se utiliza como un almacén (store) centralizado para todos los componentes de la aplicación

Since Vuex stores are reactive, the simplest way to "retrieve" state from it is simply returning some store state from within a computed property:

Dado que los stores de Vuex son reactivos, la forma más fácil de obtener el estado es simplemente devolver algún estado del store desde una propiedad computada.

Whenever store.state.count changes, it will cause the computed property...

Siempre que store.state.count cambie, causará que la propiedad computada...

---

Mi opinión es que la mayoría de veces términos como store, state, mutation, etc. se utilizan prácticamente como nombres propios. Si acostumbramos al usuario al término en inglés, cuando lea en el código store.xxx.xxx la asociación es inmediata. Cualquier palabra no traducida iría en cursiva.

Por contra, en el primer párrafo (Se utiliza como un almacén (store) centralizado...), el término almacén me parece correcto, porque es genérico, aunque como veis aprovecharía para poner entre paréntesis la palabra original, para ir familiarizando.

El 100% de lo dicho vale por ejemplo para state o computed property, aunque al final nos pueden quedar frases tan tediosas como:

Dado que los stores de Vuex son reactivos, la forma más fácil de obtener el state es simplemente devolver algún state del store desde una computed property (propiedad computada).

Encontrar el equilibrio va a ser difícil, pero en cierta manera creo que sacrificar "pureza" por acercarnos a la terminología inglesa va a ser más beneficioso para el entendimiento del lector. Y al final es de lo que se trata, ¿no?

¿Qué opináis vosotros?

[miljan-aleksic]

Estoy deacuerdo en que algunos términos son más fáciles de entender usando la expresión original, como store pero yo sí traduciría los términos que son naturales de usar traducidos, ejemplo state y computed property. Ello conseguría el mencionado equilibrio:

Dado que los stores de Vuex son reactivos, la forma más fácil de obtener el estado es simplemente devolver algún estado del store desde una propiedad computada.

[llops]

Perfecto. Si quieres, con cada PR podemos evaluar si existen este tipo de términos que es mejor no traducir e irlos incorporando al post inicial de "Resumen Pautas"

[llops]

To merge - Fusionar

Es la traducción más frecuente y la que se emplea en la guía oficial de Git. Ejemplo:

Basic Branching and Merging
Procedimientos básicos para ramificar y fusionar

[llops]

Throw error - Lanzar un error / Genera un error

[llops]

To handle - Manejar

[zeratulmdq]

Primero, creo que es importante recordar que:

• libraries - bibliotecas.

Por lo menos en Argentina es muy común traducirlo por "librerias". Por otro lado, creo que también sería conveniente agregar notas del traductor. Aunque no escribamos explicitamente Nota del traductor o N. de T. hay casos en los que es necesario. Por ejemplo:

...such as Google Chrome Apps, enforce Content Security Policy (CSP)...

quedaría bien traducirlo como (notar negritas):

... tales como las aplicaciones de Google Chrome, imponen las Politicas de Seguridad de Contenido (CSP por sus siglas en inglés)

Punto aparte, como traducirían las siguiente lineas? Sobre todo porque creo que nunca las use en español y puede que lo que tenga en mente sea diferente a como lo llamarían en otros lugares. Creo que son cosas que van a aparecer en varios lugares y me gustaría que nos pongamos de acuerdo para unificar criterios.

• Standalone - Autonomo
• Module bundler - Empaquetador de módulos
• Single file component - Componentes de un sólo archivo
• Template - Plantilla
• Build (sustantivo y verbo) - ??? Apunto a algo como runtime-only build para un sustantivo. Como verbo creo que construir no estaría mal, pero no me convence realmente.
• Frontend - Lo dejaría en inglés

Cuando resuelva estas dudas hago el PR.