I am with you Roman on po thing. It doesn't fit well with all
translation work. My pet peeve is " Dialog" string when I
was translating en to ru menus, because the word to go in the
placeholder has to change in ru from just "" according to
language grammar. I also found in po I lose context (e.g. "see
previous step" when all po entries are not in order)
Anyway, I agree with Nickolay about tracking changes. I wrote a perl
script that picks up changes in en as they come. For that to work I
needed a extra folder to compare against after svn update and a file
to list all .xml files with the last svn revision that I looked at
them. Seems to work for me.
About new contributors. Is it possible to write a script that, given a
language and an xml file/directory, takes all en elements and
recreates them with a new language and en text. That way the new guy
just searches for lang="his language" and translates en without
worrying about xml markup? Once he is done, he turns on his language
on the section level. Or is the docbook schema too complex to take
care of every case?
I also agree 30 languages won't fit in a single file.
Vitaly.
Heh, time to update the patch for xml2po, I'm afraid it won't even apply
cleanly :)
http://bugzilla.gnome.org/show_bug.cgi?id=369510
Anyhow, 30 languages won't fit into a single xml file.
Correct and I was thinking again about this issue from time to time.
IMHO the major problem is, that editing the XML scares away new authors
who want to translate the manual. We could split all the files into a
single file for each translation, but that sounds more scary to me, than
using the po approach.
As I already stated, we don't have an English reference (yet). Thinking
of the po approach means, that authors first have to create the English
reference paragraphs (or pages) and translate it.
But as far as I know (and still knew if I remember the discussion to the
bug), if we use the xml2po patch, than we have to switch entirely to
xml2po. Is that correct? Does the updated xml file use the images
created for that translation?
We've to make a decision here then. If the authors want to switch to
xml2po, we first need to:
- set a reference language (which is probably English)
- a migration policy to not loose any of the translations, how do we
deal with special cases (like the glossary, etc)
- a migration date
I fought always of the against-using-po side, but I'm getting tired of
this discussion. It still has a lot of advantages to gain but I still
fear we're loosing the collaboration, which we thought to have in our
manual, but never worked out very well....
Greetings,
--
Roman Joost
