Trados 7.5.0.759: Cyrillic character corrupt during clean-up Thread poster: Alexandra Davidson
|
|---|
Hello all,
We just noticed the following problem when cleaning up cyrillic FrameMaker documents with Trados 7.5.0.759:
The cyrillic "ja" (a flipped-around R) looks okay in the .ttx file as well as in the .mif file that results after converting back with S-Tagger. The TM, however, shows this character as a code, -angle-bracket open- :r38 -angle-bracket closed-.
This renders the TM unusable for future projects, unless I manually correct it after each clean-up... See more Hello all,
We just noticed the following problem when cleaning up cyrillic FrameMaker documents with Trados 7.5.0.759:
The cyrillic "ja" (a flipped-around R) looks okay in the .ttx file as well as in the .mif file that results after converting back with S-Tagger. The TM, however, shows this character as a code, -angle-bracket open- :r38 -angle-bracket closed-.
This renders the TM unusable for future projects, unless I manually correct it after each clean-up.
This seems to happen in Bulgarian, Russian and probably Ukranian as well. Only with FrameMaker documents, however. My Word projects and Interleaf projects, for example, produce okay TM entries.
Has anybody else noticed this problem? If yes, is there a solution?
Many thanks,
Alexandra
[Edited at 2008-01-21 14:20]
[Edited at 2008-01-21 14:20] ▲ Collapse
| | | | Jerzy Czopik 
Germany
Local time: 14:18
Member (2003)
Polish to German
+ ...
| Which Framemaker version? | Jan 21, 2008 |
Please bear in mind, that Trados still does support maximum Framemaker 7.
Framemaker 8 uses Unicode - so mifs from it cannot be processed in SDL Trados 2007.
| | | | | Not possible | Jan 21, 2008 |
Alexandra Davidson wrote:
The cyrillic "ja" (a flipped-around R) looks okay in the .ttx file as well as in the .mif file that results after converting back with S-Tagger. The TM, however, shows this character as a code, -angle-bracket open- :r38 -angle-bracket closed-.
Are you sure the TM entry comes from TTX clean-up? This is the usual problem when somebody converts translated Russian MIF files back to RTF/TTX and tries aligning them with the source RTF/TTX files.
| | | | Jerzy Czopik
Germany
Local time: 14:18
Member (2003)
Polish to German
+ ...
| Exactly - Wojciech is right | Jan 21, 2008 |
switching between processes when processing mif is catastrophal.
When you converted mif to rtf, you have to translate this rtf in Word. If you want to go for the ttx process, convert mif to ttx with S-Tagger. Even if the name looks similar (name.rtf.ttx), the result is very different.
When using S-Tagger for ttx be sure to select proper languages.
Also make your (translators) work easier and do not insert a line break before the <:hr> tag.
| | |
|
|
|
| Went from mif to ttx and back | Jan 22, 2008 |
Hello Jerzy and Wojciech,
The process was as follows:
1. .fm to .mif
2. .mif straight to .ttx
3. translation of .ttx in TagEditor
4. clean-up of .ttx
5. conversion of .ttx back to .mif
6. .mif back to .fm
FrameMaker version is 7.1 or 7.2, not exactly sure, but it is definitely not 8.0.
The translator never worked on any .rtf files as we converted directly to ttx and back. The languages were set appropriately in S... See more Hello Jerzy and Wojciech,
The process was as follows:
1. .fm to .mif
2. .mif straight to .ttx
3. translation of .ttx in TagEditor
4. clean-up of .ttx
5. conversion of .ttx back to .mif
6. .mif back to .fm
FrameMaker version is 7.1 or 7.2, not exactly sure, but it is definitely not 8.0.
The translator never worked on any .rtf files as we converted directly to ttx and back. The languages were set appropriately in S-Tagger (German-Bulgarian, or German-Russian). The only thing that might cause a problem - perhaps? - is the fact that we cleaned on a German system, and not on a system with the target locale. Could that make a difference?
Alexandra ▲ Collapse
| | | | Jerzy Czopik
Germany
Local time: 14:18
Member (2003)
Polish to German
+ ...
| No - I also use German system and produce Polish | Jan 22, 2008 |
Have you tried "Save target as..." instead of cleanup?
Woudl you mind sending me the complete batch of files to take a brief look on them? My mail is info at doku dash trans dot de.
Jerzy
| | | | | Thank you for your offer to take a look! | Jan 22, 2008 |
Jerzy Czopik wrote:
Have you tried "Save target as..." instead of cleanup?
Woudl you mind sending me the complete batch of files to take a brief look on them? My mail is info at doku dash trans dot de.
Jerzy
Hi Jerzy,
Well, we need to fill the TM and that we can only do by doing a clean-up (since we are not translating in-house). And the cleaned up files are okay - it is the TM entries that are corrupt.
As to sending you the files: Thank you for your generous offer to take a look! Unfortunately, we are not allowed to send you the original files (confidentiality agreement with the client), so my colleague, who is managing this project/client, will create a test file probably sometime this afternoon or tomorrow morning which I will then send to you.
Thanks,
Alexandra
| | | | | Coincidence? | Jan 22, 2008 |
Alexandra,
I have seen very similar case today - TM provided by the client is full of codes replacing "ja". I will run some tests on the translated files and let you know the results.
| | |
|
|
|
L10N expert (X)
Brazil
Local time: 09:18
English
| Troubleshooting for <:r38> | Oct 2, 2008 |
I am dealing with the similar problem quite often. All the thoubles start when you are trying to convert mif to ttx. file. The code already appeares in the bilingual data, but the source mif is ok.
The way I am usually resolving it is opening the ttx data with the help of Hidemaru and replacing all the instances of with russian symbol "ja"(simultaneously). After you clean-up such data the TM created does not contain the corrupt character .
I wonder does someone know t... See more I am dealing with the similar problem quite often. All the thoubles start when you are trying to convert mif to ttx. file. The code already appeares in the bilingual data, but the source mif is ok.
The way I am usually resolving it is opening the ttx data with the help of Hidemaru and replacing all the instances of with russian symbol "ja"(simultaneously). After you clean-up such data the TM created does not contain the corrupt character .
I wonder does someone know the way to avoid resulting in after having converted mif to ttx? Maybe some special settings etc. are to be set? Or the "root of the evil" is particulary the version 7.5.0 759 and there is no way out of this situation?
I will gladly welcome any comments/ideas! ▲ Collapse
| | | | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » Trados 7.5.0.759: Cyrillic character corrupt during clean-up | Trados Business Manager Lite | Create customer quotes and invoices from within Trados Studio
Trados Business Manager Lite helps to simplify and speed up some of the daily tasks, such as invoicing and reporting, associated with running your freelance translation business.
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! » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
Translation news related to SDL Trados
