Mobile menu

German umlauts etc. appear as tags in TagEditor
Thread poster: Valeri Serikov

Valeri Serikov  Identity Verified
Local time: 04:41
Member (2003)
English to Russian
+ ...
Mar 13, 2006

Hi all,

Wanted to find out whether there is any trick to show German special characters as they are in TagEditor instead of them being shown as tags.

Windows XP SP2, English UI, Russian locale, English keyboard installed.

Direct link Reply with quote

Ralf Lemster  Identity Verified
Local time: 03:41
English to German
+ ...
Moving the topic... Mar 13, 2006 SDL Trados Support - please use this forum to post topics related to SDL and/or Trados.

Direct link Reply with quote

Yuri Dubrov  Identity Verified
Russian Federation
Local time: 04:41
English to Russian
+ ...
copied from Mar 13, 2006

I have the same problem.

KnowHow: Troubleshooting incorrect extended characters in translation memory or target segments
Applies to: Translator's Workbench 1.x, Translator's Workbench 2.x/TagEditor, Translator's Workbench 3/TagEditor, Translator's Workbench 5/5.5, Translator's Workbench 6
OS: Windows 2000, Windows 95, Windows 98, Windows NT Server, Windows NT- 4.0, Windows XP


Note: The symptoms described in this article should not occur in TRADOS 6.5.2 or later. The only occur in earlier TRADOS releases.

In an existing translation memory, extended characters, for instance from Eastern European languages such as Czech or Polish, display fine. However, they are incorrectly transferred to the target segment in your document. In some cases, they may even display incorrectly in Translator's Workbench as well.
In the translation unit, the incorrect extended characters are typically formatted with local font overrides, e.g. "This is an {\f23 д} (a umlaut)."
Font translation settings do not seem to have any impact on the problem, the characters are always incorrectly transferred to the target segment in your document.

The translation memory's font table is at least partly corrupted. More specifically, the codepage information for the font in question is incorrect.

In a translation memory's font table, fonts appear as follows:

{\f23 \fswiss\fprq2 \fcharset0 Arial CE;}

\fcharset denotes the codepage. In the example above, the codepage is the English one, with the effect that the font Arial CE displays any extended characters incorrectly.

This can happen when the Word documents being translated contain corrupt font tables due to a problem in Word. Incorrect information is then passed to the font table in the translation memory.


You can fix the incorrect font table in the translation memory by exporting, externally modifying the exported file and re-importing it into a new translation memory. Follow these steps:

Export the translation memory to a text file (.txt).
Open the text file in any text editor, e.g. Notepad or WordPad. For bigger files, use a text editor that will accept large text files.
Identify the fonts that should show extended characters but in fact use \fcharset0 (English codepage) in the section of the RTF preamble. For instance, if the font name "Arial CE" uses \fcharset0, correct it to \fcharset238 using the information below.
Correct any other \fcharset values using the list below for reference.
Create a new translation memory. Do not copy the translation memory setup from the existing translation memory, since this copies the font table as well. Instead, re-create the translation memory setup manually.
Import the corrected text file into this new translation memory.
From now on, extended characters should display fine both in the translation memory and in your documents.

To quickly find out whether incorrect extended characters are caused by a damaged font table in the translation memory, use the font preview feature in Workbench as follows:

From the File menu, choose Properties.
In the fonts list, hightlight the font in question.

If the text in the Example box reads "The quick brown fox", the font table contains the English codepage for this font. If, instead, you see several extended characters, the codepage information in the font table is correct.


Font families and codepages:

Western fonts: \fcharset0

Baltic fonts: \fcharset186
Central European CE fonts: \fcharset238
Cyrillic fonts: \fcharset204
Greek fonts: \fcharset161
Turkish fonts: \fcharset162

Arabic fonts: \fcharset178
Hebrew fonts: \fcharset177

Shift JIS fonts: \fcharset128
Hangul fonts: \fcharset129
GB2312 fonts: \fcharset134
Chinese Big5 fonts: \fcharset136
Thai fonts: \fcharset222

STATUS: Closed

Article ID: 780
Created: Thursday, July 06, 2000 7:05:36 PM
Last updated: Thursday, June 30, 2005 11:57:41 AM

Direct link Reply with quote
SST  Identity Verified
Local time: 11:11
English to Ukrainian
+ ...
Corrupt Cyrillic output (target text) Jul 28, 2007

I've used your excellent post to try and rectify a problem in my Trados.
I haven't worked it out yet, hence I'm asking for help

I haven't had any problems with my English>Ukrainian (Cyrillic) Trados translations in a number of files and then, all of a sudden, my target text started looking funny, e.g. Ìåðåæåâèé ðåæèì.

The English (source) text is written in Times New Roman.
When I export my TM memory and open it in Notepad, I can see some fonts have "fcharset0" value, e.g.
{\f1 \fmodern\fprq1 \fcharset0 Courier New;}
{\f2 \fswiss\fprq2 \fcharset0 Arial;}

There's a number of lines for Times New Roman:
{\f8 \froman\fprq2 \fcharset238 Times New Roman CE;}
{\f9 \froman\fprq2 \fcharset161 Times New Roman Greek;}
{\f10 \froman\fprq2 \fcharset162 Times New Roman Tur;}
{\f11 \froman\fprq2 \fcharset177 Times New Roman (Hebrew);}
{\f12 \froman\fprq2 \fcharset178 Times New Roman (Arabic);}
{\f13 \froman\fprq2 \fcharset186 Times New Roman Baltic;}
{\f14 \froman\fprq2 \fcharset163 Times New Roman (Vietnamese);}

I can't see the line dedicated to Cyrillic - as you suggested below, Cyrillic should be fcharset204, right?
Is this the problem then?

At the same time, if I create my own English text in Times New Roman, my target text in Ukrainian looks just fine!

Could it be the client's corrupt source text? If I copy-paste all the source text into the new file, it doesn't solve the problem.

Any suggestions will be appreciated.

Direct link Reply with quote

To report site rules violations or get help, contact a site moderator:

You can also contact site staff by submitting a support request »

German umlauts etc. appear as tags in TagEditor

Advanced search

Translation news related to SDL Trados

Manage your TMs and Terms ... and boost your translation business

Are you ready for something fresh in the industry? TM-Town is a unique new site for you -- the freelance translator -- to store, manage and share translation memories (TMs) and glossaries...and potentially meet new clients on the basis of your prior work.

More info »
SDL MultiTerm 2015
Guarantee a unified, consistent and high-quality translation with terminology software.

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

More info »

All of
  • All of
  • Term search
  • Jobs