GIMP 2.6 is out …
GIMP Help Browser using webkit.
… and the Manual will be next.
The current plan is to release the last tarball of the manual suitable for the GIMP 2.4 release a.s.a.p. It should still be installed by most of the desktops until GIMP 2.6 is provided by the distributions.
We’re currently still working heavily to migrate most of the translations from DocBook/XML to po/gettext. The biggest problem for us is the missing 1:1 mapping between reference language to a translation. We’re trying to minimize the site effects when splitting the translations and using xml2po’s reuse option for a content migration. Ulf D. Ehlert wrote a Python script, which will splitt the reference language from the translation “as good as possible”.
As long this script is ready and we’re able to migrate, we’re up to speed to document GIMP 2.6.
GIMP Manual Build Architecture Status
GIMP Help Browser using webkit.
We’re currently in a huge overhaul of the build system the GIMP Manual is using (see my last post).
Ulf D. Ehlert works on a custom Makefile, which can extract the strings, creates automatically pot files, as well as po files and is able to create localized DocBook/XML. He’s still working hard to improve the script. Thanks to publican – it helped to reuse some of the Makefile code the project provides to create pot and po files automatically (I still need to communicate that with the publican folks – sorry guys).
I hope we can merge his changes as soon as possible with a current xml2po branch to test it. Hopefully other developers around will help to improve the Makefile.
We’ve still performance issues. Creating the HTML pages for the translations takes ages, and it will take more when we switch to support gettext.
LGM Aftermath LGM Aftermath
or: How I learned how to write documentation the hard way.
Current situation
The current situation for the GIMP user manual is this:
- The user manual is written using DocBook/XML.
- Each DocBook/XML file contains all translations separated by lang attributes.
When I joined the documentation project back in 2003, we thought, that the separation of author and translator brings unnecessary barriers:
- Authors can only write in one language (reference language)
- Translators can only translate a string given by the reference language and are enforced to do only that (translation slaves)
Our model (mixing translations with the actual documentation writing) was superior, because the classic model of translators didn’t exist anymore. Every writer was free to describe a GIMP function or GIMP model in it’s own way. The only problem we had: No translator was able to join us, because the writing of DocBook/XML scared everyone away. Additionally – in the meantime – maintaining all translations became a burden for everyone.
Libre Grafics Meeting 2008
I saw dark clouds coming upon me this time. Me as the one who still defended our model of creating documentation for GIMP. Andy Fitzsimon used the GIMP manual as a bad example of an unmaintainable documentation in his talk. He is right, as well as all the other guys who tried to tell us.
Back in 2007 I couldn’t see, that our way we create documentation was supposed to fail:
- lack of contributors a.k.a translators. Writing XML as a translator is hard. There are a lot of tools available for translators which provide a very nice and usable GUI.
- not focusing on one language which will be the reference language.
You can only concentrate on one thing and not on eleven other manuals simultaneously. - and the worst: Trying to invent the wheel.
Tools and Architecture is already developed by others. They do have disadvantages though, but you can’t solve them by creating something new and just thinking, it will be better than other tools because it’s new.
I learned my lesson. We now switch to a system using one reference language and creating translations from this language. Andy Fitzsimon introduced publican as a possible basis, as well as Erik Gebers introducing Scenari. Both noteworthy tools which are interesting to look at.
