Browsing Occitan (post 1500) translation

22.

This chapter groups the Frequently Asked Questions. In fact, most of the questions for now could be formulated that way: "Why is it designed this way, and not that one?" If you think po4a isn't the right answer to documentation translation, you should consider reading this section. If it does not answer your question, please contact us on the E<lt>po4a-devel@lists.alioth.debian.orgE<gt> mailing list. We love feedback.

24.

This chapter presents the specificities of each module from the translator and original author's point of view. Read this to learn the syntax you will encounter when translating stuff in this module, or the rules you should follow in your original document to make translators' life easier.

25.

Actually, this section is not really part of this document. Instead, it is placed in each module's documentation. This helps ensuring that the information is up to date by keeping the documentation and the code together.

29.

I like the idea of open-source software, making it possible for everybody to access to software and to their source code. But being French, I'm well aware that the licensing is not the only restriction to the openness of software: non-translated free software is useless for non-English speakers, and we still have some work to make it available to really everybody out there.

30.

The perception of this situation by the open-source actors did dramatically improve recently. We, as translators, won the first battle and convinced everybody of the translations' importance. But unfortunately, it was the easy part. Now, we have to do the job and actually translate all this stuff.

31.

Actually, open-source software themselves benefit of a rather decent level of translation, thanks to the wonderful gettext tool suite. It is able to extract the strings to translate from the program, present a uniform format to translators, and then use the result of their works at run time to display translated messages to the user.

32.

But the situation is rather different when it comes to documentation. Too often, the translated documentation is not visible enough (not distributed as a part of the program), only partial, or not up to date. This last situation is by far the worst possible one. Outdated translation can reveal worse than no translation at all to the users by describing old program behavior which are not in use anymore.

34.

Translating documentation is not very difficult in itself. Texts are far longer than the messages of the program and thus take longer to be achieved, but no technical skill is really needed to do so. The difficult part comes when you have to maintain your work. Detecting which parts did change and need to be updated is very difficult, error-prone and highly unpleasant. I guess that this explains why so much translated documentation out there are outdated.

36.

So, the whole point of po4a is to make the documentation translation I<maintainable>. The idea is to reuse the gettext methodology to this new field. Like in gettext, texts are extracted from their original locations in order to be presented in a uniform format to the translators. The classical gettext tools help them updating their works when a new release of the original comes out. But to the difference of the classical gettext model, the translations are then re-injected in the structure of the original document so that they can be processed and distributed just like the English version.

37.

Thanks to this, discovering which parts of the document were changed and need an update becomes very easy. Another good point is that the tools will make almost all the work when the structure of the original document gets fundamentally reorganized and when some chapters are moved around, merged or split. By extracting the text to translate from the document structure, it also keeps you away from the text formatting complexity and reduces your chances to get a broken document (even if it does not completely prevent you to do so).