-
Notifications
You must be signed in to change notification settings - Fork 29
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
Comments
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ñolEl 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écnicaLa 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 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ésPor diferencia lingüística, solemos cometer errores frecuentes al traducir entre idiomas. También añado otra de Debian, más general, y que abarca algunos de los puntos que he ido comentando: RevisoresPor ú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. |
@miljan-aleksic, para empezar, yo tengo mi primera gran duda con esto:
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:
¿Qué os parece al resto? |
Gracias @llops, excelente aportación!
|
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 Finalmente, hehehe, @miljan-aleksic crei tutear es como íbamos a dirigirnos a los lectores 😝 Saludos! |
No es un tema sencillo, porque al final es muy opinable, pero aquí van algunos ejemplos para que discutamos :)
Se utiliza como un almacén (store) centralizado para todos los componentes de la aplicación
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.
Siempre que 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 Por contra, en el primer párrafo ( El 100% de lo dicho vale por ejemplo para state o computed property, aunque al final nos pueden quedar frases tan tediosas como:
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? |
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:
|
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" |
To merge - Fusionar Es la traducción más frecuente y la que se emplea en la guía oficial de Git. Ejemplo:
|
Throw error - Lanzar un error / Genera un error |
To handle - Manejar |
Primero, creo que es importante recordar que:
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:
quedaría bien traducirlo como (notar negritas):
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.
Cuando resuelva estas dudas hago el PR. |
@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:
@llops, qué opinas? |
¿Qué se hace con la metadata, se traduce o no? El título supongo que si, pero el En el documento que me tocó traducir se ve:
Sería conveniente establecer una directiva en este aspecto. |
Traduzcamos solamente lo visible a cara al usuario. He actualizado el CONTRIBUTIONS. |
Hola, no estoy seguro como traducir ¿Alguna sugerencia? |
Quizás |
@juansaab, @rgomez90, @UchihaCFC, comentar por aqui cualquier termino con el que tengais dudas. |
Otro término sobre el que debemos decidir es assert. |
@rgomez90, que opciones tenemos? |
La palabra significa afirmar/comprobar. La RAE contempla el término aserción así que traducción hay. |
Podrias poner ejemplos de los diferentes contextos y tu recomendacion en cada? |
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
The text was updated successfully, but these errors were encountered: