On Fri, Nov 02, 2007 at 09:19:37AM +0100, Daniel Nylander wrote:

Can I, in some way, convert all the XML data to PO gettext, and then back again?

I'm used to work on other GNOME documentation which works in this way. Manually hacking in the XML data is, to be honest, not a very good way when it comes to tracking changes in the original strings.

No you can't and it's because we don't have 'original strings'. The GNOME documentation relies on a reference language (English that is), but we don't have a reference language. There is currently no maintainer for English (although Authors of other languages still maintain it). That's why we hack the XML data ...

Greetings,

? ???, 02/11/2007 ? 10:20 +0100, Roman Joost ?????:

On Fri, Nov 02, 2007 at 09:19:37AM +0100, Daniel Nylander wrote:

Can I, in some way, convert all the XML data to PO gettext, and then back again?

I'm used to work on other GNOME documentation which works in this way. Manually hacking in the XML data is, to be honest, not a very good way when it comes to tracking changes in the original strings.

No you can't and it's because we don't have 'original strings'. The GNOME documentation relies on a reference language (English that is), but we don't have a reference language. There is currently no maintainer for English (although Authors of other languages still maintain it). That's why we hack the XML data ...

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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: =?koi8-r?Q?=FC=D4=C1?= =?koi8-r?Q?_=DE=C1=D3=D4=D8?= =?koi8-r?Q?_=D3=CF=CF=C2=DD=C5=CE=C9=D1?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=C1=CE=C1?= =?koi8-r?Q?_=C3=C9=C6=D2=CF=D7=CF=CA?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=D8=C0?= Url : /lists/gimp-docs/attachments/20071103/3e820ad4/attachment.bin

On Sat, Nov 03, 2007 at 01:38:45AM +0300, Nickolay V. Shmyrev wrote:

? ???, 02/11/2007 ? 10:20 +0100, Roman Joost ?????:

On Fri, Nov 02, 2007 at 09:19:37AM +0100, Daniel Nylander wrote:

Can I, in some way, convert all the XML data to PO gettext, and then back again?

I'm used to work on other GNOME documentation which works in this way. Manually hacking in the XML data is, to be honest, not a very good way when it comes to tracking changes in the original strings.

No you can't and it's because we don't have 'original strings'. The GNOME documentation relies on a reference language (English that is), but we don't have a reference language. There is currently no maintainer for English (although Authors of other languages still maintain it). That's why we hack the XML data ...

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,