Bug 708278

Summary: RFE: support translation memory
Product: [Community] Publican Reporter: Ruediger Landmann <r.landmann>
Component: publicanAssignee: Jeff Fearn <jfearn>
Status: CLOSED NOTABUG QA Contact: tools-bugs <tools-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 2.5CC: ismael, mmcallis, pkovar, publican-list
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 887707 (view as bug list) Environment:
Last Closed: 2013-03-07 23:26:39 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Ruediger Landmann 2011-05-27 02:31:47 EDT
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.
Comment 1 Petr Kovar 2011-05-30 07:25:05 EDT
This might be of interest:

http://translate.sourceforge.net/wiki/toolkit/tmserver
Comment 2 Jeff Fearn 2011-07-08 01:54:06 EDT
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.
Comment 3 Ismael Olea 2012-02-06 09:27:52 EST
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
Comment 4 Jeff Fearn 2012-12-16 19:32:43 EST
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
Comment 5 Ruediger Landmann 2012-12-16 22:12:27 EST
(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!
Comment 6 Jeff Fearn 2013-01-23 04:06:07 EST
(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?
Comment 7 Ruediger Landmann 2013-03-07 23:26:39 EST
(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.