On Fri, Mar 23, 2012 at 5:11 AM, Tim Sutton <[email protected]> wrote: > @Paolo Corti - can you confirm if it was also your idea to use gettext > approach and if that works with the web translation platform you will > implement? By the way newer versions of QtLinguist can deal with .po > files too so there is a nice desktop gui option for doing translations > too. >
Hi Tim yes you are definitely correct, latest versions of Sphinx (from 1.1) supports internationalization, and that is exactly the approach I have been considering with Paolo Cavallini and Alessandro Pasotti. The idea is to keep the set of the original documentation as *.rst files in English (big effort will be needed here, because as far as I can see, only the Python CB is in .rst format at this time). At that point, via sphinx, we will generate the templates files (*.po) for each of the language we want to translate the documentation in (via the gettext option of sphinx-build). We can keep the set of the original *.rst English files and all the *.po files in git, and commit modification all along the way (so it will also possible to generate a whole set of html/pdf documentation for each version/release). I can figure out two approach for managing the edit of the *.po files: * a very basic workflow, where each translator will use her/his favourite editor (vi/gedit/notepad whatever), modify the *.po files and then commit to git * put in production a web application like Pootle [1], that will provide a very convenient user interface for translators, and provide at the same time useful stats regarding the ongoing translations. In this case we will have a scheduled job getting latest version of .rst/.po files and commit them to git (note that using this approach we will avoid to translators the git overhead as well). Finally we could schedule a job (or a git hock to trigger the process as soon as some new .rst/.po file is committed), getting latest doc from git, compile the *.po files to *.mo files (with the msgfmt command), compile the Sphinx project. Then we will have an html (and pdf) documentation set for each language we are supporting and still with the same job we could deploy it to the QGIS web site. The Pootle application looks to me a bit heavy, but very handy, so it would be a very convenient way for editors to manage their work. And, by the way, it is a full Django project, so at this time, for answering a previous question of you, we will not be able to integrate it in the same project where we are keeping the plugin platform. Unless we don't want to dig in source and adapt it for our situation, but not sure is the best approach and how long does this take (need to investigate more here!). @Jean Roc, I hope we can meet in Lyon, still not sure that I will be able to join the HF, but in the case I am not able to be in France, I will definitely attend it remotely from Italy, and I am pretty sure we can still get the desired results ;) ciao P [1] http://translate.sourceforge.net/wiki/pootle/index?redirect=1 -- Paolo Corti Geospatial software developer web: http://www.paolocorti.net twitter: @capooti skype: capooti _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
