Software- & App-Lokalisierung

Reines JSON hat keine Kommentare und keine Pluralunterstützung – für Englisch in Ordnung, in der Produktion fragil, sobald Übersetzer geschweifte Apostrophe (' vs '), schmale geschützte Leerzeichen um französische Interpunktion oder deutsche Guillemets (», «) hinzufügen. Ein französischer Übersetzer, der das korrekte L'application mit einem typografischen Apostroph schreibt, wird die linguistische QA bestehen und einen fragilen JSON-Parser zum Absturz bringen. Wir normalisieren Apostrophe beim Import, validieren die UTF-8-BOM-Präsenz und führen einen Syntax-Durchlauf durch, bevor ein Locale ausgeliefert wird.

Android speichert Apostrophe als \' und kaufmännische Und-Zeichen als &. Übersetzer fügen routinemäßig die geschwungenen Zeichen aus Microsoft Word ein, die identisch aussehen und ausgeliefert werden – bis das Layout zur Laufzeit Mojibake anzeigt. Wir verwenden einen benutzerdefinierten XLIFF-Roundtrip für Android-Assets, sodass der Übersetzer niemals rohes XML sieht, und maskieren beim Export erneut.

Das klassische Problem sind Pluralregeln. iOS verwendet CLDR-Pluralkategorien (zero, one, two, few, many, other) über .stringsdict. Ein unerfahrener Übersetzer behandelt die Datei als eins-zu-eins und verliert Pluralvarianten – Ihre deutsche App sagt dann "1 Nachrichten". Wir verwenden einen Plural-bewussten Editor, der jede CLDR-Kategorie so anzeigt, wie sie für das Ziel-Locale erforderlich ist, und den Export verweigert, wenn eine Kategorie fehlt.

.resx akzeptiert XML-Kommentare und eingebettete Code-Referenzen; .properties verwendet standardmäßig ISO-8859-1 (moderne Toolchains unterstützen UTF-8, aber die falsche Kombination liefert immer noch \uXXXX-Escape-Zeichen, die Übersetzer verwirren). Wir erzwingen UTF-8 beim Import und geben native Escape-Zeichen nur zur Build-Zeit aus.

Wann immer möglich, extrahieren wir Quelldateien nach XLIFF 1.2 oder 2.0, übersetzen in unserem Editor mit angehängtem Kontext und mergen neu. Dies ermöglicht es Übersetzern, den Quellkommentar, den Screenshot und die Einschränkung (Zeichenlimit, ICU-Pluralform, RTL-Spiegelungs-Flag) zu sehen, ohne jemals die Quelldatei anzufassen. Die Build-Pipeline mergt zurück in das Format, das Ihre Entwickler committed haben.

