Thunar user documentation infrastructure should be in place for the 0.2.2alpha release. This should be done like with Terminal, using docbook and a special script ThunarHelp (atleast until we have the exo-open stuff in place) to fire up the browser with a given manual page. Daichi, any objections here from the translators POV?
Bug #1368 contains the details about the exo-open progress.
Seems OK for me, at least I found the way to keep updating already translated files with updated/revised original English documents, as for the Right-To-Left languages (Arabic, Hebrew), it still works if the translators give a HTML file (with xfce-rtl.css) to me. So, what we need might be the established way as much as PO file translations, and original English will be allowed everyday minor- tunes.
I would start by adding a user-guide subdir to the docs/ directory, with a subdir "C" for the english version, and one docbook xml file per section, plus the language independent .xsl and .css files. I think I heard of a tool to manage docbook translations using .po files some time ago, but IIRC that was pretty bad. Don't remember the name tho.
> I would start by adding a user-guide subdir to the docs/ directory, > with a subdir "C" for the english version, and one docbook xml file > per section, Is that directory layout change? As far as I know, docs is for API references while doc is for End User Documents. How about discussions among the developers? > plus the language independent .xsl and .css files. No problem if they're global files. > I think I heard of a tool to manage docbook translations using > .po files some time ago, but IIRC that was pretty bad. Don't remember > the name tho. Well, if I'm not wrong, aren't they "po2xml" or "poxml"? They're used in GNOME, KDE. It's a sync' rather than management I expected, no methods to up2date will bring disaster, even a translating translator will have to check where is updated from seeing entire file, what if that will be a new translator, I guess nobody wants to take over... However, it's clearly our (translators) issue, you can write documents without a problem.
(In reply to comment #4) > > I would start by adding a user-guide subdir to the docs/ directory, > > with a subdir "C" for the english version, and one docbook xml file > > per section, > > Is that directory layout change? As far as I know, docs is for API > references while doc is for End User Documents. How about discussions > among the developers? docs/ contains a reference/ subdirectory, which in turn contains the reference manual, so no problem there. > > I think I heard of a tool to manage docbook translations using > > .po files some time ago, but IIRC that was pretty bad. Don't remember > > the name tho. > > Well, if I'm not wrong, aren't they "po2xml" or "poxml"? They're used > in GNOME, KDE. It's a sync' rather than management I expected, no methods > to up2date will bring disaster, even a translating translator will have > to check where is updated from seeing entire file, what if that will be > a new translator, I guess nobody wants to take over... > > However, it's clearly our (translators) issue, you can write documents > without a problem. Oki doki.
So, there's xml2po (GNOME) and po2xml (KDE, see KDE translator docs). What should we use? Both seem to work on .po files.
(In reply to comment #6) > So, there's xml2po (GNOME) and po2xml (KDE, see KDE translator docs). > What should we use? Both seem to work on .po files. * po2xml (C++ program, KDE) Translators: $ split2po C/Thunar.xml de/Thunar.xml > de.po $ poEdit de.po I18N Manager: $ po2xml C/Thunar.xml de.po > de/Thunar.xml * xml2po (Python script, GNOME) Developers: $ xml2po -o Thunar.pot C/Thunar.xml Translators: $ msginit --input=Thunar.pot --locale=de --no-translator $ poEdit de.po I18N Manager: $ xml2po -p de.po C/Thunar.xml > de/Thunar.xml $ xml2po -u de.po C/Thunar.xml The above processes are my rough thoughts, it just shows a way to generate a translated .xml file, directory layout is remained, which should be discussed enough among the document writers (they're called core developers at the same time) if a translating via generated PO file is considered reasonable among us (developers, translators, i18n manager). Unlike GNOME, KDE adopts non-gettext translations, its initial file is .ts suffixed (in this case, Thunar.ts) and po2xml is located in the kdesdk/poxml as one of C++ programs while xml2po is stand-alone within the gnome-doc-utils/xml2po. It's clear which one should be used for me. Anyway, there're you (developer) and me (translator, temporary i18n manager) at least, so a minimum discussion would work.
Well, I'm fine with both of them, but I think that xml2po is preferable. BTW: .ts is the Qt Linguist format.
Ok, I imported initial docs today, in docs/manual/.
Moving to 0.3.0beta1.
Moving to 0.3.2beta2.
Moving to 0.4.0rc1.
Moving to 0.5.0rc2.
Moving to 1.0.0final.
Infrastructure for user manual is in place; initial translations are available already.