Page 1 of 1
Allow numbers at the end of localization strings
Posted: Sun Feb 02, 2020 12:33 am
by Pi-C
As
suggested by darkfrei:
It is quite common to differentiate between different tiers of an entity by attaching a number to its name. If you have prototype names like
Code: Select all
bi-biomass-conversion-1=Bio fuel conversion 1
bi-biomass-conversion-2=Bio fuel conversion 2
the trailing "-1"/"-2" will be ignored, resulting in "missing localization key" messages. A way around is to define one key that is used for all tiers:
Code: Select all
bi-biomass-conversion=Bio fuel conversion
However, the assumption that different tiers are just variants of the same thing is not always correct. Here's an example for recipes where the different tiers produce different output:
Code: Select all
[recipe-name]
bi-biomass-conversion-1=Bio fuel conversion 1: Cellulose, light oil
bi-biomass-conversion-2=Bio fuel conversion 2: Petroleum gas
[recipe-description]
bi_biomass-conversion-1=Use algae biomass to produce light oil and cellulose
bi-biomass-conversion-2=Use algae biomass to produce petroleum gas
Using one key for all of these tiers wouldn't be feasible. I worked around it by replacing the dashes ("-") in the names with underscores ("_"), however, that's against convention (vanilla prototypes use dashes).
Therefore, I'd like to request that trailing numbers in localization keys of prototype names are kept in place and not cut off. It would be great if you could implement this!
Re: Allow numbers at the end of localization strings
Posted: Sun Feb 02, 2020 10:38 am
by Deadlock989
Please don't. If it were true, it would be a bad idea which would break a lot of things. For example, in vanilla, modules have a numeric suffix.
If you used a numeric suffix for a chain of tiered items but want a completely unique string per prototype, you can set a unique localisation string with .localised_name and/or .localised_description.
Re: Allow numbers at the end of localization strings
Posted: Sun Feb 02, 2020 10:55 am
by Pi-C
Deadlock989 wrote: Sun Feb 02, 2020 10:38 am
Please don't. It is a bad idea which would break a lot of things. For example, in vanilla, modules have a numeric suffix and automatically use the same truncated localisation strings. Many mods currently use the convention as well. You are suggesting that all of those prototypes in base game and the 2000+ active mods on the portal which are currently covered by a single locale string would have to be replicated repeatedly.
OK, I understand that's not optimal.
If you used a numeric suffix for a chain of tiered items but want a completely unique string per prototype, you can set a unique localisation string with .localised_name and/or .localised_description.
Not sure I understand that correctly:
Code: Select all
-- Prototype definition
{
type = "recipe",
name = "bi-biomass-conversion-1",
localised_name = "{bi-biomass-conversion-1}",
[…]
}
-- Locale file
[recipe-name]
bi-biomass-conversion-1=Bio fuel conversion 1
Would the string be used in that case, or would "-1" at the end be removed here as well?
Re: Allow numbers at the end of localization strings
Posted: Sun Feb 02, 2020 11:03 am
by Deadlock989
Actually ... where are you getting the idea that numbers are stripped?
Vanilla explicitly sets generic descriptions:
Code: Select all
{
type = "module",
name = "speed-module",
localised_description = {"item-description.speed-module"},
...
},
{
type = "module",
name = "speed-module-2",
localised_description = {"item-description.speed-module"},
...
},
Seems a lot of things have numeric suffixes - technologies, tile names - and they all have working locale strings. Another example of a numeric suffix which isn't intended to be a series is uranium-235 and uranium-238. They work fine. You must be doing something else.
Re: Allow numbers at the end of localization strings
Posted: Sun Feb 02, 2020 11:19 am
by Pi-C
Deadlock989 wrote: Sun Feb 02, 2020 11:03 am
Actually ... where are you getting the idea that numbers are stripped?
I saw it, I really did! Needless to say, I can't restore that, now that you've spoken it works even with numbers attached. Clearly a case of magic.
Code: Select all
{
type = "module",
name = "speed-module",
localised_description = {"item-description.speed-module"},
...
}
Ooops, syntax error in my example code -- string must be in table, of course!