Localised string "if key is unknown use something else" (or equivalent)

[eradicator]

What?

I want to specify a localised string so that if one component of it produces an "Unknown key:" it uses something else instead.

Speculative example:

Code: Select all

tooltip = {'my.tooltip-preset',{item-description.wooden-chest,my.no-description-placeholder,mode='use-first'}}

Why?

(Disclaimer: I don't really care *how* this is technically solved. So above is only a wild idea. I'm totally fine with anything better. Like making it possible for mods to know if a localised string is valid or not :p)

The problem is that certain localised strings can not be used in good looking mod guis because they produce garbage 90% of the time (i.e. "Unknown key:"). A prime cause of this are item descriptions, because there's only very few that have them. And from the mod side it's impossible to know if any given loc_string is valid or not.

Code: Select all

/c
game.player.gui.center.clear() 
game.player.gui.center.add{
 type="label",
 caption=game.item_prototypes['wooden-chest'].localised_description
 }

This is not limited to base keys though, for example i have a use-case for localised surface names, but i want to fall back to the internal name if me (or the surface-creating mod's author) haven't localised a name yet.

This is mostly annoying on tooltips, but it'd be awesome if a generic solution for all localised texts existed.

A good example is also the mod on the portal (which i can't find right now...) that extends the tooltip of mod settings to include the default value. But because most settings don't have a description it looks like this most of the time:
From Arumbas Stream @17:33

unknownkey.png (51.91 KiB) Viewed 4938 times

[eradicator]

Maybe a locale.cfg specification would be simple enough to be realistic?

Code: Select all

[my]
tooltip-preset=Lorem ipsum __1_or_2_or_3__ dolor sit amet.

[Wiwiweb]

What?

I would like to request a locale operator to silence the "Unknown key" error in the case of a missing locale key. It could look like this:

Code: Select all

{"?", {"entity-description.underground-belt"}}

Why?

Currently, if you print a LocalisedString that does not actually exist, it displays a string that says: "Unknown key: ..." and there is no way to know in advance that this LocalisedString doesn't exist.

unknown_key.png (53.15 KiB) Viewed 4895 times

This is a problem for us when we try to *add* to existing descriptions. We append a "Cannot be placed on:" string with any existing description. If there is actually no description, it shows up like this:

k2_missing_description.png (38.13 KiB) Viewed 4895 times

We do it like so:

Code: Select all

placement_restriction_line=[font=default-bold][color=#f5cb48]Cannot be placed on: __1__[/color][/font]\n__2__

Code: Select all

prototype.localised_description = {"space-exploration.placement_restriction_line", disallowed_locale, prototype.localised_description or {"entity-description."..prototype.name}}

Players often think that is a bug even though no information is lost here. The new "?" operator would allow us to hide that unknown key error.

[Honktown]

For consideration: in terms of behavior, it would make sense to return "" (empty string) as a result, similar to how {"", results in concatenation, with each term resulting in a string before concatenation. The alternative which would not follow normal expectations, is, if the first element of the following string can be translated, replace on *that*, vs replace the entire translation of that table with "".

The difference probably isn't clear until a parameter is used (indentation to make it clearer):

Code: Select all

{
  "",
  {"category.string_known_to_exist"},
  {
    "?",
    {
      "assumed_category.assumed_key_with_parameters",
      {"cat.param1"}
    }
  }
}

Good:
{
  "",
  "Known string. ",
  ""
}

Bad:
{
  "",
 "Known string. ",
  {
    "",
    {"cat.param1"}
  }
}

Without parameters, {""} could replace unknown translations earlier in the translation pass. It results in the weird behavior/errors with parameters though, if they're not discarded.

[Honktown]

A more compact form which was suggested: putting the "?" at the start of a localised string: {"?entity-name.abc"}. A little less overhead, and the only risk is if someone made a locale category with a leading ? (if that's even possible) which is a "breaking change" but... very small.

[FuryoftheStars]

Aye, this would be nice to have!!

[lyvgbfh]

This would solve my biggest headache with modding. The case presented can't reasonably be solved as things are currently, and I think the suggestion for new behavior is a good solution as long as the logic is clear and documented.

[Stringweasel]

+1

In Space Spidertron and Fluidic Power I dynamically generate entity prototypes based on existing ones, and there's no way to cleanly modify and retain the original description.

[Honktown]

One, possibly small way to do it: make a locale key for unknown key, instead of hard-coding it. Then instead of e.g. unknown-key=Unknown key: "__1__", it could be replaced with unknown-key= in a mod that wanted to silence it. It would have to be "turned on" or "turned off" at the mod level (dependency issues coming up when one mod blanks it, and another mod wants it back). That could be resolved as one mod can *always* come last dependency-wise, and all it has to do is define the locale key.

I'd even offer to make a basic mod to help that, as one could format a log print of 'dependencies' for all current mods during data, and *that* text could be copy and pasted in the extracted mods info.json to bring back the original locales for unknown-key (for that developer, anyway. then they disable the mod once they're satisfied).

[robot256]

+1

In Multiple Unit Train Control, I copy-and-modify locomotive entities procedurally, but have a hard-coded list of entities that have descriptions. This means information is lost if a mod has a description that I have not manually inspected yet.

[Bilka]

See also 71553 - this suggestion would be more flexible.

[Xorimuth]

BurninSun on discord also proposed the following syntax similar to __plural_for_parameter_1_{...}__ that we already have. Something like __error_for_parameter_1_{true=Not found|false=__1__}__

Personally it seems a bit clunky but it is flexible.

[FuryoftheStars]

See also 71553 - this suggestion would be more flexible.

I'd be in support of that, too.

Maybe up to a dev or mod, but maybe the threads should be combined?

[Genhis]

Merged similar topics.

This is implemented for the next release as a "fallback group" format. The format picks the first correct parameter in a localised string. The key is always "?" and is ignored in the translation. If no parameters are correct, the last one is returned.

Code: Select all

{"?", {"", {"entity-description.furnace"}, "\n"}, {"item-description.furnace"}, "Optional fallback value"}

1. If `entity-description.furnace` exists, it is concatenated with "\n" and returned.
2. Otherwise, if `item-description.furnace` exists, it is returned as-is.
3. Otherwise, "Optional fallback value" is returned. If this value wasn't specified, the translation result would be "Unknown key: 'item-description.furnace'".

[FuryoftheStars]

Merged similar topics.

This is implemented for the next release as a "fallback group" format. The format picks the first correct parameter in a localised string. The key is always "?" and is ignored in the translation. If no parameters are correct, the last one is returned.

Code: Select all

{"?", {"", {"entity-description.furnace"}, "\n"}, {"item-description.furnace"}, "Optional fallback value"}

1. If `entity-description.furnace` exists, it is concatenated with "\n" and returned.
2. Otherwise, if `item-description.furnace` exists, it is returned as-is.
3. Otherwise, "Optional fallback value" is returned. If this value wasn't specified, the translation result would be "Unknown key: 'item-description.furnace'".

Hey, that sounds great to me! Thank you!!