Editor and docs localization

These resources include:

The Godot editor’s interface (ca. 15,000 words).
The (editor manual and tutorials, ca. 300,000 words).
The class reference, available both online and in the editor (ca. 200,000 words).

To manage translations, we use the GNU gettext file format ( files), and the open source web-based localization platform, which allows easy collaboration of many contributors to complete the translation for the various components, and keep them up to date. Click the bold links above to access each resource on Weblate.

This page gives an overview of the general translation workflow on Weblate, and some resource-specific instructions on e.g. how to handle some keywords or the localization of images.

Tip

Translating all the official Godot content is a massive undertaking, so we advise prioritizing the resources as they are listed above: first the editor interface, then the online documentation, and eventually the class reference if there are enough translators to keep up with updates.

While our translations eventually reside in the Git repositories of the Godot engine and its documentation, all translation updates are handled through Weblate, and thus direct pull requests to the Git repositories are not accepted. Translations are synced manually between Weblate and the Godot repositories by maintainers.

You should therefore to contribute to Godot’s translations.

Once signed in, browse to the Godot resource which you want to contribute to (in this page we will use the editor translation as an example) to find the list of all languages:

See also

Feel free to consult Weblate’s own documentation on the for more details.

If your language is already listed, click on its name to access the overview, and skip the rest of this section.

If your language is not listed, scroll to the bottom of the list of languages and click the “Start new translation” button, and select the language you want to translate to:

Important

If your language is spoken in several countries with only limited regional variations, please consider adding it with its generic variant (e.g. fr for French) instead of a regional variant (e.g. fr_FR for French (France), fr_CA for French (Canada), or fr_DZ for French (Algeria)).

Godot has a huge amount of content to translate, so duplicating the work for regional variants should only be done if the language variations are significant enough. Additionally, if a translation is done with for a regional variant, it will only be available automatically for users located in this region (or having their system language configured for this region).

When regional variations are significant enough to warrant separate translations, we advise to focus on completing a generic variant first if possible, then duplicate the fully completed translation for regional variants and do the relevant edits. This is typically a good strategy for e.g. Spanish (work on es first, then duplicate it to es_AR, es_ES, es_MX, etc. if necessary) or Portuguese (pt_BR vs pt_PT).

Once a language has been selected, you will see an overview of the translation status, including how many strings are left to translate or review. Each item can be clicked and used to browse through the corresponding list. You can also click the “Translate” button to get started on the list of strings needing action.

After selecting a list of clicking “Translate”, you will see the main translation interface where all the work happens:

PO files are an ordered list of source strings (msgid) and their translation (msgstr), and by default, Weblate will present the strings in that order. It can therefore be useful to understand how the content is organized in the PO files to help you locate the original content and use it as a reference when translating.

Important

It is primordial to use the original context as reference when translating, as many words have several possible translations depending on the context. Using the wrong translation can actually be detrimental to the user and make things harder to understand than if they stayed in English. Using the context also makes the translation effort much easier and more enjoyable, as you can see directly if the translation you wrote will make sense in context.

The editor interface’s translation template is generated by parsing all the C++ source code in alphabetical order, so all the strings defined in a given file will be grouped together. For example, if the “source string location” indicates editor/code_editor.cpp, the current string (and the nearby ones) is defined in the editor/code_editor.cpp code file, and is thereby related to the code editors in Godot (GDScript, shaders).
The online documentation’s translation template is generated from the source RST files in the same order as seen in the table of contents, so for example the first strings are from the front page of the documentation. The recommended workflow is therefore to find a unique string corresponding to a page that you want to translate, and then translate all the strings with the same source string location while comparing with the online version of that page in English. An example of source string location could be getting_started/step_by_step/nodes_and_scenes.rst for the page .
The class reference’s translation template is generated from the source XML files in alphabetical order, which is also the same as the order of the table of contents for the online version. You can therefore locate the source string corresponding to the brief description of a given class to find the first string to translate and all other descriptions from that class should be in the subsequent strings on Weblate. For example, the descriptions for the Node2D class would have the source string location doc/classes/Node2D.xml.

A handy tool to locate specific pages/classes is to use Weblate’s advanced search feature, and especially the “Location strings” query (which can also be used with the token, e.g. location:nodes_and_scenes.rst):

Note

When a given source string is used in multiple source locations, they will all be concatenated into one. For example, the above location:nodes_and_scenes.rst query would land first on the “Introduction” source string which is used in dozens of pages, including some that come before nodes_and_scenes.rst in the template. Clicking the “Next” button then brings us to the “Scene and nodes” title string displayed above. So it may happen that a given paragraph or section title is not at the location you’d expect it when reading the online version of a page.

Each translation resource originates from a different source code format, and having some notions on the markup language used for each resource is important to avoid creating syntax errors in your translations.

The editor translations originate from C++ strings, and may use:

C format specifiers such as %s (a string) or %d (a number). These specifiers are replaced by content at runtime, and should be preserved and placed in your translation where necessary for it to be meaningful after substitution. You may need to refer to the source string location to understand what kind of content will be substituted if it’s not clear from the sentence. Example (%s will be substituted with a file name or path):
C escape characters such as \n (line break) or \t (tabulation). In the Weblate editor, the \n characters are replaced by ↵ (return) and \t by ↹. Tabs are not used much, but you should make sure to use line breaks in the same way as the original English string (Weblate will issue a warning if you don’t). Line breaks might sometimes be used for vertical spacing, or manual wrapping of long lines which would otherwise be too long especially in the editor translation). Example:

Note

Only logical order of the characters matters, in the right-to-left text, format specifiers may be displayed as s%.

The documentation translations originate from reStructuredText (RST) files, which also use their own markup syntax to style text, create internal and external links, etc. Here are some examples: