DSC08623 4

2.000 Strings, 65 Sprachen, eine Excel-Datei – Zeit für eine bessere Lösung

Wer Software-Strings in vielen Sprachen über Excel-Listen pflegt, stößt schnell an Grenzen, weil Textlängen pro Sprache variieren und die GUI nicht mitwächst. Die Lösung liegt in einem CCMS mit zentral verwalteten String-Objekten, die Übersetzungen konsistent und wiederverwendbar machen, sowie Produkt-Objekten, die zusätzlich einen automatischen Längencheck pro Sprache mitbringen. Beide lassen sich über die Include-Funktion des Editors im Smart Media Creator in die Dokumentation einbinden.

 

Das Problem: Warum eine Excel-Liste für Software-Strings nicht skaliert

Software-Strings – also GUI-Texte wie Buttons, Fehlermeldungen oder Labels – wirken zunächst harmlos: „Speichern“, „Abbrechen“, „Fehler 404“, „Bitte warten…“. In der Praxis sind es aber schnell tausende Strings über mehrere Module und Features hinweg, verteilt auf dutzende Sprachen. Und jede Sprache bringt ihre eigenen Regeln mit. Ein deutscher Button-Text ist oft 20 bis 30 Prozent länger als sein englisches Original. Was im Ausgangstext bequem in ein 80-Pixel-Feld passt, sprengt in der Zielsprache schnell das Layout und niemand merkt es, bis die Software läuft.

In vielen Organisationen läuft die Pflege so ab: Eine zentrale Excel-Tabelle mit 2.000 Strings in 65 Sprachen wächst über unzählige Spalten, und mehrere Personen aktualisieren sie parallel „nur kurz“. Diese Datei geht in die Übersetzung, kommt zurück und wird in die Software eingespielt. Danach beginnt der bekannte Kreislauf. Produktmanager prüfen manuell in jedem Build, ob Übersetzungen noch in Buttons, Dialoge und Masken passen. Ist ein String zu lang, wird die Excel-Datei erneut geöffnet, der String markiert, an die Übersetzungsagentur geschickt und der Zyklus beginnt von vorn.

Das eigentliche Problem liegt darin, dass eine Excel-Datei keine Kontrollmechanismen kennt. Sie prüft keine Zeichenlängen, erkennt keine Duplikate, meldet keine veralteten Übersetzungen und verknüpft String und Dokumentation nicht miteinander. Jede Qualitätssicherung passiert manuell, nachträglich und meist unter Zeitdruck kurz vor einem Release.

 

Was sind Software-Strings und warum sind sie mehr als „nur Text“?

Software-Strings sind alle textlichen GUI-Elemente einer Anwendung: Buttons, Menüpunkte, Fehlermeldungen, Tooltips, Statusmeldungen. Sie sind kein Nebenprodukt der Dokumentation, sondern Teil des eigentlichen Produkterlebnisses. Werden sie isoliert von der übrigen Dokumentation in Excel-Silos gepflegt, entstehen doppelte Pflegeaufwände und Inkonsistenzen zwischen GUI und Handbuch.

Das wirkt sich unmittelbar auf das Vertrauen der Anwender aus. Heißt der Button in der Software „Einstellungen speichern“, im Handbuch aber „Konfiguration sichern“, genügt das oft schon, um Vertrauen in die Dokumentation zu verlieren, gerade in sicherheitskritischen oder regulierten Umgebungen, in denen Anwender jedes Wort genau mit der Oberfläche abgleichen. Bei Software, die international ausgeliefert wird, potenziert sich dieses Risiko. Eine Inkonsistenz in einer Sprache lässt sich noch manuell auffangen, bei 65 Sprachen wird sie zum systemischen Problem.

Ein modernes CCMS-Setup löst das über zwei Objekttypen: String-Objekte (im Smart Media Creator) und Produkt-Objekte (aus dem PIM).

 

Wann sollte man String-Objekte nutzen?

String-Objekte eignen sich, wenn GUI-Texte konsistent in die Content-Struktur eingebunden und in mehreren Sprachen wiederverwendet werden sollen, aber keine strikte Längenbegrenzung der UI-Elemente besteht. Typische Vorteile:

  • Import aus CSV, Excel oder JSON
  • Einbindung über die Include-Funktion im Editor
  • Wiederverwendbarkeit in der gesamten Dokumentation, sprachübergreifend
  • Unterstützung von Fallback-Sprachen, wenn GUI und Doku nicht synchron sind
  • Vollwertige Übersetzbarkeit wie bei allen anderen Inhalten im SMC

Das ist typischerweise dann ausreichend, wenn die Software selbst flexibel auf Textlänge reagiert, wie bei responsiven Web-Oberflächen, in denen sich Textfelder an den Inhalt anpassen, oder bei Fließtext-Elementen wie Hilfetexten und Statusmeldungen, die nicht an ein festes Pixelmaß gebunden sind. GUI und Dokumentation sprechen in Folge dieselbe Sprache. Im wahrsten Sinne des Wortes.

 

Wann sind Produkt-Objekte für Software-Strings die bessere Wahl?

Sobald Software in vielen Sprachen ausgeliefert wird, treten typischerweise dieselben Herausforderungen auf: begrenzter Platz in der GUI etwa bei Buttons und Dialogfeldern, unterschiedliche Textlängen je nach Sprache und ein hoher Abstimmungsaufwand mit Übersetzungsdienstleistern.

Für genau diese Fälle bieten Produkt-Objekte

  • Import von Strings über CSV oder Excel
  • Integrierter Längencheck für alle Sprachen
  • Komfortables Übersetzungsmanagement mit Überblick über alle Sprachversionen

Der Effekt: Längenprobleme werden sichtbar, bevor die Software gebaut wird, nicht erst danach, wenn Korrekturen teuer und aufwendig sind.

Sowohl String-Objekte als auch Produkt-Objekte lassen sich über die Include-Funktion des Editors direkt in die Dokumentation einbinden. So entsteht ein zentraler Pflegepunkt, GUI und Dokumentation bleiben inhaltlich konsistent, eine redundante Übersetzungspflege entfällt, und die Inhalte lassen sich maximal wiederverwenden.

 

Fazit

Software-Strings sind einer der Bereiche, in denen Technische Kommunikation entweder sehr effizient oder sehr schmerzhaft ist, selten etwas dazwischen. Ein modernes CCMS-Setup verbindet GUI-Texte und Dokumentation konsequent, statt sie getrennt zu pflegen und macht aus einem GUI-Text-Problem einen sauber orchestrierten Content-Prozess, der mit jeder neuen Sprache und jedem neuen Release-Zyklus mitwächst.

Mit unserem Smart Media Creator lassen sich String- und Produkt-Objekte genau auf diese Weise zentral verwalten. Wie sich das für Ihre Produkte konkret umsetzen lässt, besprechen wir gerne direkt mit Ihnen. Nehmen Sie einfach über unser Kontaktformular Kontakt zu uns auf.