Special cases when using a translation memory in OmegaT
Thread poster: Jan Cerny

Jan Cerny
Austria
Jan 28

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  Identity Verified
France
Local time: 23:02
English to French
+ ...
Alternative translations Jan 30

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
Austria
TOPIC STARTER
Thanks for your help! Jan 30

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  Identity Verified
France
Local time: 23:02
English to French
+ ...
The DTD filter works fine Jan 30

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
Austria
TOPIC STARTER
Workflow Jan 31

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

Advanced search






SDL MultiTerm 2019
Guarantee a unified, consistent and high-quality translation with terminology software by the industry leaders.

SDL MultiTerm 2019 allows translators to create one central location to store and manage multilingual terminology, and with SDL MultiTerm Extract 2019 you can automatically create term lists from your existing documentation to save time.

More info »
WordFinder Unlimited
For clarity and excellence

WordFinder is the leading dictionary service that gives you the words you want anywhere, anytime. Access 260+ dictionaries from the world's leading dictionary publishers in virtually any device. Find the right word anywhere, anytime - online or offline.

More info »



Forums
  • All of ProZ.com
  • Term search
  • Jobs
  • Forums
  • Multiple search