Special cases when using a translation memory in OmegaT
Thread poster: Jan Cerny
Jan Cerny
Jan Cerny
Austria
Jan 28, 2019

Hi,

I am currently trying to create a translation memory from an existing translation (EN -> FR).
For this, I use the alignment tool in OmegaT.
The text resources which need to be translated are defined in DTD and PROPERTIES files.

To make working with the alignment tool easier, we have exported the translatable contents from the source files via script. Now there are just two pairs of files which I use to create a TM:
- one pair of PROPERTIES files ... See more
Hi,

I am currently trying to create a translation memory from an existing translation (EN -> FR).
For this, I use the alignment tool in OmegaT.
The text resources which need to be translated are defined in DTD and PROPERTIES files.

To make working with the alignment tool easier, we have exported the translatable contents from the source files via script. Now there are just two pairs of files which I use to create a TM:
- one pair of PROPERTIES files
- one pair of DTD files


1) Across the PROPERTY file, the same property key is used multiple times, with different values.
The alignment tool in OmegaT always assigns the same value.

Example:

What the existing EN file looks like:

check_name = dog
check_name = cat
check_name = horse

What the existing FR file looks like:

check_name = chien
check_name = chat
check_name = cheval

What the alignment tool produces:

check_name = cheval
check_name = cheval
check_name = cheval

Can this be somehow circumvented?
This problem does not occur when I translate manually in OmegaT - I can assign different values for each "check_name".

2) What is the best approach to deal with individual letters that should be translated differently in several places?
We use individual letters as shortcut keys in our software.
In the FR localisation, an "l" may sometimes be translated as "b", then as an "n" and so on.


Example:

What the existing EN file looks like (DTD entities):

ENTITY name1 "l"
ENTITY name2 "l"
ENTITY name3 "l"

What the existing FR file looks like:

ENTITY name1 "l"
ENTITY name2 "b"
ENTITY name3 "n"

What the alignment tool produces:

ENTITY name1 "n"
ENTITY name2 "n"
ENTITY name3 "n"

This problem also occur swhen I translate manually in OmegaT - I cannot assign different values for each "l".
Can this be somehow circumvented?




[Edited at 2019-01-29 12:25 GMT]
Collapse


 
Didier Briel
Didier Briel  Identity Verified
France
Local time: 11:57
English to French
+ ...
Alternative translations Jan 30, 2019

Jan Cerny wrote:
1) Across the PROPERTY file, the same property key is used multiple times, with different values.
The alignment tool in OmegaT always assigns the same value.

What the existing EN file looks like:

check_name = dog
check_name = cat
check_name = horse

What the existing FR file looks like:

check_name = chien
check_name = chat
check_name = cheval

What the alignment tool produces:

check_name = cheval
check_name = cheval
check_name = cheval

Can this be somehow circumvented?

No.

As you noted, the alignment tool doesn't take alternative translations into account.

That could *perhaps* be developed. You could fill in an RFE for that:
https://sourceforge.net/p/omegat/feature-requests/


This problem does not occur when I translate manually in OmegaT - I can assign different values for each "check_name".

Yes, because you can then assign different alternative translations.


2) What is the best approach to deal with individual letters that should be translated differently in several places?
We use individual letters as shortcut keys in our software.
In the FR localisation, an "l" may sometimes be translated as "b", then as an "n" and so on.


What the existing EN file looks like (DTD entities):

ENTITY name1 "l"
ENTITY name2 "l"
ENTITY name3 "l"

What the existing FR file looks like:

ENTITY name1 "l"
ENTITY name2 "b"
ENTITY name3 "n"

What the alignment tool produces:

ENTITY name1 "n"
ENTITY name2 "n"
ENTITY name3 "n"

This problem also occur swhen I translate manually in OmegaT - I cannot assign different values for each "l".

That's probably because the filter doesn't use IDs to differentiate between alternative translations, but context (i.e., previous and next paragraph).

Can this be somehow circumvented?

The filter could perhaps be improved for that.
In the meantime, you could convert your file to a format where alternative translations are based on an identifier.
See
https://sourceforge.net/p/omegat/svn/HEAD/tree/trunk/docs_devel/Multiple%20translation%20fields%20for%20filters.ods

Didier


 
Jan Cerny
Jan Cerny
Austria
TOPIC STARTER
Thanks for your help! Jan 30, 2019

Thank you a lot for reading through that wall of text and taking the time to answer, Didier!

Didier Briel wrote:
In the meantime, you could convert your file to a format where alternative translations are based on an identifier.
See
https://sourceforge.net/p/omegat/svn/HEAD/tree/trunk/docs_devel/Multiple%20translation%20fields%20for%20filters.ods

Didier


This problem worries me the most actually. How can we translate individual letters differently in several places?

The shortcut keys are defined in DTD files now, as DTD entities.
According to your list, aren't alternative translations for (Mozilla) DTD files already based on an identifier?
Which other file type could I convert my DTD files to?

Thanks a lot in advance for your help and patience
Jan


 
Didier Briel
Didier Briel  Identity Verified
France
Local time: 11:57
English to French
+ ...
The DTD filter works fine Jan 30, 2019

Jan Cerny wrote:

Thank you a lot for reading through that wall of text and taking the time to answer, Didier!

Didier Briel wrote:
In the meantime, you could convert your file to a format where alternative translations are based on an identifier.
See
https://sourceforge.net/p/omegat/svn/HEAD/tree/trunk/docs_devel/Multiple%20translation%20fields%20for%20filters.ods

Didier


This problem worries me the most actually. How can we translate individual letters differently in several places?

The shortcut keys are defined in DTD files now, as DTD entities.
According to your list, aren't alternative translations for (Mozilla) DTD files already based on an identifier?

Yes, my bad.
Since you wrote it wasn't working, I thought the issue was with the filter.

Which other file type could I convert my DTD files to?

No need to. I just tested with your example, and it worked perfectly (in OmegaT, using alternative translations).

Normally, you should have no problem with your DTD file.

Didier


 
Jan Cerny
Jan Cerny
Austria
TOPIC STARTER
Workflow Jan 31, 2019

So, the workflow would be like this:
- align files in OmegaT, but untick the problematic segments (e.g. individual letters)
- translate in OmegaT with the translation memory created in the alignment tool
- indidvidual letters show as untranslated
- create alternative translations for individual letters

At the end, generate translated documents. We can then reuse the translation memory when we update the translation, and it will remember the alternative transl
... See more
So, the workflow would be like this:
- align files in OmegaT, but untick the problematic segments (e.g. individual letters)
- translate in OmegaT with the translation memory created in the alignment tool
- indidvidual letters show as untranslated
- create alternative translations for individual letters

At the end, generate translated documents. We can then reuse the translation memory when we update the translation, and it will remember the alternative translations.

I quickly tried out this approach, and it seems to work. Thanks, Didier!
Collapse


 


There is no moderator assigned specifically to this forum.
To report site rules violations or get help, please contact site staff »


Special cases when using a translation memory in OmegaT






Protemos translation business management system
Create your account in minutes, and start working! 3-month trial for agencies, and free for freelancers!

The system lets you keep client/vendor database, with contacts and rates, manage projects and assign jobs to vendors, issue invoices, track payments, store and manage project files, generate business reports on turnover profit per client/manager etc.

More info »
CafeTran Espresso
You've never met a CAT tool this clever!

Translate faster & easier, using a sophisticated CAT tool built by a translator / developer. Accept jobs from clients who use Trados, MemoQ, Wordfast & major CAT tools. Download and start using CafeTran Espresso -- for free

Buy now! »