Softwarelokalisierung: Software, Apps und Gerätesteuerungen in die Zielsprache bringen
- ISO 17100 + ISO 9001, geprüft durch DEKRA
- strings.xml, .strings, .resx, .po, XLIFF, JSON und YAML
- Platzhalter, Pluralformen und Stringlängen werden geprüft
- Translation Memory je Produkt: Releases nur als Differenz
Für Softwarehäuser und den Maschinen- und Anlagenbau
Branchensoftware und Web-Anwendungen kommen meist mit laufenden Releases, Gerätesteuerungen gemeinsam mit der Betriebsanleitung in einem Terminologiebestand. Marketing-Website und Onlineshop gehören zur Website-Lokalisierung.
Die Ressourcendatei wird vor dem Angebot geprüft
- Prüfung und Angebot
Sichtung der Ressourcendatei: Platzhalter, Pluralformen, zusammengesetzte Strings, nicht ausgelagerte Texte. Danach das Angebot je Sprache mit Preis und Liefertermin, in der Regel noch am selben Werktag.
Was Sie liefernRessourcendatei, wenn möglich Screenshots zu mehrdeutigen Strings
- Terminologie
Produktbegriffe festlegen, nicht zu übersetzende Bezeichnungen sperren, Abgleich mit vorhandener Dokumentation
Was Sie liefernGlossar, falls vorhanden; übersetzte Anleitung, falls vorhanden
- Übersetzung im Format
Direkt in der Ressourcendatei, mit automatischer Prüfung von Platzhaltern, Längen und Sonderzeichen
Was Sie liefernNichts
- Revision und Freigabe
Pflichtrevision nach ISO 17100 durch eine zweite Fachkraft, Text gegen Text. Die Sichtprüfung im lokalisierten Build oder anhand von Screenshots je Sprache liegt bei Ihrem Team.
Was Sie liefernRückmeldungen aus Ihrer Sichtprüfung, etwa Strings, die gekürzt werden müssen
Bei Folge-Releases bearbeiten und berechnen wir nur neue und geänderte Strings; Terminologie und Translation Memory wachsen mit. Dafür genügt ein Differenz-Export oder die vollständige Datei, aus der wir die Differenz ermitteln.
Platzhalter und Stringlängen werden automatisch geprüft
Übersetzt wird direkt in der Ressourcendatei, eine automatische Prüfung kontrolliert Platzhalter, Längen und Sonderzeichen. Danach revidiert eine zweite Fachkraft nach ISO 17100 Text gegen Text. Die Sichtprüfung im lokalisierten Build oder anhand von Screenshots je Sprache liegt bei Ihrem Team. Der Prozess ist nach ISO 17100 und ISO 9001 zertifiziert, geprüft durch DEKRA.
Schicken Sie Datei oder Textprobe und nennen Sie Zielsprache und Verwendungszweck, das Angebot kommt in der Regel noch am selben Werktag.
Bereits übersetzte Strings senken die Kosten
Preisbestimmend sind Sprachkombination, Anzahl der Sprachen, Aufwand für Kontextklärung und der Anteil bereits übersetzter Strings aus früheren Releases. Ob die Software internationalisiert ist, gehört vor das Angebot, weil es den Aufwand verändert.
- Abrechnung nach Normzeile mit 50 bis 55 Schriftzeichen einschließlich Leerzeichen, nicht nach Dateigröße
- Eilige Termine: vereinbaren wir mit dem Angebot; eine Lieferung am selben Tag ist nur in Ausnahmefällen möglich, weil die Pflichtrevision nach ISO 17100 durch eine zweite Fachkraft Zeit braucht.
Details zur Kalkulation: Preisgestaltung und Angebot
L10n passt Oberflächen an den Zielmarkt an
Softwarelokalisierung, abgekürzt L10n, ist die Anpassung einer Software, App oder Gerätesteuerung an Sprache, Konventionen und technische Vorgaben eines Zielmarkts. Sie unterscheidet sich von der Dokumentübersetzung an drei Stellen: Der Text liegt nicht als Fließtext vor, sondern als einzelne Zeichenketten in Ressourcendateien; jede Zeichenkette hat eine Längenbegrenzung, die das Layout setzt; und Platzhalter, Pluralregeln und Datumsformate müssen in der Zielsprache funktionieren, nicht nur richtig klingen. Eurolingua bearbeitet Lokalisierungen nach ISO 17100 mit Pflichtrevision durch eine zweite Fachkraft, direkt im Ressourcenformat und mit Translation Memory über alle Releases. Websites und Onlineshops mit Rechtstexten, Suchbegriffen und Shop-Strings gehören zur Website-Lokalisierung.
Lokalisierte Inhalte, Formate, Prüfpunkte und Angebot als Tabelle anzeigen (acht Zeilen)Tabelle einklappen
| Kriterium | Details |
|---|---|
| Was lokalisiert wird | Benutzeroberflächen (Menüs, Schaltflächen, Dialoge), Fehler- und Statusmeldungen, Onboarding- und Hilfetexte, Gerätesteuerungen und Bedienpanels (HMI), Firmware-Anzeigetexte, App-Store-Beschreibungen, Web-Frontends von SaaS-Anwendungen |
| Formate | strings.xml (Android), .strings und String Catalogs (iOS/macOS), .resx (.NET), .po/.pot (gettext), JSON (i18next und ähnliche), .properties (Java), XLIFF 1.2 und 2.x, CSV/Excel-Exporte aus CMS und Shopsystemen |
| Geprüft wird | Platzhalter und Variablen unverändert, Pluralformen je Sprache vollständig, Stringlängen gegen Vorgabe, Sonderzeichen und Escape-Sequenzen, Konsistenz mit Betriebsanleitung und Hilfe |
| Zertifizierung | ISO 17100 + ISO 9001 (DEKRA, gültig bis 02.01.2028 bzw. 07.03.2027) |
| Wiederverwendung | Translation Memory und Terminologiedatenbank je Produkt; bei Releases werden nur neue und geänderte Strings berechnet |
| Abgrenzung | Websites und Onlineshops: Website-Lokalisierung. Betriebsanleitung und Handbuch: Technik. Kampagnen und Slogans: Wirtschaft |
| Standort | Hohe Straße 45, 44139 Dortmund, persönliche Abstimmung Mo–Do 8:30–15:30, Fr 8:30–14:30 |
| Angebot | Unverbindlich, in der Regel noch am selben Werktag nach Sicht auf die Ressourcendatei |
Übersetzung oder Lokalisierung: der Unterschied an drei Stellen im Code
Eine Übersetzung überträgt Text. Eine Lokalisierung sorgt dafür, dass der übertragene Text an der Stelle funktioniert, an der die Software ihn ausgibt. Der Unterschied ist kein Grad an Sorgfalt, sondern eine andere Arbeitsgrundlage: Der Lokalisierer sieht nicht den Satz, sondern die Zeichenkette mit ihrem Schlüssel, ihrer Längenvorgabe und ihren Variablen. Internationalisierung (i18n) ist der vorgelagerte Schritt auf Entwicklungsseite, der die Software überhaupt lokalisierbar macht: Texte aus dem Code herauslösen, Formate nicht fest verdrahten, Pluralregeln vorsehen.
| Schritt | Wer macht es | Konkret | Wenn es fehlt |
|---|---|---|---|
| Internationalisierung (i18n) | Entwicklung | Strings in Ressourcendateien auslagern, Datum, Zahl und Währung über Locale-Funktionen ausgeben, Pluralformen als Kategorien anlegen, Layout für längere Texte und Rechts-nach-links-Schrift vorsehen | Die Software lässt sich nicht lokalisieren, sondern nur neu programmieren. Kein Übersetzungsbüro kann das nachholen |
| Übersetzung | Fachübersetzer | Bedeutung jeder Zeichenkette in der Zielsprache, mit Kontext (Wo erscheint sie? Schaltfläche oder Überschrift? Welche Variable steht im Platzhalter?) | „Save“ wird zu „Sparen“ statt „Speichern“, „Order“ zu „Reihenfolge“ statt „Bestellung“ |
| Lokalisierung (L10n) | Fachübersetzer und Revisor; die Sichtprüfung im Build übernimmt Ihre Entwicklung | Stringlängen einhalten, Pluralformen je Sprache ausfüllen, Platzhalter erhalten, Sortierreihenfolgen und Tastenkürzel prüfen, Bilder mit Text erkennen, Ergebnis im Build ansehen | Text läuft über die Schaltfläche, „1 Dateien“, Absturz durch beschädigten Platzhalter, Screenshot in der Hilfe zeigt die deutsche Oberfläche |
Klären Sie deshalb vor dem Angebot, ob Ihre Software internationalisiert ist. Wenn Datumsformate oder Meldungen im Code zusammengesetzt werden, ist der Aufwand ein anderer, und wir sagen das, bevor die erste Zeichenkette übersetzt ist.
Strings, Platzhalter und Pluralformen: was in Software anders ist als in Dokumenten
Drei Eigenschaften von Software-Text erzeugen Fehler, die in Dokumenten nicht vorkommen: Zeichenketten dehnen sich in der Zielsprache aus, und zwar umso stärker, je kürzer sie sind; Platzhalter wie %1$s, {count} oder %d müssen exakt erhalten bleiben und an der grammatisch richtigen Stelle stehen; und die Anzahl der Pluralformen ist je Sprache verschieden, was die Software vorsehen muss, bevor der Übersetzer sie ausfüllen kann.
Textausdehnung: warum Schaltflächen brechen und Absätze nicht
Bei der Übersetzung aus dem Englischen wächst deutscher Text im Durchschnitt um rund 30 Prozent. Für die Oberfläche ist der Durchschnitt aber unerheblich. Entscheidend ist, dass kurze Strings prozentual am stärksten wachsen: Ein Wort mit fünf Zeichen kann sich in der Zielsprache verdoppeln oder verdreifachen, ein Text mit über 70 Zeichen wächst um rund 30 Prozent. Deshalb brechen Menüpunkte, Schaltflächen und Tabellenköpfe, während Hilfetexte problemlos passen.
| Länge des englischen Strings | Zusätzlicher Platz, mit dem zu rechnen ist | Typische Stelle |
|---|---|---|
| bis 10 Zeichen | 100 bis 200 Prozent | Schaltflächen, Menüpunkte, Tab-Beschriftungen |
| 11 bis 20 Zeichen | 80 bis 100 Prozent | Feldbezeichnungen, Tabellenköpfe |
| 21 bis 30 Zeichen | 60 bis 80 Prozent | Statusmeldungen, Tooltips |
| 31 bis 70 Zeichen | 40 bis 70 Prozent | Dialogtexte, Warnungen |
| über 70 Zeichen | rund 30 Prozent | Hilfetexte, Beschreibungen |
Für Deutsch als Ausgangssprache gilt die Umkehrung: Englisch wird kürzer, romanische Sprachen und Russisch werden länger, Chinesisch und Japanisch brauchen weniger Zeichen, aber mehr Zeilenhöhe. Wenn Sie eine Längenvorgabe je String mitliefern, wird sie bei der Übersetzung geprüft; wenn nicht, zeigt erst der Build, wo Text überläuft.
Pluralformen: eine Frage, die vor der Übersetzung entschieden werden muss
Deutsch und Englisch kennen zwei Pluralkategorien (eine Datei, zwei Dateien). Viele Zielsprachen kennen mehr, und die Kategorie hängt von der Zahl ab:
| Sprache | Kategorien | Beispiel für „n Dateien“ |
|---|---|---|
| Deutsch, Englisch, Niederländisch, Schwedisch | 2 (one, other) | 1 Datei / 2 Dateien |
| Französisch, Portugiesisch (Brasilien) | 3 (one, many, other), 0 und 1 zählen als Singular | 0 fichier, 1 fichier / 2 fichiers |
| Polnisch, Russisch, Ukrainisch, Tschechisch, Kroatisch | 3 bis 4 (one, few, many, other) | 1 plik / 2 bis 4 pliki / 5 bis 21 plików, 22 pliki |
| Arabisch | 6 (zero, one, two, few, many, other) | Eigene Form für 0, 1, 2, 3 bis 10, 11 bis 99, ab 100 |
| Chinesisch, Japanisch, Vietnamesisch | 1 (other) | Keine Pluralflexion, Zahl steht allein |
Eine Software, die „Dateien“ als eine Zeichenkette mit eingesetzter Zahl bildet („%d Dateien“), lässt sich ins Polnische oder Arabische nicht korrekt lokalisieren, unabhängig von der Übersetzungsqualität. Die Pluralkategorien müssen in der Ressourcendatei als Formen vorliegen (Android plurals, iOS stringsdict oder String Catalog, ICU MessageFormat, gettext Plural-Forms), damit der Übersetzer sie ausfüllen kann. Diese Frage klären wir beim Angebot, nicht bei der Reklamation.
Platzhalter und Wortstellung
%1$s hat %2$d Dateien in %3$s gespeichert darf in der Zielsprache die Platzhalter umstellen, aber nicht verändern. Sprachen mit anderer Satzstellung brauchen nummerierte Platzhalter; ohne Nummerierung (%s hat %d Dateien) ist die Reihenfolge festgeschrieben, und die Übersetzung wird grammatisch falsch oder die Software stürzt ab, wenn ein Typ nicht passt. Das prüfen wir automatisiert vor der Lieferung; nicht nummerierte Platzhalter melden wir vor Beginn zurück.
Ressourcendateien und Übergabe: Strings direkt im Format übersetzen lassen
Der häufigste vermeidbare Aufwand in Lokalisierungsprojekten ist der Umweg über Word oder Excel: Strings werden exportiert, als Fließtext übersetzt und von Hand zurückgetragen. Dabei gehen Schlüssel, Kommentare und Platzhalter verloren, und jeder Rücktransfer ist eine Fehlerquelle. Wir übersetzen direkt in der Ressourcendatei; Schlüssel, Struktur und Kommentare bleiben unverändert, nur der Zieltext ändert sich.
Acht Ressourcenformate mit Plattform und Übergabehinweis als Tabelle anzeigenTabelle einklappen
| Format | Plattform | Worauf es bei der Übergabe ankommt |
|---|---|---|
| strings.xml | Android | plurals und string-array mitliefern; translatable="false" setzen für Produktnamen und Schlüssel, die nicht übersetzt werden sollen |
| .strings, .stringsdict, String Catalog (.xcstrings) | iOS, macOS | Kommentare des Entwicklers im Catalog sind der wichtigste Kontext; Pluralvarianten im Catalog anlegen, bevor übersetzt wird |
| .resx | .NET, Windows | Kulturspezifische Dateien je Sprache (.de-DE.resx, .pl-PL.resx); Kommentarspalte nutzen |
| .po / .pot | gettext (PHP, Python, WordPress, Linux) | Plural-Forms-Header je Sprache korrekt setzen; msgctxt für gleichlautende Strings mit verschiedener Bedeutung |
| JSON | Web-Frontends (i18next, Vue I18n, Angular) | ICU-Syntax für Plural und Auswahl beibehalten; verschachtelte Schlüssel nicht abflachen |
| .properties | Java | Unicode-Escapes und Zeilenumbrüche erhalten; Kodierung angeben |
| XLIFF 1.2 / 2.x | Austauschformat aus TMS, CMS und Entwicklungsumgebungen | Bestes Übergabeformat, weil Quelle, Ziel, Kontext und Status in einer Datei liegen; Rückimport ohne Handarbeit |
| CSV, Excel | Shopsysteme, CMS-Exporte, Gerätesteuerungen | Nur als letzte Option: Spalte für Schlüssel, Spalte für Längenlimit, Spalte für Kontext ergänzen; Zellinhalte nicht umbrechen |
Sie arbeiten mit einem anderen Ressourcenformat? Nennen Sie uns das Format oder schicken Sie eine Beispieldatei. Datei senden
Was Sie mitliefern sollten, damit die Übersetzung beim ersten Mal passt: die Ressourcendatei im Original, Entwicklerkommentare oder Screenshots zu mehrdeutigen Strings, die Längenvorgaben, wo sie existieren, ein Glossar der Produktbegriffe, die nicht übersetzt werden, und wenn vorhanden die bereits übersetzte Betriebsanleitung, damit Software und Dokumentation dieselben Begriffe verwenden.
Website oder Software: was Ihr Projekt braucht
Die Grenze verläuft nicht zwischen Browser und Desktop, sondern zwischen Ressourcendatei und Seiteninhalt. Alles, was ein Besucher als Seite aufruft, also Unternehmensseiten, Onlineshops, Produkttexte, Meta-Daten, Rechtstexte und Transaktionsmails, gehört zur Website-Lokalisierung mit ihren eigenen Regeln für Suchbegriffe, hreflang und Sprachpflichten des Zielmarkts. Alles, was als Zeichenkette mit Schlüssel in einer Ressourcendatei liegt, gehört hierher, auch wenn es im Browser läuft: Die Oberfläche einer SaaS-Anwendung ist Software, ihre Marketing-Website ist Website. Wer beides hat, vergibt zwei Aufträge mit einem gemeinsamen Terminologiebestand.
Drei Fehlerklassen in Lokalisierungsprojekten
Bei Lokalisierungsaufträgen sind drei Fehlerklassen typisch. Keine davon ist ein Übersetzungsfehler im engeren Sinn; alle drei entstehen an der Grenze zwischen Text und Software. Wir prüfen diese Grenze mit, bevor die Dateien zurückgehen.
Fehlerklasse 1: Software und Anleitung nennen dieselbe Funktion verschieden
Die Betriebsanleitung wurde vor zwei Jahren übersetzt, die Steuerungssoftware jetzt, von einem anderen Anbieter oder ohne die Anleitung als Referenz. Der Menüpunkt heißt in der Software anders als in der Anleitung, die auf ihn verweist. Der Nutzer sucht am Gerät nach einem Begriff, den es dort nicht gibt. Das ist derselbe Fehler, den die Technik-Seite aus der Gegenrichtung beschreibt. Abhilfe: Die Anzeigetexte der Software sind die führende Terminologie, die Anleitung folgt ihr; beide Bestände in einem Translation Memory.
Fehlerklasse 2: Zusammengesetzte Meldungen
Die Software baut eine Meldung aus Teilen: "Datei" + name + "wurde" + status. Jeder Teil wird korrekt übersetzt. In der Zielsprache verlangt die Grammatik eine andere Reihenfolge oder eine Flexion, die vom eingesetzten Wert abhängt. Das Ergebnis ist eine Meldung, die aus richtigen Wörtern in falscher Ordnung besteht. Das lässt sich nicht durch Übersetzung beheben, sondern nur durch einen vollständigen String mit Platzhaltern. Wir melden solche Stellen vor Beginn zurück, weil die Entscheidung bei der Entwicklung liegt.
Fehlerklasse 3: Der Build wird nicht angesehen
Die Ressourcendatei ist vollständig und korrekt übersetzt. Freigegeben wird die Datei, nicht die laufende Software. Im Build läuft Text über Schaltflächen, ein Datum erscheint in deutscher Schreibweise, weil es im Code formatiert wird, und ein Screenshot in der Hilfe zeigt die deutsche Oberfläche. Abhilfe: Prüfung im lokalisierten Build oder mit Screenshots je Sprache als fester Schritt Ihrer Freigabe. Die Revision nach ISO 17100 prüft Text gegen Text; die Sichtprüfung in der laufenden Software ist ein eigener Schritt, den nur Ihr Team mit dem Build leisten kann.
Continuous Localization: je Release nur neue Strings
Bei Software gibt es keinen Abschlusstermin, sondern Releases. Continuous Localization heißt, dass nach dem ersten vollständigen Durchlauf bei jedem Release nur die neuen und geänderten Strings übersetzt werden, alles Unveränderte kommt aus dem Translation Memory. Voraussetzung ist ein Austauschformat, aus dem sich die Differenz ermitteln lässt, in der Regel XLIFF oder der Export eines Translation-Management-Systems.
Zur Leistung: Terminologiepflege.
Software und Websites lokalisieren in Dortmund und dem Ruhrgebiet
Dortmund hat sich vom Stahl- und Bierstandort zu einem der größeren IT-Standorte in Nordrhein-Westfalen entwickelt: die Technische Universität mit ihrer Informatikfakultät, der Technologiepark, die Fraunhofer-Institute ISST und IML sowie Softwarehäuser und IT-Dienstleister mit Hauptsitz in der Stadt. Dazu kommt der Maschinen- und Anlagenbau der Region, dessen Steuerungssoftware in dieselben Sprachen muss wie seine Betriebsanleitungen.
Häufige Auftragstypen aus der Region:
- Gerätesteuerungen und HMI-Texte aus dem Maschinen- und Anlagenbau, gemeinsam mit der Betriebsanleitung in einem Terminologiebestand
- Branchensoftware und Web-Anwendungen von Dortmunder Softwarehäusern für Kunden in Europa, meist mit laufenden Releases
- SaaS-Oberflächen und Web-Frontends mit JSON-Ressourcen, bei denen die Marketing-Website getrennt über die Website-Lokalisierung läuft
- App-Store-Texte und Onboarding für Apps mit Verbraucherkontakt, seit dem BFSG mit Blick auf barrierefreie Beschriftungen
Persönliche Abstimmung: Hohe Straße 45, 44139 Dortmund-Kreuzviertel, Mo–Do 8:30–15:30 Uhr, Fr 8:30–14:30 Uhr. Erreichbar mit U-Bahn Saarlandstraße (U46). Für Lokalisierungsprojekte ist die persönliche Abstimmung vor allem zu Beginn sinnvoll, wenn Terminologie und Übergabeformat festgelegt werden.
Häufige Fragen zu Software- und Website-Lokalisierung
Was versteht man unter Lokalisierung, und was unterscheidet sie von der Übersetzung?
Lokalisierung ist die Anpassung einer Software, App oder Gerätesteuerung an Sprache, Konventionen und Technik eines Zielmarkts. Übersetzung ist der Teil davon, der Text überträgt. Hinzu kommen Stringlängen, Platzhalter, Pluralformen, Datums- und Zahlenformate, Sortierung, Rechts-nach-links-Schrift und die Prüfung im laufenden Programm. Der vorgelagerte Schritt auf Entwicklungsseite, der das alles erst möglich macht, heißt Internationalisierung (i18n); Lokalisierung wird als L10n abgekürzt, nach der Zahl der Buchstaben zwischen L und n.
Können Sie Strings direkt in unserer Ressourcendatei übersetzen?
Ja, das ist der Normalfall. strings.xml, String Catalogs, .resx, .po, JSON, .properties und XLIFF werden im Format bearbeitet; Schlüssel, Kommentare und Platzhalter bleiben unverändert. Der Rückimport in Ihr Projekt erfolgt ohne manuelles Übertragen. Ein Export nach Word oder Excel ist nicht nötig und wäre der Weg mit den meisten Fehlern.
Wie funktioniert Continuous Localization?
Nach dem ersten vollständigen Durchlauf werden bei jedem Release nur die neuen und geänderten Strings übersetzt. Alles Unveränderte kommt aus dem Translation Memory und wird nicht erneut berechnet. Dafür braucht es ein Austauschformat, aus dem die Differenz ermittelt werden kann, in der Regel XLIFF oder der Export Ihres Translation-Management-Systems. Der Lieferrhythmus folgt Ihrem Release-Zyklus; bei kurzen Zyklen vereinbaren wir feste Übergabezeitpunkte.
Wer prüft, ob die Übersetzung in der Software richtig angezeigt wird?
Die Revision nach ISO 17100 durch eine zweite Fachkraft ist Pflicht und prüft Text gegen Text. Was sie nicht sieht, zeigt erst die laufende Software: Textüberläufe, abgeschnittene Beschriftungen, falsch formatierte Datumsangaben, Bilder mit Text. Diese Sichtprüfung im lokalisierten Build oder anhand von Screenshots je Sprache liegt bei Ihrem Team; wir liefern die Datei, Ihre Entwicklung sieht das Ergebnis an. Strings, die dabei gekürzt oder angepasst werden müssen, melden Sie uns zurück.
Was kostet eine Softwarelokalisierung?
Abgerechnet wird nach Wörtern oder Normzeilen der zu übersetzenden Strings, nicht nach Dateigröße. Preisbestimmend sind Sprachkombination, Anzahl der Sprachen, Aufwand für Kontextklärung und der Anteil bereits übersetzter Strings aus früheren Releases. Bei laufender Lokalisierung sinken die Kosten je Release deutlich, weil nur die Differenz berechnet wird. Sie erhalten ein Angebot je Auftrag, unverbindlich: Preisgestaltung und Angebot.
Welche Sprachen werden bei der Lokalisierung von Software am häufigsten angefragt?
Englisch deckt den Einstieg in die meisten Exportmärkte ab; Nachbarmärkte wie die Niederlande, Frankreich und Polen kommen je nach Vertriebsgebiet dazu. Bei Gerätesteuerungen folgen die Sprachen der Exportmärkte des Maschinenbaus, etwa Spanisch, Italienisch, Tschechisch und Chinesisch, mit Zeichenlimits auf dem Panel als bestimmender Größe. Für Arabisch und Hebräisch ist zusätzlich die Rechts-nach-links-Darstellung der Oberfläche zu prüfen, die die Software unterstützen muss. Sprachdetails: alle Übersetzungssprachen.
Schicken Sie Datei oder Textprobe und nennen Sie Zielsprache und Verwendungszweck, das Angebot kommt in der Regel noch am selben Werktag.