How to evaluate .localised_name in control.lua for display/logging?

[FuryoftheStars]

Let's say I have a reference to a resource entity. I can get the localised_name like so:

Code: Select all

local name = resource.localised_name

However, this is what I'm given (let's say resource entity was iron):

{"entity-name.iron-ore"}

How do I evaluate this such that if I attempt to use this in game to display to someone or log it, it comes out with what is in the localization files? In the case of English:

Iron ore

?

[boskid]

In general you do not need to know translation of the localised string to print it to the player. LuaGameScript::print(), LuaPlayer::print() and log() are aware of LocalisedStrings so you can just pass them directly and what will be logged or printed will be the translated result using player's currently selected language.

From the perspective of the game determinism, translated strings are considered not part of the game state because game would have to have details about every player's currently selected language (in MP) and maybe would need to include file with all translations for each player. In most cases this is not useful at all and scripts should be completly fine working with LocalisedString which is represented by a table with first key being non empty string with localisation key.

If you really need to obtain a translation of a given string (certain mods do this in order to implement control-stage searching in some guis) you can use LuaPlayer::request_translation but it is only doing a translation request when given player is in game, does translation using given player selected language, has to go through the InputAction logic in order to be properly introduced into the game state, has latency in MP and in certain cases may not be resolved at all.

Only place where base game has to request translation is the 5th level of the tutorial campaign as we decided we want the iron ore train stop names to be possible to translate: in that case when first player joins the game, script requests translation using first player's locale and once those strings are translated and properly introduced into the game state, they can be then used to rename 2 train stops that are in that scenario.

[FuryoftheStars]

Hmm, ok, thank you.

I was using a mod that puts labels on the map for resources, and noticed that there were several mod added resources that it was either pulling the internal name or had the wrong name for. Looking into it, I found they had a manually built table of internal to English only names, with a fallback to the internal name, so I wanted to see what it would take to allow it to pull the localized names dynamically. However, replacing the logic where it does the lookup to the manual table with .localised_name was then causing errors elsewhere in the code regarding attempting to concat a table (presumably because it's now being passed eg. {"entity-name.iron-ore"}), but I'm having a hard time tracing it down.

I'll keep poking at it.

Thank you!

[FuryoftheStars]

Ok, so yeah, that was the issue. If I change the concat logic to instead combine them into a single localized string (4th example from here), it now proceeds and errors out with the adding of the map tag:

bad argument #4 of 4 to 'add_chart_tag' (string expected, got table)

Ok, so this makes sense to me now why mods like these often have a manual table to support other mods.



Point of inquiry: Would it cause too many issues to change things like this so they can accept localized strings, allowing things like map tags to display in each person's language (with a fallback to something other than the typical "Unknown key" text)? I feel like this could solve some levels of mod compatibility without the need of each mod owner being required to manually build internal translation tables, or for that matter do them all in one single language despite the end user's language choice and the different translations being available.