Predefined strings in localization files

[Pi-C]

Hi! I've read the Localization tutorial and I know now how to use localized strings -- even those with parameters -- in my code. What I'm looking for is something similar for use in the localization files.

Consider this example:

Code: Select all

[GCKI-messages]
dead=Your __1__ is destroyed, use your keys to claim a new vehicle!
miner_bot=Robots mined your __1__, use your keys to claim a new vehicle!
miner_player=__1__ mined your __2__, use your keys to claim a new vehicle!

As you can see, the string "use your keys to claim a new vehicle!" is used multiple times. It would be easier if predefined strings could be used instead (Made a typo? Fix it in one place, instead of the complete file!). I'm thinking of something along these lines:

Code: Select all

@STRING{CLAIM="use your keys to claim a new vehicle!"}

[GCKI-messages]
dead=Your __1__ is destroyed, #CLAIM
miner_bot=Robots mined your __1__, #CLAIM
miner_player=__1__ mined your __2__, #CLAIM

Could you implement something like this, please?

[Klonan]

You can do this already:

Code: Select all

claim=use your keys.
dead=Your __1__ is destroyed, __2__

Then in code:

Code: Select all

game.print({"dead", "marriage", {"claim"}})

[Pi-C]

You can do this already:

Code: Select all

claim=use your keys.
dead=Your __1__ is destroyed, __2__

Then in code:

Code: Select all

game.print({"dead", "marriage", {"claim"}})

Thanks, but I think you misunderstood me. Concatenating the strings with game.print is not the issue here, what I meant is more like a preprocessor.

Let me explain:

Code: Select all

dead=Your __1__ is destroyed, __2__

This is perfect if you want to use this in game, e.g. when acting on an event. Something has been destroyed (we don't know what when writing the code), so this code inserts the value of a variable into the localized string at runtime. It's flexible, but you have to call game.print with the name of the complete localized string (here: {"dead"}) and with the names of localized strings for the arguments (here: {"claim"}).

If I know that parameter _1_ is the only thing that will ever change in the game, it makes little sense to use a variable for it. However, if I want to define a lot of localized strings that have the same phrase in common, defining rather than using the strings could be made more flexible.

[Deadlock989]

It's not just about game.print. You can use the __1__, __2__ etc. syntax in any localisation string, without using concatenation at all. For example, there are 5 of them in this tooltip, including the recipe name. The things substituted for __1__ can themselves be localised strings that you have defined, which can themselves contain substitutions, effectively ad infinitum.

locale.png (158.09 KiB) Viewed 1859 times

[eradicator]

(+1)

I tripped over this when polishing up my stockpile mod the other day. It generates a bunch of entities, all of which have the same [entity-description]. But the limits of the cross-referencing system do not allow access to descriptions at "localise-stage".

For example it's possible to references entity/item names:

Code: Select all

[entity-name]
example=Example
big_example=Big __ENTITY__example__

but not descriptions:

Code: Select all

[entity-description]
example=unsuspicious
big_example=really __ENTITY-DESCRIPTION__example__

It's also not possible to cross-reference custom categories

Code: Select all

[er]
example-word=foobar
[entity-name]
large-example=large __ER__EXAMPLE-WORD__

If this system was extended to allow cross-referencing any key from any category (or even just a "fixed string" category) that would be quite useful. Essentially the idea is to keep *static* compositions inside the locale files and only do *dynamic* composition at runtime. (Kinda hoping this works already and i just don't know how to use it properly...)

[Pi-C]

For example it's possible to references entity/item names:

Code: Select all

[entity-name]
example=Example
big_example=Big __ENTITY__example__

Yes, got that one to work. This seems to be a case of a built-in parameter.

but not descriptions:

Code: Select all

[entity-description]
example=unsuspicious
big_example=really __ENTITY-DESCRIPTION__example__

Apparently, ENTITY-DESCRIPTION is not a built-in parameter.

It's also not possible to cross-reference custom categories

Code: Select all

[er]
example-word=foobar
[entity-name]
large-example=large __ER__EXAMPLE-WORD__

Reading this, I thought you could cross-reference strings of the same custom category, but neither

Code: Select all

[GCKI-messages]
claim=use your keys to claim a new vehicle!
dead=Your __1__ is destroyed, __GCKI-messages__claim__

nor

Code: Select all

[GCKI-messages]
claim=use your keys to claim a new vehicle!
dead=Your __1__ is destroyed, __claim__

seem to work.

If this system was extended to allow cross-referencing any key from any category (or even just a "fixed string" category) that would be quite useful. Essentially the idea is to keep *static* compositions inside the locale files and only do *dynamic* composition at runtime. (Kinda hoping this works already and i just don't know how to use it properly...)

That's a better summary of what I meant than I made in my last post.

[Optera]

Expanding built-in parameters would be nice to have for descriptions with constantly repeating text parts.