App Lokalisierung ist mehr als übersetzter Text
Eine App ist in einem Markt erst dann lokalisiert, wenn Store-Seite, Oberfläche, Beispiele, Rechtstexte und Support zusammenpassen. Eine übersetzte Beschreibung allein schafft noch kein lokales Produkt.
Apple und Google Play erlauben lokalisierte Metadaten und Bilder, wählen fehlende Sprachfassungen aber unterschiedlich aus. Apple verwendet je nach Sprache und Store eine andere passende Lokalisierung oder die Primärsprache. Bei Google Play können Nutzer eine automatische Übersetzung oder die Standardsprache wählen; fehlen lokalisierte Bilder, bleiben die Bilder der Standardsprache sichtbar. Deshalb prüfen wir Texte und Bilder getrennt: Eine übersetzte Beschreibung macht fremdsprachige Screenshots noch nicht verständlich.
Wir planen Lokalisierung wie eine Produktänderung. Jede Sprache bekommt Verantwortliche, Quelltexte, Glossar, Screenshots, Testzustände und einen Freigabeweg. Automatische Übersetzung kann beim Entwurf helfen, ersetzt aber keine fachliche Prüfung.
Zuerst Marktfit, dann Sprache
Vor der Übersetzung steht die Frage, ob das Produkt in diesem Markt angeboten, bezahlt, betreut und rechtlich betrieben werden kann. Eine hohe Suchnachfrage allein reicht nicht.
Auch innerhalb derselben Sprache unterscheiden sich Begriffe und Erwartungen. US-Englisch, britisches Englisch und australisches Englisch können dieselbe Seite teilen, wenn das Angebot wirklich gleich ist; lokale Versprechen dürfen dabei nicht erfunden werden.
Store und Produkt synchron halten
App-Name, Untertitel, Beschreibungen, Keywords und Screenshots müssen den aktuellen Produktzustand spiegeln. Wenn der Store eine lokalisierte Funktion verspricht, die App aber im Kernablauf auf die Ausgangssprache zurückfällt, entsteht ein Vertrauensbruch.
Darum wird die Store-Lokalisierung zusammen mit UI-Strings, Fehlermeldungen, E-Mails und Supportmaterial abgenommen.
Vor der Übersetzung steht die Frage, ob das Produkt in diesem Markt angeboten, bezahlt, betreut und rechtlich betrieben werden kann. Eine hohe Suchnachfrage allein reicht nicht.
App-Name, Untertitel, Beschreibungen, Keywords und Screenshots müssen den aktuellen Produktzustand spiegeln. Wenn der Store eine lokalisierte Funktion verspricht, die App aber im Kernablauf auf die Ausgangssprache zurückfällt, entsteht ein Vertrauensbruch.
Bilder wirklich lokalisieren
Ein Screenshot kann mehr Fremdsprache enthalten als die Überschrift darüber. Datumsformat, Kartenort, Namen, Beispielinhalte und Navigationslabels müssen geprüft werden.
Wo ein Motiv kulturell oder operativ nicht passt, braucht es ein anderes Motiv statt nur eines neuen Textlayers. Alle Varianten bleiben auf echten, kontrollierten Produktzuständen.
Statisch veröffentlichen, sauber verbinden
Für die begleitende Website verwenden wir statische, redaktionell geprüfte Sprachseiten. Jede Version hat eine eigene URL und Canonical; hreflang verbindet nur echte Entsprechungen. Das verhindert Laufzeitübersetzung und hält Inhalte für Nutzer und Crawler konsistent.
Nach dem Release werden Suchanfragen, Store-Aufrufe, Installationsschritte und Supportfragen pro Markt betrachtet. Eine Sprache bleibt nicht online, wenn niemand ihren Inhalt pflegen kann.
Lokalisierungs-Definition of Done
Die Sprache ist erst fertig, wenn diese Bereiche zusammenpassen.
- Realer Markt- und Supportumfang bestätigt
- Glossar und Produktbegriffe freigegeben
- Store-Metadaten manuell geprüft
- Screenshots und Beispielinhalte lokalisiert
- Kernablauf, Fehler und E-Mails getestet
- Datenschutz- und Supportlinks erreichbar
- Canonical und hreflang technisch validiert
Lokalisierung ist Produktpflege
Steingraf Labs verbindet Store, Oberfläche, Website und Release-Check. So bleibt eine neue Sprache kein isoliertes Marketingasset, sondern ein betreibbarer Teil des Produkts.
Passende Leistung ansehenGeprüfte Primärquellen
Plattformregeln ändern sich. Deshalb verlinkt jeder Ratgeber die offiziellen Unterlagen, auf denen die fachlichen Aussagen beruhen.