Description of problem: Right now, translation reuse between different versions of the one document depends on the version-control mechanism and success and sanity depends largely on writers' and translators' skill in branching and merging within those systems. Reusing translations between different projects is only possible through manual use of the gettext tools and again, comes down to the skill of the person using them. One specific problem is that when documents are not branched carefully, it's very easy for translations to fall out of step with published books, making it very difficult to correct the translation of one particular version of a document without pulling in all the subsequent changes to the document. I've seen translators using scripts to create and apply gettext compendiums to get around these problems, but it would be good if Publican itself could support translation memory to assist reuse, or at the very least, have some way to "freeze" a version of the original language against which translations are applied.
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.