Localizing VS Code extensions with the localization skill

GitHub's skill explains the three technical paths for localizing VS Code extensions consistently in practice, step by step.

  • Skill Road
  • Localizing VS Code extensions with the localization skill

Published on 09.09.2026

Purpose of the localization skill for VS Code extensions

The vscode-ext-localization skill comes from the awesome-copilot GitHub repository, which is maintained by GitHub itself and collects guidance for AI-assisted development tools. Per the provider, the skill helps localize every aspect of a VS Code extension, meaning making it available in different languages. It targets anyone who wants to localize new or existing contributed configuration such as settings, commands, menus, views, or walkthrough titles, as well as anyone who wants to translate string messages inside the extension's actual source code that are shown to end users. The skill is deliberately narrow and does not describe general translation theory, but the concrete technical conventions that Visual Studio Code prescribes for localized extensions.

The three localization paths in VS Code

According to the guidelines summarized in the skill file, Visual Studio Code has three separate mechanisms depending on where a piece of text to be translated originates. First, configuration items such as settings, commands, menus, views, and walkthrough titles that are defined in an extension's package.json file get translated via a dedicated file following the naming pattern package.nls.LANGID.json, for example package.nls.pt-br.json for Brazilian Portuguese. Second, walkthrough content that lives in its own Markdown files receives a language-specific copy following the same naming pattern, such as walkthrough/someStep.pt-br.md. Third, messages and string resources located directly in the extension's JavaScript or TypeScript source code that are visible to end users get translated via a bundle file named bundle.l10n.LANGID.json. This separation matters because a single translation process that only covers one of these three sources will automatically leave gaps in the other two.

Prerequisites for using it

To make meaningful use of the skill you need an existing VS Code extension project with the usual folder structure, in particular a package.json file, and, where applicable, existing walkthrough files and source code containing visible text messages. The skill itself does not automatically translate content into a foreign language; it only prescribes the structure and convention according to which new or changed localizable resources must be added for every already-supported language. You therefore still need either human translators or an additional translation tool, which the skill merely guides you to apply consistently.

Workflow in practice

Whenever a new localizable resource is created, or an existing one changed, the skill requires that the corresponding translation also be created or updated for every currently available language. In practice this means: as soon as you add a new command or setting to package.json, the matching line has to be added to every existing package.nls.LANGID.json file. If a walkthrough text changes, the corresponding translated Markdown file has to be updated to match. And if a new user-facing message is inserted into the code, the corresponding entry has to appear in every bundle file. This consistent three-way synchronization prevents a situation where an extension shows up-to-date features in some languages but outdated or missing text in others.

Security, limitations, and value

Security considerations barely apply to this skill, since it works exclusively with text files inside your own project and touches no external services or sensitive data. The value lies mainly in the fact that developers don't have to research themselves which of the three localization mechanisms is responsible for which kind of text; the skill gives them that consistently. The limitations are obvious: the skill does no actual translation work and knows nothing about language-specific subtleties such as plural forms or cultural adaptation; it only ensures that the technical structure required for multilingual extensions is correctly followed. For actual translation quality, native-speaker review remains necessary regardless of the skill.

Published on 09.09.2026

Categories

Frequently asked questions

Which resource types does the skill distinguish?

According to the provider, it distinguishes package.json contributions, walkthrough files, and strings from JavaScript or TypeScript source code.

May technical keys be translated?

No. Keys, placeholders, file names, and other technical identifiers must remain unchanged; only the visible language should be adapted.

Does the skill replace tests and manual review?

No. Diff review, extension tests, and inspection in the relevant VS Code languages are still required.