Re: [arpug] Re: [arpug] Traducción al español del manual oficial

2009/11/3 juan jaimes <juanjava(at)gmail(dot)com>

> hola diculpen me entrometa, pero he tratado de aprender postgresql desde
> hace tiempo pero no avanzo, y veo que como ustedes hay muchos que quieren
> traducir los manuales y a la fecha no se ha realizado un buen avance, que
> tambien lo comprendo porque no hay nada de reconocimiento ni verval ni
> monetario y ahora que veo esto se me ocurre lo siguiente, porque no pagar a
> profesionales que realicen la traduccion y a alguien del grupo de postgresql
> que la revice serian dos pagos (aunque no se cuanto seria), y para cubrir
> estas cantidades colocar a alguien de ustedes dos Mariano Reingart, Emanuel
> Calvo Franco ya que lo realizan sin ningun lucro (que yo diria que deberian
> de tener alguna, ya que ud lo administrarian) la recolecta a todo aquel que
> lo quiera tener (poniendo un valor minimo de cooperacion), que creo yo que
> serian bastantes y asi podemos pagar la traduccion y supervision.
>

Justamente el tema de traductores profesionales lo comentamos en Brasil con
la gente que hizo la traducción de los manuales al portugués (Euler et. al.)
y desarrolladores importantes de PostgreSQL (Bruce Momjian y Magnus
Hagander)
Todos nos recomendaron no hacerlo, ya que salvo que consigamos traductores
especialistas en PostgreSQL, el resultado no es útil (un traductor común no
tiene los conocimientos técnicos específicos para que la traducción sea de
buena calidad)

La idea de la donación es buena, por lo menos a mi (y calculo que al resto
también) nos permitiría dedicarle más tiempo a este proyecto, aunque todo
esto no lo planteamos como algo comercial en sí.

> espero no agredir a nadie, si ya lo habian pensado perdon pero detodas
> maneras lo propongo y lo comento porq
>

Todo bien, gracias por tus comentarios, todas las opiniones son bienvenidas,
justamente queremos avanzar con este tema y estamos viendo las alternativas.

Sds
Mariano

PD: perdón si se mezclo este email en la lista de ayuda, queríamos tratarlo
inicialmente como algo local y luego enviarlo a las listas generales.

>
> 2009/11/2 Mariano Reingart <reingart(at)gmail(dot)com>
>
> 2009/11/2 Emanuel Calvo Franco <postgres(dot)arg(at)gmail(dot)com>
>>
>>> >>
>>>
>>> >> No es mucho quilombo despeus para recopilar las paginas?
>>> >>
>>> >
>>> > No, hay plugins para trac que generan los PDF recopilados
>>> automaticamente
>>> > (en formato artículo o en formato libro). Lo mejor es que se puede
>>> > seleccionar que páginas incorporar, por lo que cada uno se podría armar
>>> su
>>> > propio manual en PDF con los temas que le interesen.
>>> >
>>> > También hay otros plugins en trac para agregarle indices, menúes, tags,
>>> > comentarios, votación, etc., por lo que tendríamos un manual
>>> interactivo y
>>> > automático sin tener que programar nada.
>>> >
>>> > Si la pregunta viene por el lado de "se puede hacer un make ..." la
>>> > respuesta es no, esto no pasa por los archivos fuentes sgml, y no hay
>>> una
>>> > forma fácil de generarlos.
>>> > O sea, perderíamos la flexibilidad que tienen los fuentes de generar
>>> html,
>>> > pdf, hlp (para windows), xml, etc., pero por otro lado, en general solo
>>> se
>>> > esta distribuyendo el html y pdf, cosa que sería posible si usaríamos
>>> el
>>> > trac.
>>> >
>>>
>>> Mmmh creo que seria un punto debil de esto...
>>>
>>
>> Hay plug-ins para generar PDF, Docbooks, DOC, ODS, etc.
>>
>> Aparte, si nos fijamos en las traducciones portugesa, francesa y japonesa,
>> en general ofrecen el HTML y PDF, y algunas como mucho el MAN.
>>
>> Igualmente, el archivo CHM de ayuda para windows calculo que podría ser
>> generado desde los HTML y las páginas MAN podrían ser generadas desde la
>> wiki con herramientas externas (si es que se van a generar, como se puede
>> integrar facilmente a la ayuda de pgadmin3 cambiando la URL, en
>> mi opinión no haría falta).
>>
>>
>>> > Otro detalle es que el formato de trac es muy simplificado, lo que lo
>>> hace
>>> > más manejable, pero por ej no soporta bloques de código con formato (en
>>> trac
>>> > son solo sin formato), por eso no se puede incluir negritas o cursivas
>>> en
>>> > los bloques de código.
>>> > Se podrían usar preprocesadores en html o rst pero me parece que no
>>> vale la
>>> > pena (hoy, quizas mas adelante con tiempo podríamos ajustar estos
>>> detalles).
>>> > Justamente trac simplifica el formato wiki para hacer las cosas más
>>> rápidas
>>> > y simples, y en general, de las páginas que probé, se respeta bastante
>>> el
>>> > "espíritu" del original (con la salvedad del los bloques de código, que
>>> no
>>> > creo que influya mucho)
>>> >
>>>
>>> Esperemos mas feedback de esto...
>>
>>
>> Ya modifiqué trac para que permita formato en bloques PRE, de igual modo
>> como hace la documentación oficial.
>> Prácticamente las páginas traducidas se ven igual que las páginas
>> originales:
>> http://www.arpug.com.ar/trac/wiki/sql-select.html
>> http://www.postgresql.org/docs/8.4/interactive/sql-select.html
>>
>> Sds
>> Mariano
>> http://www.arpug.com.ar/
>>
>
>
>
> --
> atte
>
> juan antonio jaimes valle
> merezco ser pròspero y exitoso, el dinero es mi amigo y se quiere venir
> conmigo, tù tambièn
> toluca, mexico
> juanjava(at)gmail(dot)com
> juanjava(at)yahoo(dot)com
>