
Welcome to the Metruvia Content Creator Series Localization and Translation Guide. When you upload a mod to the Steam Workshop, your audience is generally localized to the PC gaming demographic. When you push a mod to Mod.io with the “Console Compatible” tag, your work is instantly distributed to living rooms in Tokyo, Berlin, Paris, and São Paulo.
Transport Fever 2 has a massive international following, particularly in Europe and Asia. If your vehicle names, station menus, and campaign objectives are hardcoded exclusively in English, you are alienating up to 70% of your potential player base. Furthermore, improperly formatted text characters can cause the console UI parser to choke, resulting in visual bugs or rejected submissions.
This masterclass will deconstruct the Transport Fever 2 localization pipeline. We will explore the architecture of the strings.lua dictionary, the syntax of the translation wrapper, the absolute necessity of UTF-8 encoding, and the workflow for localizing your Mod.io metadata.
1. The Architecture of strings.lua
Transport Fever 2 handles translations through a central dictionary file. Instead of writing separate vehicle scripts for every language, you write one script and tell the game engine to look up the correct translation in real-time based on the user’s system settings.
1.1 The Directory Structure
Your translation dictionary must be placed in a highly specific location within your mod’s root directory:
res/config/name_of_your_mod/strings.lua
(Note: In newer versions of the engine, placing it directly in res/config/strings.lua can cause conflicts if multiple mods use identical keys. It is best practice to nest it in a unique subfolder or ensure your translation keys are highly unique).
1.2 The Dictionary Syntax
The strings.lua file is a simple array of ISO 639-1 language codes, containing key-value pairs.
function data()
return {
en = {
[“metruvia_heavy_freight_title”] = “Heavy Freight Locomotive”,
[“metruvia_heavy_freight_desc”] = “A powerful diesel-electric locomotive designed for steep gradients.”
},
de = {
[“metruvia_heavy_freight_title”] = “Schwere Güterzuglokomotive”,
[“metruvia_heavy_freight_desc”] = “Eine leistungsstarke dieselelektrische Lokomotive für steile Steigungen.”
},
zh = {
[“metruvia_heavy_freight_title”] = “重型货运机车”,
[“metruvia_heavy_freight_desc”] = “专为陡峭坡度设计的重型柴油电力机车。”
}
}
end
2. The Wrapper Function: _("Text")
The engine will not automatically translate text just because it exists in the dictionary. You must explicitly tell the engine which strings need to be translated using the underscore wrapper function: _()
2.1 Applying the Wrapper in .mdl and mod.lua Files
Whenever you define a name or description in your vehicle models, construction scripts, or the master mod.lua, you wrap the dictionary key in this function.
— Inside your vehicle’s .mdl file
metadata = {
description = {
name = (“metruvia_heavy_freight_title”), description = (“metruvia_heavy_freight_desc”)
}
}
When the game loads, it sees the _() wrapper, grabs the string "metruvia_heavy_freight_title", checks the player’s console language (e.g., German), looks inside your strings.lua under the de block, and displays “Schwere Güterzuglokomotive” in the UI.
2.2 The Fallback Mechanic
If a Japanese player downloads your mod, but you did not provide a ja translation block in your strings.lua, the engine will default to the exact text inside the wrapper function. For this reason, some developers prefer to use the actual English text as the key itself: name = _("Heavy Freight Locomotive"). While this works, using dedicated keys (like metruvia_heavy_freight_title) is cleaner for massive projects and prevents punctuation from breaking the Lua parser.
3. Encoding Standards: The UTF-8 Mandate
This is the most common technical failure point for localization. When writing translations for German (Ü, ß), French (é, à), or Chinese (汉字), you are using characters outside the standard ASCII table.
3.1 UTF-8 Without BOM
If you save your strings.lua file using standard ANSI or default Windows text encoding, the console OS will fail to read the special characters. The game will display broken squares, question marks (), or crash the UI thread entirely.
You must configure your code editor (VS Code, Notepad++) to save the file strictly as UTF-8 without BOM (Byte Order Mark). The BOM is an invisible character placed at the very beginning of a file by some Windows programs; the Transport Fever 2 Lua parser will read the BOM as a syntax error and instantly reject the entire dictionary.
4. Localizing the mod.lua for the Mod Manager
Translating the vehicles in-game is only half the battle. You must also translate the mod’s title and description so it appears correctly in the player’s Mod Activation menu before they even load a save file.
This is handled identically to the .mdl files. In your root mod.lua:
function data()
return {
info = {
minorVersion = 1,
severityAdd = “NONE”,
severityRemove = “WARNING”,
name = (“metruvia_mod_title”), description = (“metruvia_mod_desc”),
tags = { “Vehicle”, “Train” },
},
— …
}
end
5. The Cloud Dashboard: Mod.io Storefront Localization
While strings.lua handles the in-game text, it does not translate your mod’s actual webpage on the Mod.io storefront. Console players browsing the Mod.io app on their Xbox or PlayStation will see the text you entered in the web dashboard.
5.1 Multilingual Descriptions in Markdown
Mod.io supports Markdown in the description field. To cater to a global audience on the storefront, structure your web description using language headers.
English
The definitive Metruvia Heavy Freight pack, optimized for console performance.
- Top Speed: 120 km/h
- Capacity: N/A
Deutsch
Das definitive Metruvia Schwerlast-Paket, optimiert für Konsolenleistung.
- Höchstgeschwindigkeit: 120 km/h
- Kapazität: N/A
Do not rely on machine translation (like basic Google Translate) for technical terms. “Draw calls,” “tractive effort,” and “LODs” often translate into literal, nonsensical phrases in other languages. If you do not have a native speaker to translate for you, keep your non-English storefront descriptions strictly focused on the basic numbers (Speed, Weight, Year).
6. Summary: The Pre-Publish Localization Audit
Before you submit your mod to the Mod.io automated pipeline, ensure your text is globally compliant:
The Wrapper Check: Are all UI-facing text strings in your .mdl, .con, and mod.lua wrapped in the _() function?
Key Matching: Does every single key inside a wrapper exist exactly as typed in your strings.lua file?
Encoding Verification: Is the strings.lua file strictly saved as UTF-8 (Without BOM)?
Fallback Safety: If a language is missing, will the default key text read cleanly to the user?
Storefront Formatting: Is your Mod.io web description cleanly separated for international readers?
By treating localization as a core engineering requirement rather than an afterthought, you respect the global community, bypass UI parsing errors, and dramatically increase your mod’s subscriber retention across all console regions.


Leave a Reply