2010/12/19 Oscar Manuel Gómez Senovilla <[email protected]>:
> Buenas. Aviso que el correo es largo, aunque espero que no tedioso. Va
> dirigido a quien desee involucrarse en la implementación de criterios de
> mejora en el proceso de traducción.
>
>
> Tras haber hecho la revisión de dos documentos en oooauthors, y pegarme con
> la documentación, sistema de traducción, etc., me veo en la obligación de
> realizar una serie de sugerencias que, si parecen bien, y en la medida de lo
> posible, se llevarían a cabo cuando fuera prudente hacerse.
Creo que si es bastante largo y algo tedioso. Creo que la mision del
documento es mantenerlo simple y tener un escrito que no tengan a un
nuevo voluntario pasandose leyendo dicho documento largo y tedioso.
>
> Quería comentar que básicamente voy a hacer un análisis, paso a paso, del
> funcionamiento, donde algunas cosas ya estarán hechas, otras no, otras son
> mejorables, otras según se mire, etc. Este análisis está hecho pensando en
> cómo tendría que funcionar el sistema de forma idónea para poder llevar todo
> a cabo, pero el posible que el sistema tenga fallos o deficiencias (bien por
> el propio software o la versión implementada, o porque la configuración que
> se haya hecho no sea la apropiada) que impidan hacerlo. También está la idea
> de que la organización en el procedimiento permita tener una visión exacta
> del estado de los documentos, sin tener que ponerse a investigar por todo el
> árbol. Dicho de otra forma, si uno busca garbanzos, que pueda encontrarlos
> en "garbanzos" y no en un sitio que, tras dar varias vueltas y mirar en
> "Otros" le diga que se encuentra en "Cosas varias".
>
Creo que tampoco es el objetivo tener un sistema idoneo, o mejor dicho
el sistema idoneo es el menos burocratico. Es quizas el problema con
los manuales que quieren ser tan perfectos y completos que nadie los
lee. Muchas veces es mejor tener solo los lineamientos princpiales y
partir de estos. Un ejemplo es la participacion en el wiki, pocas
personas se leen el manual de mediawiki antes de crear su primer
modificacion.
> Tampoco he fantaseado demasiado, y por los documentos que he leído, creo que
> debería poderse hacer con las herramientas actuales, salvo que éstas no
> funcionen como supuestamente deben funcionar.
>
>
> Como piloto, he ido haciéndolo de forma sencilla en mi disco, para probar si
> realmente era posible, y creo que lo es.
>
>
> Fase 0
> ======
> Donde todo comienza es en poner unos originales para que se comience el
> proceso. Para ello, alguien tendrá que informar y/o coordinar el progreso de
> los proyectos en inglés. Cuando se finalice un proyecto, se crearía una
Por que razon debiamos informar a otro proyecto. Aunque en este
proyecto se supone que todos sabemos ingles, el tener que obligar a
participar en dos listas es algo que no veo necesario para la
traduccion como tal.
> carpeta en el sitio de español *con el mismo nombre (o identificador, si lo
> hubiera) que en inglés* para albergar el nuevo proyecto. De esta forma,
> cualquier persona puede asociar cualquier traducción con el proyecto
> original, sin necesidad de conocer el idioma.
Creo que la estructura no trabaja asi a nivel general. Tambien
oooauthors como tal no se ve como un proyecto como tal 'publico' la
mayoria del sitio esta para los miembros y las publicaciones se hacen
en documentation.openoffice.org. Vaya digamos oooauthors es una
herramienta de trabajo.
>
> Como punto de partida, habría que crear una carpeta que contenga los
> originales, ("0 - Sources"), en donde habría *una copia* del zip conteniendo
> la documentación publicada (lo de la copia es para tener una referencia fija
> por si acaso se modifica la ubicación o lo que sea en el origen).
De nuevo, la documentacion usualmente se hace en el proyecto
individual de OOo, no tanto en OOoAuthors.
>
> Fase 1
> ======
> Esta fase sería la de realizar la traducción de los originales. Para ello,
> el coordinador pondría todos los ficheros extraídos del zip para comenzar la
> traducción *Y* asignarles un nombre adecuado a la hora de comenzar la
> traducción. En este punto, quisiera discutir algún detalle sobre los nombres
> de los ficheros.
Aun no entiendo el uso del zip, usualmente se traducen un documento a
la vez. Las asignaciones multiples pueden crear secuestro de
documentos donde estan asignados a alguien que no esta activamente
traduciendo. A la misma vez el nombre de los ficheros es unica, muchos
usuarios no lo siguen, el tener cambiar la convencion o tener una
convencion mas estricta creo que puede ser desfaborable en su
adopcion. Por ejemplo los usuarios nuevos sus nombres son los titulos
traducidos y nada mas, ni fecha ni autor. Esta labor es usualmente mas
dificil que la de tener un nombre muy exacto. Tambien la mayoria de
esta ifnormacion se deduce por el folder. Personalmente siento que
admiistrar los documentos por folders es una mejor opcion que tener
una lista grande y ver documentos en diferentes etapas con diferentes
codigos y con documentos que no fueron correctamente codificados.
> Creo que, al menos hasta que se publique definitivamente un documento, debe
> tener una asociación con el original en las distintas fases del proceso, y
> por ello creo que modificar sustancialmente el nombre mientras haya que
> mantener un ojo en el original y otro en el documento que se esté
> traduciendo puede dar lugar a errores. Por ello, partiendo de la
> nomenclatura en inglés, propongo la siguiente nomenclatura para el español:
>
> <CODIGO>-ES-XX-Nombreingles.odt
>
> donde <CODIGO> son los 7 primeros caracteres del nombre del fichero en
> inglés hasta que empieza el nombre en sí (en lo poco que he visto, creo que
> son 7). Por ejemplo, en la guía de inicio de Writer, el código va desde
> "0101GS3" hasta "0116GS3". Luego, "ES" son las iniciales de español, y "XX"
> es un código de un número indeterminado de caracteres que debe poder
> ordenarse alfabéticamente, y que permita saber el estado del documento. El
> contenido de "XX" lo retomaremos al final de ver todas las fases, pero como
> avance, se excluiría el nombre del traductor, *pudiendo* ir en el interior
> bien como comentario, o bien en algún sitio que quien realice la siguiente
> fase del proceso, pueda identificar, si fuera necesario, a quien haya
> trabajado antes en el documento. Esto también se aplica para la fecha,
> pudiendo ir en el interior, y no en el nombre del fichero.
>
> El nombre de la carpeta sería "1 - Pendientes de traducir" (o quizás "1 -
> Para traducir"). Dentro de ésta, aparte de los documentos iniciales, y
> quizás con alguna modificación que comentaré al final, estarían los
> documentos en su estado inicial para comenzar la fase 1 del proceso de
> traducción.
Umm.. esto no duplicaria documentos inecesariamente, con tener una
liga al documento en el proyecto en ingles seria suficiente no crees?
Aparte usualmente los usuarios no escojen su documento sino se les
asigna. Esto no es por disenio sino por experiencia de comportamiento
de los usuarios nuevos. Tienes que ponerlo en el contexto que muchos
apenas estan sacando sus permisos de autores y ya lo que quieren es
trabajar, entre mas directo sea (via asignacion) es mejor para ellos.
Tambien se mantiene una grafica de avance local del grupo, esto
duplicaria la actividad de gestion.
>
> Fase 1.1
> ========
> La fase 1.1 consiste en el proceso de empezar a traducir un documento que se
> encuentra en "1 - Pendientes de traducir". Para ello, se habilita una
> carpeta "En progreso" dentro de "1 - Pendientes de traducir". Con esto, el
> procedimiento de la fase inicial de traducción quedaría:
De nuevo, este folder ya existe.
> - Descargar el zip con los originales
No veo el caso de un zip, a menos que se este delegando a una empresa
donde se encargaran de multiples documentos.
> - Un traductor avisa a la lista de que va a traducir un documento.
Esto ya se tiene.
> - A continuación, descarga el documento, y luego lo mueve (este proceso
> aparentemente sencillo, no lo tengo claro cómo se viene haciendo en
> oooauthors) a "En progreso", para que quede claro que se está trabajando en
> él.
> En esta fase puede haber un caso especial que comento al final.
Asi se maneja actualmente. Solo con subir el documento al folder en cuestion.
>
> Fase 2
> ======
> La fase 2 consiste en habilitar los documentos cuya traducción ha finalizado
> para proceder a su revisión. Para ello, se crea una carpeta "2 - Pendientes
> de revisión".
> Cuando un traductor finalizar la traducción, tendría que hacer:
> - Poner el código "XX" adecuado en el nombre del fichero en su disco local y
> subirlo al fichero a esta carpeta.
Esto ya se tiene pero no creo que se deba cambiar el codigo, con que
este la carpeta ya se entiende que esta en ese proceso. Lo que si
deberia cambiar es la persona que lleva la revision usualemtne
asignada con sus inciiales.
> - Quitar el documento anterior de "1 - Pendientes de traducir/En progreso".
No creo que los usuaios lo hagan por eso el coordinador global se
encarga por que muchos aun no saben como llevar eso y tambien se
pierde mas tiempo enseniando a los nuevos que tener una persona
asignada para 'housekeeping'.
> - Avisar a la lista de las acciones realizadas y del nuevo estado.
Lo mismo esto ya se tiene al anunciar la finalizacion del documento.
> De esta forma, se podrán ver claramente los documentos disponibles para esta
> fase.
De hecho esto se actualiza en la tabla general de avance y no es en
tiempo real sino se genera cada 'corte'.
>
> Fase 2.1
> ========
> Consiste en habilitar que se pueda realizar la revisión de un documento cuyo
> último trabajo ha sido la traducción y que se ha dejado en "2 - Pendientes
> de revisión" con el código de la fase 2. Según la documentación en inglés,
> esto se puede realizar con permisos de revisor y haciendo "retreat" del
> documento, que cambia el estado a "borrador interno" y posteriormente se
> procede a la descarga. Alternativamente, si no se tuvieran permisos de
> revisión, se necesitaría tener una carpeta "En progreso" dentro de "2 -
> Pendiente de revisión". Después, el revisor:
Creo que los permisos de revisor y autor son los mismos. Casi casi es
binario o eres usuario sin permisos o con permisos.
> - Descargaría el documento a revisar.
> - Avisaría en la lista del trabajo que se dispone a realizar
> - Movería el documento a "2 - Pendientes de revisión/En progreso"
Usualmente la asignacion se hace via la lista, y se asigna al mismo
tiempo o en el mismo hilo que se publica la finalizacion.
>
> Fase 3
> ======
> La fase 3 consiste en habilitar que se pueda realizar la segunda revisión de
> un documento una vez que se ha finalizado la primera. Para ello, se
> habilitaría una carpeta "3 - Pendientes de revisión 2". Cuando un revisor
> finalice la primera revisión:
> - Nombrará localmente el fichero con el código "XX" correspondiente.
de nuevo siento esto inecesario.
> - Subirá el documento a esta carpeta
> - Quitará el documento anterior de "2 - Pendientes de revisión/En progreso"
> - Avisará a la lista de las acciones realizadas y del nuevo estado, para
> quien desee continuar el trabajo.
Esto ya se tiene asi, tambien creo que la mayoria de esto se trata en
la lista mas que en el sitio de oooauthors. Creo que la causa de tener
un dominio propio para el apartado en tu mente y la de muchos usuarios
ponen a oooauthors como el centro de comunicaciones y operaciones, sin
embargo este es la lista mas que el sitio.
Usualmente el flujo es de esta manera:
Usuario -> Lista de soporte/discusion de OOoES -> Lista de
localizacion -> OOoAuthors.
Poniendo al sitio como la 3era fuente de informacion despues de las listas.
>
> Fase 3.1
> ========
> Consiste en habilitar que se pueda realizar la revisión de un documento cuyo
> último trabajo ha sido la primera revisión y que se ha dejado en "3 -
> Pendientes de revisión 2"(*). con el código de la fase 3. Se necesitaría
> tener una carpeta "En progreso" dentro de "3 - Pendiente de revisión 2".
> Después, el revisor:
> - Descargaría el documento a revisar.
> - Avisaría en la lista del trabajo que se dispone a realizar
> - Movería el documento a "3 - Pendientes de revisión 2/En progreso"
>
>
> Fase 4
> ======
> Consiste en habilitar que se puedan realizar las acciones necesarias(**)
> previas a la publicación, tras acabar la segunda revisión. Para ello, se
> crearía una carpeta "4 - Pendiente de publicar". El revisor tendría que:
> - Renombrar localmente el fichero con el código "XX" correspondiente.
> - Subir a esta carpeta el fichero renombrado
> - Quitar el documento anterior de "3 - Pendientes de revisión 2/En
> progreso".
> - Avisar a la lista del trabajo realizado y del nuevo estado, para quien
> desee continuar el trabajo.
>
>
> Fase 5
> ======
> Publicar. Seguramente habrá ya un sitio adecuado para ello, por lo que no
> debería ser necesario nada en este punto sobre lo existente. Lo menciono más
> que nada para tener el proceso completo e intentar no dejar cabos sueltos.
> Como detalle, en este punto, el nombre del fichero, al ir ya al público del
> idioma, debe tener una traducción adecuada. Esta traducción será el título
> que figure en la primera página, quitando espacios y usando mayúsculas para
> las palabras nuevas. Por ejemplo, el fichero en inglés
> "0109GS3-GettingStartedWithMath.odt", en sus distintos procesos sería
> "0109GS3-ES-XX-GettingStartedWithMath.odt", pero a la hora de publicar,
> atendiendo a la traducción que figura en la página 1 del capítulo, sería
> "0109GS3-ComenzarConMath.odt" o "0109GS3-ES-ComenzarConMath.odt", para que
> los no nativos puedan al menos saber el idioma del documento.
De hecho el proceso aunque asi pasa, debemos construir el libro pero
esta actividad solo se olgra cuando tenemos los capitulos completos
finalizados cosa que aun no ha pasado. Cuando se tiene el 100% de los
documetnos traducidos de algun libro. Unicamente ahi se hace una
publicacion real.
>
> (*) Dado que debería conseguirse un código que diferencie la primera de la
> segunda revisión, y que básicamente son el mismo tipo de proceso, gracias al
> código diferenciador de fase de revisión, se podría utilizar la carpeta "2 -
> Pendientes de revisión" con la misma filosofía de ubicación de archivos que
> las fases 2 y 2.1.
Esto ya se tiene, debe ser rev o rev1 y rev2 pero solo miemtras se
revisa ya que al finalizar ya se sube a la caprpeta de publicacion.
> (**) Habría que consensuar el uso de una plantilla para aquellos aspectos
> legales y cosméticos que no deberían quitar tiempo a traductores ni a
> revisores, relativos principalmente a las páginas de créditos y detalles del
> documento publicado. También habría que consensuar si esta parte se puede
> realizar previamente a la fase 1, y que se revise en la fase previa a la
> publicación.
>
De hecho cualquier documento finalizado tiene esto ya hecho, pero si
se parte del documento original usualmente no se tiene esa opcion.
> Códigos de estado
> =================
> Teniendo en cuenta que en inglés se utiliza el formato
>
> <CODIGO>-Nombreingles.odt
de hecho es <codigo>-<titulo>-<autor>-<fecha>[-<revision>].odt
>
> para los documentos *publicados* (ignoro el procedimiento intermedio, que es
> el que aquí nos ocupa), creo que la nomenclatura debe ser similar, con los
> atributos justos para que cualquiera pueda tener constancia del contenido y
> estado del documento atendiendo sólo al nombre del mismo. Por eso, propongo
>
> <CODIGO>-ES-XX-Nombreingles.odt
No lo veo necesario usualmente el codigo es sifuciente para asociarlo
con la fuente original. el 'es' se asume al estar en la carpeta de
oooauthors.org/es ya que no se tiene ningun documento en algun otro
idioma en todo el arbol de 'Español'.
> siendo XX un código de un número indeterminado de caracteres que debe poder
> ordenarse alfabéticamente, y que indique el último estado *por el cuál ha
> pasado" el documento. Teniendo en cuenta las fases por las que atraviesa el
> documento, los distintos nombres serían:
Esto se maneja al final del documento y realmente unicamente durante revisiones.
> - Fase 0: Aquí está el original en inglés en formato
> "<CODIGO>-Nombreingles.odt", que no hay que alterar.
> - Fase 1: Se pone el documento para empezar a traducir, con el nombre
> "<CODIGO>-ES-Nombreingles.odt"
> - Fase 1.1: Al moverse a "En progreso", no hay cambio de nombre. Ahora,
> pueden producirse ciertas circunstancias que impidan que el traductor pueda
> completar la traducción en un plazo apropiado (enfermedad, falta de tiempo,
> capítulo excesivamente largo, o cualquier otro imprevisto) y tenga que dejar
> la traducción para que alguien la continúe. Por ello, para prever incluso
> que varios traductores dejen trabajos sin concluir, propongo que se use la
> nomenclatura "Lx", siendo "L" de "localización" (podría usar "traducción",
> pero no quedaría ordenado con la "R" que viene después) y "x" un dígito,
> empezando por el "0", que se vaya incrementando al pasar de "En progreso" al
> volver a "1 - Pendientes de traducir", quitándolo, obviamente, de "En
> progreso" en cada ocasión. En este caso, sería como volver a la fase 1, pero
> con la "x" incrementada. La "x" puede crecer infinitamente, si fuera mayor
> de 9, o 99, etc.
> - Fase 2: Al coger un documento con "<CODIGO>-ES-Lx-Nombreingles.odt" en "2
> - Pendientes de revisión", se pasaría con el mismo nombre a "En progreso", y
> al finalizar, el codigo sería "R1".
> - Fase 2.1: En el caso de interrumpirse las revisiones y tener la casuística
> del proceso de traducción, se usaría "R1x", dejando la revisión parcial con
> este nombre en la carpeta anterior. Mientras no haya un código "R1", es que
> la primera revisión no se ha podido finalizar y queda pendiente de que
> alguien lo continúe.
> - Fase 3: Se cogerían los "R1", y se pondrían en "En progreso".
> - Fase 3.1: Al igual que la fase 2.1, se usaría "R2" para indicar que la
> revisión 2 ha finalizado (aunque iría en la siguiente carpeta), pero se
> puede indicar "R2x" fuera de "En progreso" para indicar que se desea que
> alguien retome la revisión. Esto permitiría reutilizar la carpeta para ambas
> fases de revisión (o incluso más de 2 revisiones).
> - Fase 4: Se cogerían los "R2", se realizarían en el documento las
> modificaciones previas a la publicación y se pasaría a publicar con el
> nombre final de "<CODIGO>-ES-NombreTraducido.odt".
>
>
> Quedarían los detalles de la "plantilla" para los créditos, pero ahora ya es
> muy tarde y creo que lo principal ya está expuesto. En fin, espero que no se
> os haga muy pesado y que entre todos podamos mejorar la documentacion.
Uff creo que la mayoria de lo que comentas ya esta. Solo que mas
sencillo y mucho mas corto. El sobre documentar creo que es algo
bastante tedioso e inutil y hasta contraproducente. Como puse con el
wiki de OOo, pocos voluntarios no editan, por que prefieren que
'alguien que sepa' les diga que hacer o donde contribuir. Poca gente
lee la ayuda por que no sabe que buscar o como buscarlo, o simplemente
no se hacen de tiempo para ponerse a leer la ayuda y prefieren
contribuir.
Por eso un documento sencillo con lineamientos rapidos de ver en un
pantallazo es preferible que un manual que por su longitud nadie lo
toque.
> Saludos.
>
> --
> |----------------------------------------------------------------------|
> | http://counter.li.org info: Linux user: 92390 - Linux machine: 39301 |
> | Oscar Manuel Gómez Senovilla - omgsATescomposlinux.org |
> | GPG Key at http://keyserver.pgp.com |
> |----------------------------------------------------------------------|
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
--
Alexandro Colorado
OpenOffice.org Español
http://es.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
