Bug 708278 - RFE: support translation memory
RFE: support translation memory
Status: CLOSED NOTABUG
Product: Publican
Classification: Community
Component: publican (Show other bugs)
2.5
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jeff Fearn
tools-bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-27 02:31 EDT by Ruediger Landmann
Modified: 2013-03-07 23:26 EST (History)
4 users (show)

See Also:
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: ---


Attachments (Terms of Use)

  None (edit)
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.

Note You need to log in before you can comment on or make changes to this bug.