{count, plural,
 one {# friend}
 few {# friends}
 many {# friends}
 other {# friends}
}

Das ist in Englisch, Französisch und Deutsch in Ordnung. Im Arabischen benötigen Sie zero, one, two, few, many, other. Im Polnischen deckt few nur 2-4 ab, wenn die letzte Ziffer 2-4 ist und die Zahl nicht 12-14 ist – Polnisch hat ungefähr 5 Pluralkategorien. Walisisch hat seine eigene. Wir übersetzen gegen den CLDR-Pluralregel-Satz für jedes Locale, nicht gegen das englische Template.

Spanisch, Italienisch und Paschto müssen alle wissen, ob das Subjekt maskulin, feminin oder neutral ist, um das Verb zu flektieren. Eine naive Übersetzung von "You are invited" ist standardmäßig maskulin; eine weibliche Benutzerin sieht fehlerhafte Grammatik in 50 % der Locales. ICUs select behandelt dies:

{gender, select,
 female {Estás invitada}
 male {Estás invitado}
 other {Te han invitado}
}

Wenn Ihr Datenmodell das Geschlecht nicht erfasst, ist der sichere Weg der geschlechtsneutrale other-Zweig. Wir markieren geschlechtliche Strings in der Quellprüfung, sodass Ihr Team entscheiden kann, ob das Geschlecht erfasst, standardmäßig neutral verwendet oder Varianten ausgeliefert werden sollen – bevor das Übersetzungsbudget gebunden ist.

App Store- und Google Play-Bewertungen weisen routinemäßig auf fehlerhafte Plurale hin: "App ist fehlerhaft, zeigt '1 messages'". Ein-Stern-Bewertungen häufen sich und verschlechtern das Ranking. Die Behebung von Pluralen nach dem Launch kostet mehr als ICU-bewusste Übersetzung im Voraus.

Der häufigste Produktionsfehler: Entwickler schreiben margin-left: 16px statt margin-inline-start: 16px. In einem Links-nach-rechts-Locale sind sie identisch. Im Arabischen fixiert das erste den Rand auf der linken Bildschirmseite; das zweite dreht korrekt nach rechts. Wir prüfen Ihr Stylesheet auf physische Eigenschaften (left, right, padding-left, border-right), bevor wir die Strings anfassen.

Ein arabischer Absatz, der einen englischen Markennamen, eine URL oder eine Ziffer erwähnt, wird zu einem gemischt-direktionalen String. Browser behandeln dies mit dem Unicode Bidirectional Algorithm, aber der Algorithmus ist heuristisch und macht es in vorhersehbaren Fällen falsch – am häufigsten, wenn ein Satz mit einer lateinischen Zahl oder Interpunktion endet. Wir fügen U+202A/U+202C (LRE/PDF)-Markierungen ein oder verwenden <bdi>-Tags um undurchsichtige Token wie Benutzernamen und Produkt-IDs.

Pfeil-Icons, das "Zurück"-Chevron, Rückgängig und Wiederholen, Slider-Richtungen, Fortschrittsbalken – jedes Richtungs-Icon benötigt eine RTL-Variante oder eine CSS-Transformation. Lucide und Heroicons haben RTL-bewusste Varianten; Material's Icon-Set erfordert eine Mirror-Klasse. Wir katalogisieren jedes Richtungs-Icon in Ihrem Design-System und markieren alle, die im Audit nicht gespiegelt sind.

Westliche Font-Stacks fehlen routinemäßig arabische Glyphen – Helvetica Neue, Inter und Roboto benötigen alle einen arabischen Fallback. Die Systemvorgabe (Geeza Pro auf iOS, Noto Naskh Arabic auf Android) rendert, aber die Zeilenhöhe ist falsch und das Kerning ist schlecht. Wir testen das Rendering auf den tatsächlichen Geräten, die Ihre Benutzer haben – nicht nur Chrome auf macOS – und markieren Font-Stack-Fixes als Teil der Pseudo-Locale-Prüfung.

Arabisch ist unser größtes einzelnes Sprachpaar. Unsere Schwestermarke arabictranslation.co.uk liefert arabische Lokalisierung seit 2012 aus. Die RTL-Zuschläge, die die meisten UK-Agenturen erheben (20-30 %), spiegeln wider, dass dies für sie ungewöhnliche Arbeit ist; es ist die Arbeit, die wir am meisten machen. Wir erheben keinen RTL-Zuschlag.

Passt zu den meisten SaaS-Teams. Ein GitHub-Webhook wird bei jedem Push zu main ausgelöst. Unser Service inspiziert das Diff auf neue oder geänderte Strings, entwirft die Locales, sendet sie zur Prüfung an einen Linguisten und öffnet einen Return-PR. Branch Protection stellt sicher, dass der PR nicht vor der Prüfung gemergt werden kann. Typische End-to-End-Zeit: 18-24 Stunden für 35 Sprachen bei einem 200-String-Commit.

Wenn Ihr Team es vorzieht, dass Locale-Änderungen durch Ihr Build-System (CircleCI, GitHub Actions, GitLab Runners) fließen, stellen wir ein CLI bereit: lingosecure pull zieht die neuesten Übersetzungen als Build-Schritt in Ihr Repository, lingosecure push lädt alle Source-String-Änderungen zur Übersetzung hoch. Wird von Teams verwendet, die Release Trains betreiben und keine Übersetzungs-PRs in ihrem Flow wollen.

Wenn Sie bereits ein TMS haben, übernehmen wir gerne die Linguisten-Ebene darin – Ihre Entwickler pushen weiterhin Strings in das TMS, unsere Linguisten übersetzen innerhalb des TMS, und der TMS-Sync läuft wie immer. Null Workflow-Änderung für Ihre Engineers. Der Vorteil: ein Lieferant statt ein TMS-Abonnement, ein Roster von Freelancern und ein Vendor für regulierte Inhalte zusammenzufügen.

Alle drei Patterns teilen ein Prinzip: Ihr Translation Memory gehört Ihnen. Jedes übersetzte Segment wird in Ihr TM geloggt, das wir innerhalb von LingoSecure hosten oder auf Anfrage in Ihr TMS exportieren. Wenn Sie nächstes Jahr den Vendor wechseln, geht das TM mit Ihnen. Es gibt kein Lock-in.

Wir pinnen Translation Memory auf Produkt-Releases. Ihr v4.2 wird niemals versehentlich mit den übersetzten Strings von v4.1 ausgeliefert. Wenn Ihr Team ein Release zurücksetzen muss, wird das TM damit zurückgesetzt. Das ist wichtig für regulierte Produkte, bei denen eine übersetzte Offenlegung mit der englischen Version übereinstimmen muss, gegen die sie genehmigt wurde.

• Trunkierung — Buttons, die "OK" passen, aber nicht "Aceptar"
• Hart codierte Strings — alles, was nicht in t eingewickelt ist
• Konkatenations-Bugs — "Hello " + username wird in Sprachen mit unterschiedlicher Wortstellung kaputtgehen
• Fixed-Width-Annahmen — Datumsauswahl, Dropdowns, Navigations-Tabs
• Font-Fallbacks — Text, der sich in Rechtecke verwandelt, weil die Schrift Latin Extended-A nicht abdeckt
• RTL-Flip-Bugs — jedes Richtungs-Icon und Layout dreht sich in Pseudo-RTL

Wir liefern den Pseudo-Locale-Build als Storybook-Deployment oder als Feature-Branch, gegen den Ihr QA-Team testen kann. Das Defekt-Log geht direkt in Ihr Linear, Jira oder GitHub Issues. Wir beheben die Locale-seitigen Probleme; Ihr Team behebt die produktseitigen, bevor Sie für ein einziges Wort menschlicher Übersetzung bezahlen.

Für ausgereifte Produkte führen wir einen zusätzlichen Durchlauf durch: Jeder Bildschirm wird auf Englisch, Pseudo-EN, Deutsch, Arabisch und Chinesisch erfasst, und die Diffs werden verglichen. Layout-Regressionen zeigen sich sofort. Derselbe Workflow läuft gegen jeden PR, wenn Sie es als GitHub Action möchten.

Jeder String passiert einen qualifizierten Linguisten, bevor er das Portal verlässt. Wir verwenden spezialisierten Linguisten, um den ersten Entwurf zu beschleunigen, aber kein String wird jemals ohne menschlichen Signoff ausgeliefert. Wenn Sie rohe MT aus Kostengründen wollen, sind AWS Translate und unsere Pipeline API ausgezeichnet – wir helfen Ihnen beim Einrichten, aber wir werden unseren Namen nicht auf die Ausgabe setzen.

Ein 50-String-Notfall-Fix in 4 Stunden ist realistisch für die meisten wichtigen Locales. Ein 5.000-String-Produkt-Launch in 24 Stunden ist nicht realistisch, und wir werden uns nicht dazu verpflichten. Wir planen rückwärts von Ihrem Release-Datum mit eingebautem QA-Puffer; wenn Ihre Timeline kürzer ist, sagen wir Ihnen, was tatsächlich erreichbar ist.

Die meisten UK-Agenturen routen Arabisch an ein Studio in Kairo oder Beirut. Wir übersetzen intern mit benannten Linguisten. Dieselbe Person, die Ihre v1-Strings übersetzt hat, ist die Person, die v4.7 übersetzt. Terminologie-Konsistenz ist eine Funktion von Kontinuität; Kontinuität erfordert, nicht unterzuvergeben.