Localization Guide: Language Support & Setup

Localization in Mindustry covers the game's system for translating and presenting text, in-game editors, and locale-specific assets. Proper localization ensures players see menus, messages, and UI elements in their chosen language and that locale-dependent features (such as region-specific assets or editor behavior) behave predictably.

Supported locales and text presentation

• Mindustry supports multiple locales. Each locale provides translated strings for UI elements, building and item names, tooltips, and system messages.
• When a translation for a string is missing in the selected locale, the game falls back to the default language (typically English).
• Locale files control not only raw translations but also formatting for numbers, dates, and other display conventions where applicable.

In-game editor localization

• The Visual (in-game) editor — opened via the pencil icon — is localized for ease of use across platforms. It provides a graphical interface for editing logic processors and is recommended for new players.
• Advantages of the in-game (visual) editor:
  • Graphical, block-style interface suitable for beginners.
  • Simple variable selection with all available variables displayed.
  • Intuitive handling of control flow (e.g., Jump).
  • Usable on mobile devices.
• The visual editor allows import/export via the clipboard so players can transfer logic code between instances and locales without manual retyping.

Locale-specific assets and region data

• Some game assets and settings are region-tagged. For example, certain map or region definitions may reference a named shadow region to load; using a null value indicates the normal/default shadow region.
• Locale data may include region names (e.g., "Serpulo") and other map-specific strings. These should be translated consistently to avoid confusing players who switch locales.

Translating numeric and gameplay data

• Localization files must not alter gameplay numbers or mechanical properties. Descriptive text is localized, but values shown in UI (damage, speed, capacity) should be presented exactly as defined by the game data.
• For elements with complex properties (for example, fluid attributes like flammability, explosivity, viscosity, heat capacity, and temperature), the localization layer displays labels and units; it does not change those mechanics.

Working with null and missing values

• Some configuration fields accept null to indicate default behavior (for example, a null "shadow" region name to indicate the normal shadow). Translators and localizers must preserve null semantics and not substitute empty strings or localized text where the engine expects null.

Best practices for translators

• Keep placeholder tokens intact (e.g., {0}, %s) and preserve ordering if the grammar of the target language requires it.
• Do not translate raw identifiers, technical keys, or filenames.
• Maintain consistency for gameplay terms (building names, item names, region names). Use the established canonical translations for proper nouns like Serpulo.
• Test translations in the visual editor and in-game to ensure UI fits layout constraints and mobile screens.
• Use clipboard import/export to validate logic snippets across locales without introducing encoding issues.

Testing and maintenance

• Verify translations in-game, checking menus, tooltips, and the visual logic editor.
• Ensure that any locale-specific asset references (e.g., shadow region names) load correctly and that null/default behaviors remain intact.
• Keep localization files synchronized with game updates to avoid missing strings or mismatched placeholders.