VS-Code-Erweiterungen mit dem Localization-Skill lokalisieren

GitHubs Skill erklaert die drei technischen Wege zur Lokalisierung von VS-Code-Erweiterungen konsistent und praxisnah erklaert.

  • Skill Road
  • VS-Code-Erweiterungen mit dem Localization-Skill lokalisieren

Veröffentlicht am 09.09.2026

Zweck des Localization-Skills fuer VS-Code-Erweiterungen

Der Skill vscode-ext-localization stammt aus dem GitHub-Repository awesome-copilot, das von GitHub selbst gepflegt wird und eine Sammlung von Anleitungen fuer KI-gestuetzte Entwicklungsassistenten enthaelt. Laut Anbieter unterstuetzt der Skill dabei, saemtliche Aspekte einer VS-Code-Erweiterung zu lokalisieren, also fuer verschiedene Sprachen verfuegbar zu machen. Er richtet sich an alle, die neue oder bestehende Konfigurationen wie Einstellungen, Befehle, Menues, Ansichten oder Einfuehrungstexte lokalisieren wollen, sowie an alle, die Textmeldungen im eigentlichen Erweiterungscode fuer Endnutzerinnen und Endnutzer uebersetzen moechten. Der Skill ist bewusst schmal gehalten und beschreibt keine allgemeine Uebersetzungstheorie, sondern die konkreten technischen Konventionen, die Visual Studio Code fuer lokalisierte Erweiterungen vorschreibt.

Die drei Lokalisierungswege in VS Code

Nach den in der Skill-Datei zusammengefassten Richtlinien von Visual Studio Code gibt es drei getrennte Mechanismen, je nachdem, wo ein zu uebersetzender Text herkommt. Erstens: Konfigurationen wie Einstellungen, Befehle, Menues, Ansichten und Einfuehrungstitel, die in der Datei package.json einer Erweiterung definiert sind, werden ueber eine eigene Datei mit dem Namensschema package.nls.SPRACHKENNUNG.json uebersetzt, zum Beispiel package.nls.pt-br.json fuer brasilianisches Portugiesisch. Zweitens: Inhalte von Einfuehrungs-Walkthroughs, die in eigenen Markdown-Dateien liegen, erhalten eine sprachspezifische Kopie mit demselben Namensschema, etwa walkthrough/someStep.pt-br.md. Drittens: Meldungen und Textbausteine, die direkt im JavaScript- oder TypeScript-Quellcode der Erweiterung stehen und fuer Endnutzerinnen und Endnutzer sichtbar sind, werden ueber eine Bundle-Datei mit dem Namen bundle.l10n.SPRACHKENNUNG.json uebersetzt. Diese Trennung ist wichtig, weil ein einzelner Uebersetzungsprozess, der nur eine dieser drei Quellen abdeckt, automatisch Luecken in den anderen beiden hinterlaesst.

Voraussetzungen fuer den Einsatz

Um den Skill sinnvoll zu nutzen, braucht man ein bestehendes VS-Code-Erweiterungsprojekt mit der ueblichen Ordnerstruktur, insbesondere einer package.json-Datei sowie gegebenenfalls vorhandenen Walkthrough-Dateien und Quellcode mit sichtbaren Textmeldungen. Der Skill selbst uebersetzt keine Inhalte automatisch in eine Fremdsprache, sondern gibt lediglich die Struktur und Konvention vor, nach der neue oder geaenderte lokalisierbare Ressourcen fuer alle bereits unterstuetzten Sprachen ergaenzt werden muessen. Man benoetigt also weiterhin entweder menschliche Uebersetzerinnen und Uebersetzer oder ein zusaetzliches Uebersetzungswerkzeug, das der Skill lediglich sinnvoll anleitet einzusetzen.

Ablauf in der Praxis

Wird eine neue lokalisierbare Ressource erstellt oder eine bestehende geaendert, verlangt der Skill, dass die entsprechende Uebersetzung fuer alle aktuell verfuegbaren Sprachen ebenfalls angelegt oder aktualisiert wird. In der Praxis bedeutet das: Sobald man einer package.json einen neuen Befehl oder eine neue Einstellung hinzufuegt, muss die passende Zeile in jeder vorhandenen package.nls.SPRACHKENNUNG.json-Datei ergaenzt werden. Aendert sich ein Walkthrough-Text, muss die entsprechende uebersetzte Markdown-Datei nachgezogen werden. Und wird eine neue Benutzermeldung im Code eingefuegt, muss der zugehoerige Eintrag in jeder Bundle-Datei erscheinen. Diese konsequente Drei-Wege-Synchronisierung verhindert, dass eine Erweiterung in manchen Sprachen aktuelle Funktionen zeigt, in anderen aber veraltete oder fehlende Texte.

Sicherheit, Grenzen und Nutzen

Sicherheitsrelevante Aspekte spielen bei diesem Skill kaum eine Rolle, da er ausschliesslich mit Textdateien im eigenen Projekt arbeitet und keine externen Dienste oder sensiblen Daten beruehrt. Der Nutzen liegt vor allem darin, dass Entwicklerinnen und Entwickler nicht selbst recherchieren muessen, welche der drei Lokalisierungsmechanismen fuer welchen Texttyp zustaendig ist, sondern dies vom Skill konsistent vorgegeben bekommen. Die Grenzen sind offensichtlich: Der Skill erledigt keine tatsaechliche Uebersetzungsarbeit und kennt auch keine sprachspezifischen Feinheiten wie Pluralformen oder kulturelle Anpassungen; er sorgt lediglich dafuer, dass die technische Struktur fuer mehrsprachige Erweiterungen korrekt eingehalten wird. Fuer die eigentliche Uebersetzungsqualitaet bleiben weiterhin muttersprachliche Pruefungen notwendig.

Veröffentlicht am 09.09.2026

Kategorien

Häufige Fragen

Welche Ressourcentypen unterscheidet der Skill?

Laut Anbieter unterscheidet er package.json-Beiträge, Walkthrough-Dateien und Zeichenketten aus JavaScript- oder TypeScript-Quellcode.

Dürfen technische Schlüssel übersetzt werden?

Nein. Schlüssel, Platzhalter, Dateinamen und andere technische Bezeichner müssen unverändert bleiben; nur die sichtbare Sprache wird angepasst.

Ersetzt der Skill Tests und manuelle Prüfung?

Nein. Diff-Review, Erweiterungstests und eine Kontrolle in den relevanten VS-Code-Sprachen bleiben erforderlich.