WinCC Text Distributor: Resolving ??? in Multilingual Runtime

WinCC Text Distributor: Resolving '???' Placeholders in Multilingual Runtime

When a WinCC project is extended with a new language, designers frequently observe that message texts (alarm lists, message classes, archive comments) translate correctly at runtime, while graphic screen elements — static text fields, button labels, IO field captions, group display text — display only ?????? regardless of the selected language flag. The root cause is the separation of text storage between the centralized Text Library and the per-object Picture Object text table, and the symptom resolves only by running the Text Distributor editor with a Unicode-compliant import file.

Problem Details: Symptom Matrix

This symptom pattern is the diagnostic fingerprint: any text defined inside the Graphics Designer picture tree is stored locally on the object instance and is independent of the Text Library editor. Adding a language tab in the Text Library only registers a new language column for the central table — it does not retroactively create language entries on the thousands of picture-bound objects in the PDL files.

Root Cause Analysis

WinCC (V7.x and the TIA Portal WinCC Unified runtime) maintains two parallel text storage systems that must both be localized to render correctly:

1. Text Library (centralized text catalog) — A database-resident, language-indexed table holding all translatable message strings, user archive text, and any text linked to an object via the Text ID mechanism. Languages are managed as tabs (e.g., English, German, French, custom). When a new tab is created, a column is added; the WinCC Explorer automatically generates a language pair ID used at runtime to swap text. The display is driven by the project's configured Runtime language setting.
2. Picture Object Texts (per-PDL storage) — Every static text, button, checkbox, radio button, IO field output value, and status display maintains its own internal multilingual text table. This table is populated at design time, not from the Text Library, and is what feeds the on-screen rendering layer when the Runtime language is toggled.

The ????? rendering means the Graphics Designer cannot find a text row for the currently active Language Code in the picture's local table. A blank or missing entry — not a font problem — causes the placeholder render. A language dongle is not required for project languages created in the editor; it is required only for switching the OS / runtime UI language. This is a common misdiagnosis.

Language Architecture (WinCC V7.5 / WinCC Unified)

WinCC V7.5 maintains an OS-level language dependency table. According to the Siemens runtime documentation, language switching is parameterized at the Computer Properties → Parameter tab in the WinCC Explorer; the active language is selected by the user via the flag icons in the runtime title bar or by the SetLanguage API. The WinCC V7.5 "How to Change Language in Runtime" manual describes the procedure to bind the language-change event to a function or a hotkey.

In WinCC Unified (TIA Portal V20/V21), the language model uses a two-level hierarchy: Project languages (used during engineering) and Runtime languages (used at runtime). The Siemens TIA documentation on "Languages in WinCC (RT Unified)" clarifies that the two levels are completely independent: a project language can be created in the engineering environment without being activated as a runtime language. For alarm-related text, the Locale IDs of the supported languages (RT Unified) page documents the BCP-47 style locale codes used by the AlarmSubscription.Language property at runtime.

Prerequisites

• WinCC V7.4 / V7.5 SPx (procedure identical for V7.0+) or WinCC Unified V16+ (different tool flow — see Section 8).
• Edit privileges on the WinCC project (local project, not remote-compiled).
• The Text Distributor start entry (WinCC Explorer → Tools → Text Distributor). This tool is part of the standard installation — no separate license.
• Microsoft Excel or any text editor capable of producing Unicode (UTF-16 LE, BOM-marked) plain text with .txt extension. Notepad.exe with "Save as: Unicode" works; CSV saved directly from Excel will corrupt non-ASCII characters.
• Read/write access to the project's \TxtDist\ working folder (auto-created on first export).

Step-by-Step Resolution Procedure

Step 1 — Verify All Project Languages Are Activated

1. Open the WinCC Explorer.
2. Right-click the project root → Languages.
3. Confirm every required language is checked. Unchecked languages are not available to the Text Distributor and will produce ????.
4. Click Set as Project Language for the editing language; the additional tabs become the target languages.

Step 2 — Run the Text Distributor Export

1. Launch the Text Distributor from WinCC Explorer → Tools → Text Distributor.
2. In the Source Language dropdown, select the language used as the master (typically English).
3. In Target Language, select the language that is showing ????.
4. Click Export → File (txt, csv).
5. Choose a destination. The default folder is <ProjectPath>\TxtDist\; the file is named with the language code, e.g. 0009.txt for English or 0007.txt for German.
6. The Languages.csv file is also written into the same folder and must be preserved; it maps the language IDs used in the export to the language tabs in the project. Do not edit this file manually.

