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
Attachment:
signature.asc
Description: This is a digitally signed message part.