Leandro Regueiro escribiu:
2008/5/13 mvillarino <mvillar...@gmail.com>:
2008/5/13, Leandro Regueiro <leandro.regue...@gmail.com>:
Tarrío igual quere deixalo nas túas mans :)
Non teño os coñecimentos precisos para poder afrontar iso.

Vale. E penso eu que Jacobo non quererá que o mareemos.

- Repositorio: de que??
Dos ficheiros po (e posibelmente pot, e docbook, e outros), dos
distintos proxectos, de xeito que desde este poda ser actualizado o
oficial do proxecto en "automático". E que podan os distintos
voluntarios entregar sobre o repositorio local.

Se é isto si que é interesante. Sobre todo porque así non temos que
saber de memoria o sistema de envío de cada proxecto no caso de estar
en varios. Xa vos contara a desfeita que teñen no Fedora cunha chea de
repositorios montados con sistemas diferentes, non?

- Glosario: e logo non se integra no de Mancomún ou no buscatermos se se
libera?
Os glosarios wiki teñen un problema: son wiki. Ferramentas como o
Lokalize empregan un formato algo diferente, é preciso poder obtelos
de xeito que se podan empregar desde as ferramentas coas que se
traduza.

Servidor TBX. Estase falando de se montar algo estilo wiki para
debater termos. Pero o servidor TBX só tería propostas aceptadas, con
xml-rpc para programas e interface web para consultas (coma o
buscatermos).

Perdoade a ignorancia neste tema, con respecto a estas memorias e o modo de interactuar o "soporte loxico" non sería mellor que no canto de consultar o servidor para cada termo se sincronizase a base de datos cunha local cada certo tempo? Ao mellor xa é así como traballa, pero como non teño nin idea de como vai iso comentoo.

- Base de datos de tradución: por isto entendo un servidor de TM, e
logo o de Mancomún?
Por que ter só unha tm? Ademais, entendo que mancomún só quer ter as
cadeas que validen.

Disto estaba intentando eu falar na lista g11n. A nós interesanos
dispor de todas cantas traducións haxa feitas, mal ou ben, de
documentación e de interfaces, pero se eles montan un servidor que
admita todo tipo de cadeas, diferenciando sempre as cadeas validadas,
penso que sería mellor pasar nós de ter outro servidor, porque custa
traballo mantelo e é duplicar traballo, e non habería problema mentres
dispoñamos da posibilidade do backup comunitario do que falamos.

- Interface administrativa: para administrar que?
Os permisos de escrita sobre os ficheiros do repositorio. E dar de
alta/baixa tradutores dentro de cada proxecto, e reservar ficheiros.

Algo estilo Verbum??

- Editor de ficheiros po: por isto entendo un Pootle, supoño que
habería que tirar a fusionar isto co de Mancomún, pero igual os de
Traducif queren manter o seu propio...

O de montar nós cousas que despois temos que administrar e igual
despois non usamos moito, non che me gusta... Se os de Mancomún
cambian de Entrans a Pootle seguro que nos dan bastante liberdade alí.
E contamos ca posibilidade do backup comunitario.

Como di damufo, os das Ciberirmandades non confían moito na
posibilidade do backup comunitario (viñera alguén pola súa parte o
domingo??), co que imos duplicar e triplicar o asunto, e eu penso que
a idea era intentar centralizar un pouco a cousa sen quitarnos a
liberdade. Recursos en Trasno, que mantelos servidores custa traballo,
Marce xa o recoñece...

Non o domingo non puido asistir ninguen de ciberirmadade. Se os de mancomun nos dan liberdade no pootle por min vale. Eu en principio con tal de poder facer o que fixen no entrans de ciberirmandade váleme. Isto foi, crear un proxecto de tradución, subir os po a traducir, traducir desde a web, e finalmente descargar os po para pasalos a .ini posteriormente. En principo no preciso máis.


- Contas shell: ???
Para executar comandos sobre o repositorio no proxecto trasno...
entregas basicamente.

Se se monta ese repositorio si. Pero o do repositorio vai ser un
traballo do demo, a non ser que se consigan uns scripts automatizados
moi ben feitos, e que che digo por experiencia, vai haber que ir
revisando cada x tempo (isto pasaba cos scripts de estatísticas na web
vella de Trasno).

Ata logo,
                    Leandro Regueiro

Responderlle a