Step 3 — Translate in Excel and Save as Unicode TXT

1. Open the exported .txt file directly in Excel (drag-drop or File → Open → All Files → Unicode Text).
2. Translate every empty cell in the target-language column. The source-language column must remain untouched.
3. Critical encoding step: Do not save back as CSV or XLSX. Use File → Save As → Save as type: "Text (Tab delimited) (*.txt)" → Save. Excel will prompt about format incompatibility — confirm Keep current format. Alternatively, open the file in Notepad and re-save with encoding Unicode (UTF-16 LE with BOM).
4. Verify the file in a hex editor: the first two bytes must be FF FE (UTF-16 LE BOM). A UTF-8 BOM (EF BB BF) is also acceptable in newer WinCC versions but UTF-16 LE is the canonical Siemens format and is the safest choice for legacy V7.x systems.

Step 4 — Re-Import Through the Text Distributor

1. Return to the Text Distributor in WinCC Explorer.
2. Click Import → From File. Navigate to the same \TxtDist\ folder and select the translated .txt file.
3. The Text Distributor parses the file, matches text IDs to picture objects, and writes the translated strings back into the PDL picture objects.
4. On completion, the tool writes an ImportResult.xml into the same \TxtDist\ folder. Open this file after every import — it lists every entry that failed to import, with a reason (e.g., "Picture not found", "Object property not available", "Encoding error").

Step 5 — Diagnose a Failed Import (ImportResult.xml)

The ImportResult.xml schema is straightforward. Typical failure entries and their meanings:

<Error>PICTURE_NOT_FOUND</Error>

Encoding Pitfalls and Common Import Errors

The most frequent import failure — and the one most often misattributed to a dongle or a project corruption — is the encoding mismatch. A translation workflow that uses Excel's "Save" (which writes CSV with system code page encoding) or saves as .csv (which writes UTF-8 without BOM) will appear to load into the Text Distributor but will fail the row-by-row match against the binary picture objects, producing an empty ImportResult.xml with all entries marked as "no change". The fix is always the same: a clean Unicode TXT file with the BOM intact.

Round-Trip Verification Test

Before committing a full project import, perform a single-picture round trip:

1. Pick one picture with ten static text objects.
2. Export → translate two entries → import.
3. Inspect the PDL in the Graphics Designer — the translated strings should be visible in the property view for those two objects.
4. Activate the project and toggle language in Runtime. If those two strings render correctly and the others still show ????, the import path is healthy and a full export/import cycle will succeed.

Verification in Runtime

After a successful import, complete the following verification sequence:

1. Close the WinCC Explorer if open.
2. Open Graphics Designer → Tools → Check Consistency. Any remaining ???? entries will be flagged.
3. Activate the project.
4. In Runtime, click the target language flag (or use the configured hotkey / SetLanguage API call).
5. Navigate every process picture and visually confirm all text fields render in the target language.
6. Trigger at least one alarm and verify the message list row also renders in the target language (this confirms the Text Library side of the localization is still intact after the import).

WinCC Unified (TIA Portal) Equivalent Procedure

The Text Distributor is a WinCC V7.x tool. In WinCC Unified, the multilingual export/import is done from the project tree → Languages & Resources → Project languages with the Export translations and Import translations commands. The same rule applies: texts entered on screens via the Text property of an HMI tag / IO field / button are stored in the screen object and must be translated per screen via the language switching dropdown in the screen editor's properties pane. The TIA Portal V20 documentation on languages describes the project-language vs runtime-language separation, and the V21 locale ID list documents the runtime language codes used by API consumers.

A useful diagnostic in Unified: open any screen, switch the editor language dropdown to the target language, and check whether the text field is empty (untranslated) or shows the placeholder. If empty, the property value has never been entered for that language. Right-click → Translate text brings up the per-language editor.

Troubleshooting Matrix

Performance and Project-Size Considerations

For projects with more than ~2,000 picture objects, the Text Distributor export produces files in the 1–10 MB range. Excel handles these, but the re-save step can take 30–60 seconds. For very large multi-language projects (10+ languages, 20,000+ text entries), a non-Excel workflow is faster: export to the Unicode .txt, then use a find/replace workflow in a dedicated editor such as Notepad++ (Encoding: UCS-2 LE BOM) or a script that operates on the \TxtDist\ files directly. The result must remain a Unicode TXT; the import engine does not accept XLSX or XLS.

Field Commissioning Tip

FAQ