Bug 708278

This might be of interest:

http://translate.sourceforge.net/wiki/toolkit/tmserver

Please open a separate bug for 'have some way to "freeze" a version' since it's unrelated to translation memory.

Please supply more detail in what is required with regard to translation memory. i.e integration with specific translation memory tools or standards, or implementing a system in Publican specifically for documentation. If the later then please supply details of the functionality required.

Have you considered using OmegaT as a CAT tool instead of the tricky way of PO files?

It's being used by proffesionals translators everywhere, manages Docbook, supports TMs and is in Fedora: https://admin.fedoraproject.org/pkgdb/acls/name/OmegaT

My proposal for this is to make tmx2po and po2tmx actions that convert the PO files used by Publican to and from TMX [1] files. Getting the TMX files to and from other services would be outside the scope of this bug.

1: http://en.wikipedia.org/wiki/Translation_Memory_eXchange

(In reply to comment #2)

> Please supply more detail in what is required with regard to translation
> memory. i.e integration with specific translation memory tools or standards,
> or implementing a system in Publican specifically for documentation. If the
> later then please supply details of the functionality required.

Because:

1. we tend to author books in multiple XML files joined by xi:includes and

2. Publican uses a separate PO file for each XML file in the source language

it means that the same string might occur multiple times in multiple PO files within the one book. This was a specific complaint from Fedora translators when we moved to using Publican, because they were used to translating one giant PO file generated from all the XML files in a book. (Obviously, this didn't scale well though).

The core functionality for this RFE is a way to propagate translations from one PO file in a book to the other PO files in that same book. Of course, if the mechanism allowed translations to propagate between multiple books/projects, that would be even more useful!

(In reply to comment #5)
> (In reply to comment #2)
> 
> > Please supply more detail in what is required with regard to translation
> > memory. i.e integration with specific translation memory tools or standards,
> > or implementing a system in Publican specifically for documentation. If the
> > later then please supply details of the functionality required.
> 
> Because:
> 
> 1. we tend to author books in multiple XML files joined by xi:includes and
> 
> 2. Publican uses a separate PO file for each XML file in the source language
> 
> it means that the same string might occur multiple times in multiple PO
> files within the one book. This was a specific complaint from Fedora
> translators when we moved to using Publican, because they were used to
> translating one giant PO file generated from all the XML files in a book.
> (Obviously, this didn't scale well though).
> 
> The core functionality for this RFE is a way to propagate translations from
> one PO file in a book to the other PO files in that same book. Of course, if
> the mechanism allowed translations to propagate between multiple
> books/projects, that would be even more useful!

Are you are asking for Publican to act as a translation memory system?

(In reply to comment #6)

> Are you are asking for Publican to act as a translation memory system?

Only in an extremely limited sense. However, I take the point that it would be more advantageous to look to an external TMS to connect to. Closing for further research.