Candy Logo Copyright © 2025-2026 Candy Arts
Other Methods
Candy Dialogue Engine translates Dialogues with its own features: language Variations for speech, and localization tables for names, UI texts and other content. Godot has its own localization system, which your game may already use for its menus and other texts. The two systems are independent, and can be combined. How Godot's localization works is explained in the Godot documentation: Internationalizing games. Godot's Localization Godot's localization, in outline:
  • Translations are imported from CSV or gettext (PO) files, and registered in the Project Settings.
  • The current language is a locale code, such as "fr" or "pt_BR", managed by the TranslationServer singleton.
  • Code translates a text with tr(), which looks up a key such as "ITEM_SWORD" in the current locale's translation.
  • Control nodes, such as Labels and Buttons, can translate their own text automatically when it matches a key.
Two Separate Languages Candy Dialogue Engine doesn't read Godot's locale. Its language is candy_de.language, or an Engine's engine_language (see Translating Speech). Changing one doesn't change the other. If your game uses both systems, change both languages together, for example in your options menu:
func set_game_language(locale: String, candy_language: String) -> void: TranslationServer.set_locale(locale) candy_de.language = candy_language $DialogueUI/CandyEngine.refresh_language()
The two systems also name languages differently:
  • Your Dialogues' original language is always named Default in Candy Dialogue Engine, whatever its locale is.
  • Candy Dialogue Engine's other languages can be named after Godot locales, such as "fr" or "ja", which simplifies the mapping. Locales that contain an underscore, such as "pt_BR", can't be language names as they are, because underscores separate the parts of a Variation name: name them differently, such as "pt-BR".
Godot Translations in Dialogues Godot's translation functions can be called from any ¢ expression (see CandyRef Expressions). For example, a text variable can display an item name from your Godot translations:
You found ¤¢tr("ITEM_SWORD")¤!
This is an alternative to adding a localization table of your own (see Translating Other Content): texts your game already translates with Godot don't need to be translated again in a Candy Dialogue Engine table. tr() reads Godot's locale, not the Engine's language: change both together, as above. An expression is evaluated when its line runs. A choice label written as ¢tr("CHOICE_ATTACK") retains the text it had when its menu opened: the Engine's refresh_language() doesn't evaluate it again. Automatic Translation of UI Nodes Godot can translate the text of Control nodes automatically, depending on each node's auto_translate_mode. This also applies to the texts Candy Dialogue Engine writes into its UI Elements, such as choice labels or speaker names: if one of your Godot translations has a key identical to such a text, Godot displays its translation. This rarely matters, because Godot keys are usually identifiers such as "ITEM_SWORD", which don't appear in Dialogues. If your Godot translations use plain text as keys, set auto_translate_mode to Disabled on the root node of Candy Dialogue Engine's UI scenes, so that only Candy Dialogue Engine translates their texts. Text-to-Speech Text-to-speech systems usually require the language of the text they read. Your tts() hook function receives the line's Variation name in candy_args["variation"], whose first part is the language. It can also read Godot's locale with TranslationServer.get_locale(). See TTS.