Re: [pgsql-es-ayuda] Re: [arpug] Re: [arpug] Traducción al español del manual oficial

2009/11/3 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>

> Mariano Reingart escribió:
> > 2009/11/3 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> >
> > Las actualizaciones se pueden hacer manualmente (calculo que del mismo
> modo
> > que como se hacen con SGML) o podríamos hacer un script para que mezcle
> los
> > textos, la información es la misma que en los SGML nada más que en un
> > formato wiki más simple, incluso la estructura es mucho más limpia (texto
> > plano, sin tags), lo que tendría que permitir hacer merges más fáciles.
>
> Ok, si te parece que se puede, adelante. Si me preguntan mi opinión, yo
> digo que quizás se pueda o quizás no, y en caso de poderse, es muy
> difícil; y antes de seguir ese camino, haría el intento para ver cómo
> funcionaría.
>

De hecho, es lo que queremos hacer, evaluar las alternativas:
GIT: http://git.postgresql.org/gitweb?p=docs_castellano.git;a=summary
Pootle: http://pootle.arpug.com.ar:8080/es/pgdoc/sql-select.po?translate=1
Trac Wiki: http://www.arpug.com.ar/trac/wiki/sql-select.html

Pueden revisarlo y vemos que les parece.

> Lo de las versiones distintas no hay problema, se pueden copiar y
> mantener
> > paginas para versiones diferentes (de hecho el wiki esta almacenada en
> una
> > base de datos postgres, se puede manipular por SQL).
>
> Hmm.
>
>
> > > Mi opinión al respecto (y es algo en lo que he pensado bastante) es que
> > > una traducción debe necesariamente hacerse sobre el formato SGML o bien
> > > un formato equivalente (como podría ser el docbook XML).
> >
> > ¿Formato equivalente en cuanto a la estética del producto final o
> respecto a
> > la parte técnica.?
> > Concuerdo que SGML o XML técnicamente puede ser superior, pero una WIKI
> es
> > mucho más práctica, no requiere tantos conocimientos y es más
> colaborativo
> > (y esteticamente es similar).
>
> Técnicamente. En realidad estoy pensando en DocBook XML específica y
> exclusivamente.
>

Bueno, como comentaba en otro mail, el formato wiki es ampliamente usado
para documentación.
De hecho, toda la documentación de Python se basa en este formato, y se han
podido realizar traducciones sin problemas.

>
> > > Ya tenemos dos proyectos abortados de traducción, uno de Mario González
> > > que consistía en una webapp de traducción y que además permitía
> > > revisión; y otro de Ricardo Mendoza, que está alojado en
> > > git.postgresql.org y que hasta donde entiendo, en realidad no está
> > > abortado sino que simplemente Ricardo dejó de trabajar en él.
> >
> > La wiki de trac también permite revisión y control de cambios.
>
> Yo uso Trac y su wiki todos los días, en mi trabajo. Es útil para cosas
> muy menores. Para algo tan complejo como este proyecto, no es
> apropiado en mi experiencia.
>
> > > No es mi intención detener el ímpetu que quieren meterle a este tema,
> > > sino encauzarlo de manera que pueda perdurar en el futuro (que es donde
> > > falló el proyecto de traducción de Hispalinux, que tradujo los manuales
> > > de 6.5 y después dejó una actualización a 7.2 a medio hacer).
> >
> > Si vemos los esfuerzos traducción pasados y actuales, el SGML no
> garantizó
> > que pueda perdurar, ya van aproximadamente 10 años sin una traducción,
> por
> > eso planteo algo más simple y dinámico.
> > Lo mismo pasa con la traducción al portugés, no esta totalmente
> actualizada
> > aún hecha en SGML.
>
> El que estuviera hecha en el SGML no garantiza que vaya a hacerse, sólo
> que es posible hacerlo. Si ellos no lo hicieron no significa que otros
> no puedan hacerlo!
>

Como se hace con SGML, ¿mergeando manualmente los cambios?
Igual mi punto es, si se puede hacer con SGML, se puede hacer con formato
texto plano de la wiki, incluso debería ser más fácil.

> > > Recomendaría ver qué es lo que hicieron para traducirlo al francés y
> al
> > > alemán, que son traducciones que se mantienen al día constantemente.
> > >
> >
> > Hasta donde sé, en francia no usaron el formato SGML, lo pasaron a XML y
> > luego utilizaron herramientas especiales.
>
> Es lo mismo. (Acoto que "herramientas especiales" se refiere a
> herramientas de traducción que se usan en todos lados, como KBabel o
> poEdit, que son las mismas que se usan para las traducciones de los
> archivos PO de los mensajes de los programas. En otras palabras, si los
> franceses pueden hacer eso, ¿por qué no nosotros?)
>

Las herramientas especiales supongo que serán de traducción, trate de
investigar pero no encontré nada.
También calculo que los franceses tendrán experiencia con esas herramientas
y/o tiempo para desarrollarlas y mantenerlas.

