Factorio Forums

1. You essentially introduce a second locale file that can be asynchronus with the actual locale file. Meaning double work for translators/modderes.
2. The serach keywords are an incomplete representation of the locale and as such won't do what the user expects them to do 90% of the time.
3. You're blindly mixing languages. For all i know "Iron" could be the Estonian word for "Bomb". Leading to completely wrong results for every user.
4. You can already implmenet this on your own via remote.call() so it doesn't improve the situation at all.

eradicator wrote: Thu Sep 12, 2019 5:09 pm I'm all in for a translate() function, but i want a proper solution, and i want it to work for all locale strings. And as far as the old thread goes, this requires making locales deterministic in one way or the other. I.e. by synchronizing locales between players or by making locales part of the mod checksum in the first place.

Bilka wrote: Thu Sep 12, 2019 5:48 pm Something changed since that thread - all mods are now part of "game changing mods", so all players will have the same mods active and the right locale file on their system.

Bilka wrote: Thu Sep 12, 2019 5:48 pm Using a different one for Lua means also loading that. Now, loading like 30 different locales? That sounds insane.

1. Is 30 locales really that big? A search over my factorio folder says there are 947 ".cfg" files with a total of 9MB. With RAM in the gigabytes this should be negligible.
2. If it's still too much anyway (table overhead or whatever) then why not load them dynamically? To keep the game deterministic it would be sufficient if only locales were loaded that *someone* is actually using. The players see only their own locale. And i suspect that multiplayer servers with players from more than 10 different countries are extremely rare, and most of the time it's less than 5.
3. There are benefits besides modding to this. It'd be possible to e.g. have a button that toggles between the players two/three favourite locales, making communication much easier when playing with friends in a different locale. (Ok, would probably require too much engine rewrite to actually happen...)

Bilka wrote: Thu Sep 12, 2019 5:48 pm I still hope for translate(), but I want to explain why it's not a thing yet.

player.translate(localised-string)

• API call is made requesting that a translation for 'localised-string' by 'player' is done
• If the player is online the game sends an InputAction with the localised-string and translated result + a bool if it failed to translate
• Whenever the action gets to the game and is run it fires a "on_string_translated" event which contains the player it was translated by, the original localised string, and the result translation + if it failed to translate

Rseding91 wrote: Fri Sep 13, 2019 2:56 am I could implement a

Code: Select all

player.translate(localised-string)

but it's not going to be instant and would only work when the player is connected to the game.

How it would work is:

• API call is made requesting that a translation for 'localised-string' by 'player' is done
• If the player is online the game sends an InputAction with the localised-string and translated result + a bool if it failed to translate
• Whenever the action gets to the game and is run it fires a "on_string_translated" event which contains the player it was translated by, the original localised string, and the result translation + if it failed to translate

In single player it would be instant or 1 tick later that results come back. In multiplayer it's N ticks later or never if the player disconnects before finishing the request. It's not perfect but I think for most cases it would work.

Is this something that would handle peoples needs?

player.translate("Eisenplatte")

on_string_translated(player, "iron-plate")

posila wrote: Fri Sep 13, 2019 5:57 am No, I think it's the other way around

Code: Select all

player.translate({ "iron-plate" })

would raise

Code: Select all

on_string_translated(player, "Eisenplatte")

Optera wrote: Fri Sep 13, 2019 7:28 am That seems only useful to check if a certain translation exists.

Just going by the thread name the goal is to search for a prototype by translated name. Any mod trying to do a translated name> prototype name search would need to call this function for every prototype and player to build a translation dictionary.
Ideally that would then be used to create one function library shared between all mods wanting to use this feature, as if that would ever happen. We all know every larger mod created makes his own library because none of us trust the other to keep a library working with all mods depending on it.

posila wrote: Fri Sep 13, 2019 5:57 am No, I think it's the other way around

Code: Select all

player.translate({ "iron-plate" })

would raise

Code: Select all

on_string_translated(player, "Eisenplatte")

on_string_translated(player,{["iron-plate"]="Eisenplatte"})

Rseding91 wrote: Fri Sep 13, 2019 8:06 am Any time anything does searching/filtering it's "get all of the translations for every prototype i'm filtering and then match what the player typed against them".

eradicator wrote: Fri Sep 13, 2019 10:24 am On second thought, is that really more efficient than just

Code: Select all

player.request_locale()

or even

Code: Select all

player.request_locale_filtered({types={'item-name','recipe-name','entity-name'})

that raises an event that contains the complete locale? Mods will have to build dictionaries anyway, so translating only a single keyword will be a rare edge case.

{["en"] = {["iron-plate] = "Iron plate", ...}

Therenas wrote: Thu Sep 12, 2019 4:39 pm The idea is to add an additional field to the prototypes, named search_strings or something, that contains the words the developer wants to let people find their item as. So, for an item with the name 'gear', and the localised name 'Iron gear', you could have search_strings like 'Iron', 'Gear', 'Eisen', 'Zahnrad' (German translation of those).

Rseding91 wrote: Fri Sep 13, 2019 7:00 pm A function which gives the full set of translations wouldn't be useful because translations aren't a 1-1 mapping of key<>value. They have substitutions/replacements and can even include each other.

Rseding91 wrote: Fri Sep 13, 2019 8:03 pm One at a time vs multiple at once won't have any significant difference in performance but it will make the backing logic easier if it's one at a time.