Hello Clytie, thanks for your very interesting and long e-mail. Having translated the Debian web page and several man and help pages for a while, I agree that is indeed different. If you have long paragraphs then looking for diffs (even with previous above) is very tedious (probably some tool could highlight the difference which would make it easier, but still I routinely encounter paragraphs which do not fit the screen, much less with previous). Also in (long) texts content might be split up differently in different languages, e.g. when lists or examples are embedded in paragraphs. Also "missing" content (i.e. when strings are reused from other parts) can be confusing. Still, the po based workflow is nice, especially since it requires no changes from programm translations and when content is shifted within documents (e.g. in relase announcements) then it really safes work. On the other hand, having a VCS as backend and doing diffs also has its advantages. If, e.g., some sentence is updated within a huge paragraph, you can really nicely spot the difference and update the translation quickly. You always have the full context. And "5 lines difference" is a lower barrier than 5 paragraphs difference, where you initially do not know if the entire paragraph was updated or only a word exchanged. The downside for VCS/diff based translations is, of course, that it is highly specific to the project at hand. Regarding XLIFF I've no experience, so I cannot comment. And I would definitly concentrate on more stable and more valuable parts during translation. So translating an introductory document[0], which requires only minor/seldom changes (if any) when the project/software evolves, is much more sensible than working on highly dynamic wiki pages[1]. And translating News really needs dedication: If it is done carefully, then it might take so much time that is no longer news, but if it is done quickly everybody will point fingers (because news are frequently read/discussed). And as already mentioned translating documentation involves much more proofreading. The program strings are seen by the developer(s) every day, but the documentation is (IMHO) often written once and only updated when there is a necessity, but I doubt that the developer(s)/authors read them much afterwards. So the German team routinely sets up patches for the original while translating. So a "back channel" to the original document authors is required. I personally would prefer if there could be two ways to translate: A "direct" approach, using a VCS, where I can get accustomed to the developers/document authors and interact directly with them (e.g. apply fixes, track documentation updates before releases, ...) and a general, e.g. po4a based version, where "drive by translators" can discover and work on the project. Before releasing, these translations (which e.g. in the po4a case do not need changes in the original) could be pulled in, built (the intermediate po files thrown away) and shipped.[2] This would allow me to first help a project as a one or two shot effort and when I see my translation applied, my fixes taken and feedback coming in I could join the group, pull the VCS and work more closely. If not, well, then someone else could take over. Hope my 2 cents help. Greetings Helge [0] Also this document might give the user so much information that he then can use the software/join the project even if some bits are still untranslated. Without it, he might have never tried/encountered the project/software. [1] I firmly believe that wiki pages are out of scope of translation since the wiki concept is for frequent updates by a diverse group of people, so having consistency and stable versions is rather unlikely and the translation probably stays outdated almost all the time. [2] This idea is not mine, I've recently read a developer who wondered if he would need the translation locally (in a VCS) at all. He simply would like an automatic exchange from his VCS to some central translation place, where during development the translators see the new strings/paragraphs and during release all translations available are being pulled. With po4a you could can arrange such that you only set it up once and then simply don't have to care if and how many translations are present (unless they break the build, of course). -- Dr. Helge Kreutzmann debian@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/
Attachment:
signature.asc
Description: Digital signature