> > La alemana hasta donde pude investigar uso un editor de texto:
>
> ... sobre los archivos SGML.
>
> > http://archives.postgresql.org/pgsql-general/2003-09/msg01690.php
> > (¿estabas en dicho hilo y vi que se trataron estos temas, alguna
> novedad?)
>
> No, sigue siendo básicamente lo mismo. Y mi opinión es la misma que
> tenía en 2003. (Es bastante deprimente ver que nunca conseguí sacar
> adelante una traducción en seis años).
>
> > De hecho, para la traducción en español, el año pasado pusimos a
> disposición
> > la herramienta Pootle que no tuvo aceptación. Trabajaba pasando los sgml
> a
> > xml y luego a po, como hacen algunos otros proyectos de software libre.
>
> Sí, yo sugiero que se use algo como eso. ¿No tuvo aceptación, o más
> bien fue que no supimos encauzar a los potenciales traductores
> adecuadamente?
>

La verdad que desconozco. Creo que hicimos todo lo posible.
Mi teoría es que Pootle no es muy atrayente que digamos, aparte de ser un
poco tosco.
Pienso lo mismo de usar GIT y traducir los SGML a mano con el vi :-)
Por eso se me ocurrió el tema de la wiki, que es mucho más colaborativo,
dinámico y fácil de usar.

> El tema es que se pierde la estructura, se pueden mezclar los textos
> > antiguos y nuevos,
>
> ¿En qué basas estos comentarios?
>

En la impresión que me dejo la traducción de los instaladores de PostgreSQL
(OneClickInstaller y PgInstaller).
Y teniendo en cuenta que eran mensajes de un programa simple (instalador),
no manuales.

Intenté lo mismo con las FAQs (HTML), y noté varias dificultades.
Igualmente ya subí un par de páginas que les comenté arriba para que lo
prueben uds.

Una cosa que no se podría hacer con Pootle y si con la wiki es modificar la
estructura, agregar o quitar párrafos, cambiar formatos, etc.
Aparte, te extrae los tags y hay que respetarlos, es un poco más engorroso
que el formato wiki.

> > hay que transformar entre formatos, no se ven los
> > resultados inmediatamente, es más difícil de usar que una wiki, etc.
>
> Hay que transformar, sí. ¿Es problemático eso? No veo cómo, puesto que
> se supone que todo lo hace un programa. Respecto de ver los resultados
> inmediatamente, tampoco veo que sea tanto problema, porque debería
> publicarse el manual traducido convertido a HTML en forma automática y
> periódica, de forma que el traductor pueda ver lo que ha ido haciendo.
>

¿Porque complicarnos tanto si puede ser automático y tener todo online
inmediatamente?.
¿No es mejor que el traductor vea como queda la traducción directamente, sin
tener que esperar que se transforme, compile, suba, etc.?

¿Difícil de usar? No sé. El Wiki de Trac sólo permite editar una
> página completa, no por secciones como el Wiki de MediaWiki. Si se pone
> una página por cada capítulo, hay que editar trozos de texto muy
> grandes.
>

Trac tiene muchos plugins, uno es editar por sección (ya lo instalé).
Igualmente traduciendo los SGML hay que traducir toda la página.

> > Quizás para los mensajes de un prorgama o una documentación pequeña
> sirve,
> > pero para la documentación de PostgreSQL no creo que simplifique las
> cosas
> > (aparte que tampoco se trabaja directamente sobre los SGML, y hoy por hoy
> no
> > se puede volver del XML a los SGML)
>
> No importa que no se pueda volver a SGML; lo que importa es que el XML
> se puede procesar con las mismas herramientas y obtener
>

Entonces estamos igual, en vez de XML va a ser TXT con formato wiki, no veo
la diferencia.
(incluso se podría bajar a archivos si lo desean)

> > Además, con una wiki se pueden mantener al día la traducción calculo
> mucho
> > más fácil y rápidamente.
>
> Es fácil editar; es difícil ver qué se tradujo originalmente y cómo
> difiere de lo que se está traduciendo hoy.
>

Se puede hacer un diff con las versiones que quieran comparar, viendo cambio
por cambio (trac lleva el control de versiones de las páginas wiki de modo
similar a un repositorio cvs, svn o git)
Esto creo que es una ventaja, a diferencia de Pootle que solo tenés una
versión de la traducción y las sugerencias (no hay historial)

Si se respetaran las lineas (no se agregan o quitan), se podría hacer un
seguimiento directo similar al que se puede hacer con pootle.

> > Así que apoyo totalmente lo que está en el comentario más arriba de lo
> > > que cito, que no sé de quién será: el quilombo va a ser mucho.
> >
> > Por mi parte, prefiero tener algunos inconvenientes a no tener la
> traducción
> > en español.
>
> Totalmente de acuerdo en este punto.
>
> > Trabajar con SGML o XML tampoco nos asegura no tener inconvenitntes, y
> son
> > más difíciles de usar y mantener.
>
> En este no :-)
>
> > De ultima, una vez que este traducido en la wiki, es muy simple (yo diría
> > trivial) modificar los SGML si alguien quiere volver atrás o utilizar
> otro
> > método.
>
> No lo veo trivial, ni siquiera difícil; lo veo imposible.
>

A lo que me refería es que con la traducción hecha, es copiar y pegar los
textos, un proceso no automatizado pero bastante mecánico.
Igualmente coincido que no es lo ideal y sería una lástima desperdiciar
tiempo en esas cuestiones.

> Dicho todo eso, reitero que esto es sólo mi opinión. Si quieren hacerlo
> de esta forma, adelante. Ya expuse mi punto de vista y no voy a gastar
> tu energía ni la mía tratando de detenerte.
>
>
Ok, solo quería fundamentar mi decisión y tratar de consensuar estos temas.

Sds
Mariano
http://www.arpug.com.ar/trac