Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pautas de Traducción #1

Open
miljan-aleksic opened this issue Dec 5, 2016 · 22 comments
Open

Pautas de Traducción #1

miljan-aleksic opened this issue Dec 5, 2016 · 22 comments

Comments

@miljan-aleksic
Copy link

miljan-aleksic commented Dec 5, 2016

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

@miljan-aleksic miljan-aleksic changed the title Términos a usar Definición de Términos Dec 5, 2016
@miljan-aleksic miljan-aleksic changed the title Definición de Términos Pautas de Traducción Dec 6, 2016
@llops
Copy link

llops commented Dec 18, 2016

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
Copy link

llops commented Dec 18, 2016

@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
Copy link
Author

miljan-aleksic commented Dec 18, 2016

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
Copy link

zgudino commented Dec 18, 2016

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
Copy link
Author

miljan-aleksic commented Dec 19, 2016

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

@llops
Copy link

llops commented Dec 19, 2016

@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
Copy link
Author

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
Copy link

llops commented Dec 19, 2016

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
Copy link

llops commented Dec 20, 2016

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
Copy link

llops commented Dec 20, 2016

Throw error - Lanzar un error / Genera un error

@llops
Copy link

llops commented Dec 20, 2016

To handle - Manejar

@zeratulmdq
Copy link

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.

@miljan-aleksic
Copy link
Author

miljan-aleksic commented Jan 30, 2017

@zeratulmdq, parece que estos días vamos todos superliados... siento la tardanza y gracias por tu colaboración.

Me parece bien usar notas del traductor según sea necesario. En cuanto a los nuevos términos:

  • Standalone - Autónomo en España tiene el significado de persona que trabaja para sí mismo. Aunque se pueda emplear en otros sectores, me parece mejor traducirlo como independiente.
  • Module bundler & Build - Habría que indagar en como lo traducen en otros documentos técnicos, si no los dejamos como no traducibles.
  • Single file component, Libraries, Template & Frontend - Me parecen bien tus propuestas.

@llops, qué opinas?

@jstoledano
Copy link

¿Qué se hace con la metadata, se traduce o no? El título supongo que si, pero el type no lo tengo claro. Realmente type no lo usa Hexo como categorías, porque en general, la documentación usa alias para las URL.

En el documento que me tocó traducir se ve:

---
title: Template Syntax
type: guide
order: 4
---

Sería conveniente establecer una directiva en este aspecto.

@miljan-aleksic
Copy link
Author

miljan-aleksic commented Mar 8, 2017

Traduzcamos solamente lo visible a cara al usuario. He actualizado el CONTRIBUTIONS.

@tochoromero
Copy link

Hola, no estoy seguro como traducir raw properties.
Quizá se puede traducir como propiedades puras, pero no estoy seguro. La traducción literal, propiedades crudas, no tiene mucho sentido.

¿Alguna sugerencia?

@miljan-aleksic
Copy link
Author

Quizás propiedades sin alterar.

@miljan-aleksic
Copy link
Author

@juansaab, @rgomez90, @UchihaCFC, comentar por aqui cualquier termino con el que tengais dudas.

@rgomez90
Copy link

Otro término sobre el que debemos decidir es assert.

@miljan-aleksic
Copy link
Author

@rgomez90, que opciones tenemos?

@rgomez90
Copy link

La palabra significa afirmar/comprobar. La RAE contempla el término aserción así que traducción hay.
Yo usaría los tres terminos dependiendo del contexto. No traducirlo no me parece buena idea, ya que resultaría en frases muy "raras" según el caso.

@miljan-aleksic
Copy link
Author

Podrias poner ejemplos de los diferentes contextos y tu recomendacion en cada?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants