[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Traducciones sobre temas espcíficos



Pues si la traducción no se puede realizar, por el motivo que sea, se pone «así» y listo.

Noel David Torres Taño escribió:
On Jueves 09 Septiembre 2010 10:26:56 Camaleón escribió:
El Thu, 09 Sep 2010 11:12:20 +0200, Fernando Cerezal escribió:
El día 8 de septiembre de 2010 23:11, Camaleón escribió:
Si no estáis seguro de lo que estáis traduciendo, mejor no traducirlo.
Los traductores tenemos que tomar decisiones, a veces son acertadas y
otras no tanto. Para las decisiones "desafortunadas" que tomamos (los
traductores no somos expertos en todas las materias de todos los campos
científicos, tecnológicos o industriales existentes) está esta lista
Esta lista está para cosas lingüísticas, pero no creo que nadie pueda
hablarte sobre la Teoría del Funcional de la Densidad.
Esta lista es para discutir sobre la correcta terminología que se debe
utilizar en las traducciones, nadie ha dicho que se debata sobre el
estado del tiempo sino sobre términos lingüísticos.

Sí, pero no es aquí donde discutimos sobre términos lingüísticos específicos a un campo, por la sencilla razón de que no sabemos. Yo, como astrofísico, prefiero los programas de astrofísica en inglés, porque las traducciones me lían (y eso que sé qué debería hacer el programa). ¿Cómo traducirías tú 'dark current' o 'flat field'?
y
también el sistema de bugs (BTS) donde se puede indicar qué fallos
existen en las traducciones así como sugerir alternativas.
Pero si un experto en tecnología de polímeros ve una mala traducción, va
a pensar que no puede fiarse de ninguna traducción y lo mirará todo en
inglés, aparte de avisar a todos sus conocidos de que no se fíen de las
traducciones.
No creo que ese sea un enfoque adecuado. Ese experto tiene que saber que
las traducciones de proyectos libres (al menos las que yo conozco y en
las que he participado) las llevan a cabo gente que viene de distintos
campos, no son traductores profesionales y hacen lo que pueden y lo mejor
que pueden.

Probablemente ni siquiera sea consciente de que es un proyecto libre: para él no es más que una herramienta de trabajo, y si la herramienta le causa problemas, no le sirve. Punto y pelota.
Si algo está mal, se debe corregir, esto es un proyecto colaborativo. Si
el traductor del paquete está en esta lista, pues lo lógico es que se le
dé solución aquí. Como último recurso siempre está el BTS.

«Si algo está mal, se debe corregir» es la regla número 2. La regla 1 es «No causar más problemas de los que se solucionan», o equivalentemente, «No desperdiciar trabajo»
En rara ocasión se irá a la versión original, la traducirá, buscará el
paquete en cuestión, enviará el aviso de fallo y demás..
No tiene por qué hacerlo, sólo tiene que avisar y recomendar un
traducción mejor.

No va a hacerlo, es tan simple como eso. Los usuarios no tienen obligación de colaborar con nosotros, simplemente se quejarán entre colegas y, como decía Fernando, usarán el programa en inglés o lo abandonarán.
Si son temas muy específicos, casi seguro que quien lo vaya a usar sabe
inglés, así que no pasa nada porque se tarde más en traducirlo.
Y a todo esto, ¿de qué cadena/mensaje/paquete estamos hablando? Creo que
aún no has comentado nada así que no sé cómo podremos corregirlo.

Ahí sí estoy contigo. De todos modos tener que corregir malas traducciones es la CONSECUENCIA de que se hayan hecho malas traducciones.

Un saludo a todos

Noel
er Envite


Reply to: