Hello Marion & Christophe: Thank you on the first hand. Linkedin: https://linkd.in/Ljjt8L Twitter : https://twitter.com/luigy_tspg
On 17 April 2016 at 07:20, Marion & Christophe JAILLET <christophe.jail...@wanadoo.fr> wrote: > > Hi docs@, > > a few weeks ago someone, a discussion [1] has started about using a web based application in order to translate our documentation. > The proposal was about Transifex [2]. > > Another tool that looks similar is provided by the Apache Foundation itself: https://translate.apache.org/ > It works with Pootle. (see [3] which is the version used on t.a.o) > > I don't know yet if our doc format is convenient for it. > At least, it can use .po files. > Tools exist to convert docbook (more or less our doc format) to .po files, handle translation and generate back some docbook document. > I have already used something called 'po4a' for such a process. > > The workflow would be: > main documentation in XML files --> generate/manage pot file --> generate/manage po files --> translate using t.a.o --> generate updated XML files for each languages --> generate html/pdf... as we actually do > > > The pros: > - IMHO, following changes with po files is easier for translators > - trunk/2.4.x are mainly the same files. They could be merged in the same po files to avoid duplication of translation effort > - using po files keeps the document structure itself (formatting, links, ...). So the translator only has to focus on the translation of the text itself > - translating is easier and can be shared easily between different people > - easy access to translation statistic > - svn integration > > The cons: > - the translator doesn't have a global view of the file he is working on > - new tools and new intermediate file format > - more complex doc generation process > > > Anyway, I think that our translation workflow is too complex. > Apart from the French translation (huge thanks, Lucien) and Spanish which sees some interest and looks promising (Thanks and welcome Luis), everything else is more or less dead. > So anything that ease access to new translators is a win. > > > > We would like to have your feedback about the actual doc translation process: > - Do you think that using XML files for the translation is convenient? Pros, Cons... > - Do you think that using .po files would help to keep track of translation changes? > - Do you think that using a web based interface for translation would be a win? > Any thought? > > > CJ > > > [1] http://marc.info/?t=145716544900002&r=1&w=2 > [2] http://www.transifex.com > [3] http://docs.translatehouse.org/projects/pootle/en/stable-2.5.1/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org > For additional commands, e-mail: docs-h...@httpd.apache.org > On the other hand, I want to share my opinion over this. The way we are translating things now @httpd looks good, i mean the xml files (for me was easy to follow up the format etc) and the build process is totally automated ( o.f.c. we would need to update stuff). But the main thing for keeping track and getting things going on the translation, (for non committers its hard). Files in the mailing list sometimes get lost, on the threads. So talking about what you suggest, Transifex its good, but how we will integrate the *.po files and make the Jenkins or what ever (i actually know how we build the web, just when we do the ./build ) anyway we should not discard this new stuff, at least if it will make our workflow easy and faster. If we are integrating Pootle, i'm not sure if you need to learn too python (Django), i have been using the framework and its very flexible and it can i think integrarte with what we are doing, but the thing is, we need to create the Django backend and structure for the web, and... well i'm not sure how much time we will need on this (correct me if i'm wrong) so resuming i see the following: 1. Transifex will be a pain in the ass for ASF because the build process i guess. 2. Pootle it could be the best way if we would like to move forwards, in the way Django works. 3. We will need to update the backend (i guess) to integrate this tools, maybe use Jenkins or other automate deploy software. Best regards. Luis Gil de Bernabé. PD: if at any time will this be going to be any option, i would be pleased to help on the back-end work ;) -- Luis J.G
