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

Re: [RFR] wml://devel/tech-ctte



El jue, 30-09-2010 a las 21:48 +0200, Javi Taravilla escribió:
> Hola de nuevo Fernando.

Hola Javi

> Entregado estoy a tus investigaciones técnicas para la traducción de
> los 4 Bugs de la web de tech-ctte, por ser precisas y por ofrecer la
> información necesaria para la mejor comprensión del fallo o, al menos,
> para averiguar con mayor facilidad de qué trata cada uno. Se puede
> seguir la discusión pichando en el link pero, si ofrecemos mejor y
> mayor info en su presentación, será mejor para las personas
> hispanohablantes que interesadas en el tema, :).
> 
> Sólo que en el 4º bug...(sigue abajo)...
>         
>         
>         
>         <li>2009-07-25 <a href="http://bugs.debian.org/484841";>Fallo
>         #484841</a>: de manera predeterminada /usr/local no es
>         escribible por el
>         grupo staff; el cambio podrá implementarse tras el plan de
>         transición
>         que permita a los administradores mantener el comportamiento
>         
>         actual.</li>
>            por:
>         <li>2009-07-25 <a href="http://bugs.debian.org/484841";>Fallo
>         #484841</a>: el grupo staff ya no tendrá permisos de escritura
>         en el
>         directorio /usr/local; este cambio será implementado después
>         de contar
>         con un plan de transición adecuado que brinde a los
>         administradores de
>         sistemas la posibilidad de elegir continuar con el
>         comportamiento
>         previo.</li>
> 
> El texto original en inglés dice:
> 
> "by default, /usr/local is not writable by group staff; change can be
> implemented after transition plan which enables administrators to keep
> the current behavoir".
> 
> Y mi propuesta de traducción es:
> 
> "El grupo staff no tiene permisos de escritura en el
> directorio /usr/local; el cambio puede ser implementado después de un
> plan de transición que permita a los administradores de sistemas
> mantener el comportamiento previo"
> 
> En la primera oración mantengo el verbo en presente al ser una
> situación "by default" (algo debido a una configuración concreta), al
> igual que en la segunda, si bien es cierto que al ser un acción que se
> podría hacer "tras" una modificación (...can be implemented after...)
> podría ir en futuro como propones. A su vez mantengo la posibilidad
> del cambio con la forma "puede ser", en lugar de irme al futuro
> imperfecto "será" que supone una mayor determinación a la inclusión
> del cambio. Pero mantengo estas formas por rigor a la redacción del
> texto, pero, si en tus investigaciones te has cerciorado que el
> bloqueo de los permisos de escritura en usr/local se realizaron tras
> diversas situaciones que sacaron a la luz problemas desconocidos,
> pongo los verbos en futuro como me sugieres.

Como te mencioné, lo que aparece en la página es un resumen, sin embargo
te dará mayor idea leer la decisión que tomó el comité:

«Decide to change the default so that /usr/local is not writeable by
group staff anymore. This change should only be implemented after an
appropriate transition plan exists which enables system administrators
to maintain the ability of group staff to write to /usr/local. (Reasons
for the change are the adaption of other tools like sudo on most sites,
and the concept of "least surprise" for novice users.)»

Como ves, el grupo staff actualmente tiene permisos de escritura en el
directorio /usr/local y se decidió que ya no los tenga, por eso la
traducción basado en las normas de traducción [1]:

«En general, se debe evitar la traducción directa del inglés. El
traductor debe primero leer y entender lo que va a traducir antes de
hacerlo y, en muchos casos, es mejor traducir con las palabras que uno
utilizaría, y no necesariamente con las mismas que utilizó el que lo
escribió en inglés.»

Saludos y buen día

P.D. «Nunca envíe sus mensajes en HTML; use por el contrario, texto
plano.» [2]

[1] http://www.debian.org/intl/spanish/notas
[2] http://www.debian.org/MailingLists/#codeofconduct
-- 
Fernando C. Estrada


Reply to: