# VS Code Language Packs: where the translated strings actually come from > The vscode-loc repository holds the localized resource files behind the Visual Studio Code Language Packs, covering 14 languages including a pseudo locale used for testing. It is an output repository rather than a place to translate, since the strings are edited on the Microsoft Localization Platform and pull requests fixing translations are rejected. **microsoft/vscode-loc** — VS Code Localization Extension - Repository: https://github.com/microsoft/vscode-loc - Stars: 756 · Forks: 399 - Language: Unknown - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/microsoft-vscode-loc ## This repository is an export target, not a translation workspace The Visual Studio Code Language Packs repository exists to hold the localized resource files that ship inside the language pack extensions. The README states the model in one sentence: localized resource files are managed and edited by Microsoft, and files are exported to this repository when strings are updated to prepare for publishing the language packs. That is a pipeline with an authoring stage that lives outside GitHub. The strings are edited on the Microsoft Localization Platform, and the repository receives the exported result. The original English strings, the ones you read in the open source VS Code repository, are the reference against which the localized ones are produced. The practical consequence for a contributor is stated directly in the contributing section. Translation strings are managed on the Localization Platform and changes to strings can only be made there, so pull requests fixing translations will not be accepted. Other pull requests, to things like the README file and package.json, are accepted at the discretion of the maintainers. Feedback still goes through GitHub. The project asks you to create a new issue for a translation report or other feedback, and to check whether a topic about the issue already exists. The repository layout matches the role. There is an i18n/ directory holding the internationalization data, a build/ directory, a media/ directory, a SECURITY.md file, a LICENSE.md file and a .github/ directory. The primary language of the repository is not recorded as a specific language, which is consistent with a repository that mostly carries resource files rather than source code. ## Fourteen languages, two identifier schemes, and one pseudo locale Visual Studio Code is localized through the concept of Language Packs, and the README lists 14 supported languages in a table that gives two identifiers for each one: the Visual Studio Code language ID and the Microsoft Localization Platform language code. The two schemes are not the same thing, and the difference matters if you are writing an extension. The VS Code language ID is what the product itself uses, and the MLCP code is the Microsoft Localization Platform code that identifies the same language on the translation side. For French they are fr and French (fr-fr). For Italian, it and Italian (it-it). For German, de and German (de-de). For Spanish, es and Spanish (es-es). For Russian, ru and Russian (ru-ru). Chinese appears twice, split into Simplified and Traditional, with the language IDs zh-cn and zh-tw and the MLCP codes Chinese Simplified and Chinese Traditional. The other entries are Japanese with ja, Korean with ko, Czech with cs, Portuguese (Brazil) with pt-br, Turkish with tr and Polish with pl. The final row is the one that is not a real language. Pseudo Language has the VS Code ID qps-ploc and the MLCP code Pseudo (qps-ploc). A pseudo locale is a synthetic locale used to test how an interface behaves with text that is longer than the source strings or with unusual characters, which is how a layout is checked for truncation before a real translation exists. Note the casing inconsistency in the MLCP codes themselves. Most are lowercase country suffixes, de-de and it-it and es-es, but Czech is given as Czech (cs-CZ) with an uppercase country code, and the Chinese entries have no country suffix at all. Anyone matching on these codes should not assume a single convention. The VS Code language IDs are the ones that matter for extension authors, since that is the identifier a display language command and a language contribution in an extension package refer to. ## Installing a language pack is a command, and the marketplace is the other route There are two documented ways to get a language pack into Visual Studio Code, and both are mentioned in the opening paragraph of the README. The first is the command palette route. You run the Configure Display Language command in Visual Studio Code's command palette, which surfaces the list of available language packs and installs the one you pick. The second is the marketplace. The README links to the Visual Studio Code Marketplace filtered to the VS Code target and the Language Packs category, sorted by installs, so the packs can be installed directly as extensions. The two routes matter for different reasons. The command palette route is for the person sitting at the machine, who wants to switch their editor into their own language, and it is a one-step operation that does not require knowing which extension to look for. The marketplace route is the one that matters if you are deploying VS Code to a fleet of machines, because it treats the language pack as an extension with a version, and it is the same channel that carries every other extension your organisation installs. The repository does not describe the publishing process in detail beyond the export step, so if you want to know how a pack gets from the Localization Platform to a marketplace listing, the build directory and the i18n directory are where to look in the tree, and the export described in the README is the documented step you can trace. For an extension author, the practical takeaway from this repository is the identifier table. The language ID your extension's display language handling has to recognise is the VS Code column, and the MLCP code is what the translation workflow uses to associate a translated string with your package. ## Why pull requests fixing translations are turned away The refusal to accept translation pull requests deserves a paragraph of its own, because it is the detail that most surprises people who find this repository while trying to fix a mistranslation they just used. The stated reason is the workflow, not the policy of refusing help. The strings live on the Microsoft Localization Platform, which is where the translators, the context, the machine translation and the human review all work. A patch applied to the exported file in this repository would be overwritten by the next export, and it would bypass the context that the translation tooling provides to a translator, such as the original English string and its surrounding usage. There is a second-order effect that is worth stating. Because a translation pull request cannot be accepted, the effective contribution path for a translator is to report the issue and then, presumably, fix it on the platform where the change can be made. The README does not describe the platform side, which is a separate sign-in experience from GitHub, and that gap is where someone trying to help a user with a bad string will get stuck. What the project does accept is more predictable than it first appears. Pull requests to things like the README file and package.json are accepted, at the discretion of the maintainers. The discretion is in the wording and it is worth reading twice, because it means the acceptance of a non-translation pull request is not guaranteed either. The legal side follows the same model of a gate. Before a pull request can be accepted you need to sign a Contribution License Agreement, and all you have to do to start is submit the pull request. It is then labelled with its state, one of the labels listed in the README being cla-required, and once the agreement is signed every future pull request from that account is labelled cla-signed, so the check does not repeat. ## A custom licence record next to an MIT statement The licence story in this repository is slightly tangled, and it is the kind of detail worth resolving before you copy anything out of it. The README's licence section links to MIT in the LICENSE.md file at the root. The repository licence metadata, on the other hand, is recorded as a custom licence that GitHub cannot classify, with a pointer to the LICENSE file for the actual terms. Those two statements sit next to each other and the second one is the one that describes the file you would need to read. For most users of VS Code this is academic, since language packs are installed as extensions rather than incorporated into a product. It stops being academic if you build tooling that reads the i18n data, or if you want to reuse the pseudo locale, which is the piece of this repository that is arguably most reusable on its own since a pseudo locale is a testing asset rather than a translation. Two other repository files are worth noting for anyone evaluating the project as a dependency. There is a SECURITY.md file, so security issues have a documented reporting path rather than an informal channel, and the project has adopted the Microsoft Open Source Code of Conduct, with a code of conduct FAQ and an opencode@microsoft.com contact for questions about the code itself. The release history is a mirror of how VS Code versions its work. The listed tags are v1.98.2025022817, v1.98.2025022609 and v1.98.2025021909, all dated in February 2025, and each tag carries the VS Code version followed by a date stamp. The last push to the repository was on 2026-10-20, so the tree is still receiving updates even though the newest listed release is from February 2025, which is consistent with a repository whose releases track the editor's own release cadence. ## Conclusion vscode-loc is worth knowing about if you maintain a VS Code extension with translated strings, because it shows exactly how the platform distinguishes the editable source of a string from the shipped localized resource file, and it documents the language identifiers your extension has to match. It is not a repository to contribute translations to, and the project says so in terms, since changes can only be made on the Microsoft Localization Platform and pull requests fixing translations are not accepted. Before you file anything, verify three things yourself: that the issue you want to report is a translation issue at all, because other pull requests, to files such as README.md and package.json, are accepted at the maintainers' discretion, that you are signed up on the Localization Platform, and that the licence position is clear to you, since the README links MIT in the LICENSE.md file while the repository licence field itself is recorded as one GitHub cannot classify. ## FAQ ### What does the microsoft/vscode-loc repository contain? It contains the localized resource files for the Visual Studio Code Language Packs, covering 14 supported languages. The files are managed and edited by Microsoft on the Microsoft Localization Platform and exported to this repository when strings are updated. ### Can I fix a bad translation with a pull request to vscode-loc? No. Translation strings are managed on the Microsoft Localization Platform and changes can only be made there, so pull requests fixing translations are not accepted. Other pull requests, to files such as README.md and package.json, are accepted at the discretion of the maintainers. ### Which languages does Visual Studio Code support? The README lists 14: French, Italian, German, Spanish, Russian, Chinese Simplified, Chinese Traditional, Japanese, Korean, Czech, Portuguese (Brazil), Turkish, Polish, and a Pseudo Language. Each entry gives both a Visual Studio Code language ID and a Microsoft Localization Platform language code. ### How do I install a Visual Studio Code language pack? Run the Configure Display Language command in the Visual Studio Code command palette, or install a pack from the Visual Studio Code Marketplace, where language packs are listed under the Language Packs category for the VS Code target. ### Do I need to sign a CLA to contribute to vscode-loc? Yes, a Contribution License Agreement must be signed before a pull request can be accepted. You start by submitting the pull request, which is then labelled with its state, and once signed, all your future pull requests are labelled as signed. ## Sources - [Issues](https://github.com/microsoft/vscode-loc/issues) - [microsoft/vscode-loc on GitHub](https://github.com/microsoft/vscode-loc) - [README](https://github.com/microsoft/vscode-loc/blob/main/README.md) - [Releases](https://github.com/microsoft/vscode-loc/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-vscode-loc