On Miércoles 22 Septiembre 2010 19:03:11 Javi Taravilla escribió:
> Agradeciendo enormemente las rápidas propuestas de Noel y animando a
> Fernando C. Estrada a que le eche un vistazo (por su ánimo a ayudar), mando
> el wml actualizado.
>
> Estas son las partes debatidas, tal cual van incluidas en la traducción
Eso que pones no es lo que te mandé :)
Tienes toda la razón. Grrr...Abiword lleva un tiempo dándome problemas al guardar los documentos, y hay veces que sencillamente no lo hace. La vez anterior lo mandó como binario (mientras que a mi me dice guardarlo como wml) y ahora no ha guardado los cambios incluidos. Desde luego es hora de pasarse definitivamente (como algunos me recomendáis en otros sitios) a Gedit, el cual uso para otras tareas. Por exclusivas razones de visualización en pantalla tiraba de Abiword y OO, pero basta ya, :(.
Disculpa de nuevo por tanto mi fallo y vuelvo a mandarlo con las incorporaciones correctas. Descargaré de nuevo la versión antigua, abriré con Gedit y modificaré.
> 2009-09-04 Bug #535645: negarse a invalidar la eliminación del equipo de
> ftp de ia32-libs-tools; confirmar la habilidad del equipo de ftp para
> borrar paquetes; recomendamos la aclaración de las razones para la
> eliminación y el mecanismo de reintroducción en el archivo.
«la eliminación del equipo de ftp de ia32-libs-tools» no queda nada claro. Por
eso escribí: «rechazar anular la eliminación de ia32libs-tools por el equipo
ftp».
Puede que «rechazar anular» suene raro, y «rechazar invalidar» quede mejor.
«confirmar la habilidad del equipo de ftp para borrar paquetes» creo que no
está bien porque no se confirman las habilidades (que son un asunto técnico)
sino las autorizaciones. Por ejemplo, yo tengo la habilidad de pegarle una
puñalada a alguien por la calle, pero no tengo autorización para ello. Por eso
escribí «confirmar la autorización del equipo ftp para eliminar paquetes»
> 2009-07-30 Bug #539158: rechazo a anular el mantenimiento de udev; se
> sugiere que printf sea documentado como incorporación necesaria en la
> normativa.
No se rechaza «anular el mantenimiento de udev», simplemente proponerlo sería
una locura. Se rechaza «anular la decisión del mantenedor de udev».
Por otra parte, no «se sugiere que printf sea documentado como incorporación
necesaria», al menos como yo entiendo lo que se votó, sino que «se sugiere [al
equipo de la Policy] documentar en la Política que printf es una
característica incorporada [a todas las shells que se presenten como posibles
/bin/sh]»
> 2009-07-25 Bug #484841: por defecto, el personal de grupo no puede escribir
> en /usr/local; el cambio puede ser implementado después del plan de
> transición que permite a los administradores mantener el funcionamiento
> actual.
En castellano no hacemos nada «por defecto», sino «por omisión» (o «de manera
predeterminada»).
No hay nada que se parezca remotamente al «personal de grupo», lo que hay es
un «grupo staff».
Por otra parte, los tiempos verbales son importantes. No dice que «el cambio
puede ser implementado», que es una afirmación en positivo, sino que «el cambio
podrá implementarse», que queda subjetivo. Por lo mismo, no es «que permite a
los administradores» sino «que permita».
Otra cosa más, es que el directorio /usr/local no funciona, sino que tiene
determinados permisos que le dan un determinado comportamiento, por eso no
sería «mantener el funcionamiento actual» sino «mantener el comportamiento
actual».
Completamente de acuerdo. Como te digo, las propuestas que me mandaste no es que no aparezcan porque no crea en ellas o las vea incorrectas, sino por problemas con el guardado.
En resumen:
rechazar invalidar la eliminación de ia32libs-tools por el equipo ftp;
confirmar la autorización del equipo ftp para eliminar paquetes; recomendar la
aclaración de las razones para la eliminación y el mecanismo de reintroducción
en el archivo
rechazar anular la decisión del mantenedor de udev; se sugiere documentar en
la Política que printf es una característica incorporada
por omisión, el grupo staff no podrá escribir en /usr/local; el cambio podrá
implementarse después del plan de transición que permita a los administradores
mantener el comportamiento actual
Muchas gracias de nuevo por la paciencia de vovler a corregirlo y reenviarme la propuesta.
Un saludo.
er Envite
--
To UNSUBSCRIBE, email to debian-l10n-spanish-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] 201009222045.29717.envite@rolamasao.org" target="_blank">http://lists.debian.org/[🔎] 201009222045.29717.envite@rolamasao.org