Why can't I use this structure in localised in settings??

[yaim904]

I want to build the description and the name used localised, but it doesn't work the same as for items and entities.

Code: Select all

--in settings.lua:
data:extend({
    {
        type = "string-setting",
        name = "my-mod-always-difficult",
        setting_type = "startup",
        default_value = "yes",
        allowed_values = {"yes", "no"},
        localised_name = { "" , { { "base.one" }, 1 }, { "base.hello" } },
    }
})

Code: Select all

--in local.cfg:
[base]
uno=Count: __1__\n
hollo=Hello, player.

What am I doing wrong??
How do I correct it?

Code: Select all

--Result
Error: [ "my-mod-always-difficult" ].localised_name[ 1 ][ 0 ]

[Pi-C]

I want to build the description and the name used localised, but it doesn't work the same as for items and entities.

Code: Select all

--in settings.lua:
…
  localised_name = { "" , { { "base.one" }, 1 }, { "base.hello" } },
…

You've got the part with "base.one" wrong. Basically, localized strings are a table consisting of a template and optional arguments. The template may be an empty string (that's when you want to concatenate arbitrary strings, like in your example), or a pointer to a localization key following the pattern "Category.Key". In the locale file, this would look like

Code: Select all

[Category]
Key=Your translation goes here!

If the translation contains any placeholders, you can pass on arguments in the same table. So, if you have

Code: Select all

[base]
one=Count: __1__

you can do

Code: Select all

game.print({"base.one", 123})

to print

Code: Select all

Count: 123

If your template is an empty string, the game will print all arguments (from left to right) that you pass on -- as long as they are a string or number. So

Code: Select all

game.print({"", {"base.one"}, 123, "Test"}

would print

Code: Select all

Count: __1__123Test

All 3 arguments passed on to the empty template -- {"base.one"}, 123, and "Test" -- either are strings to begin with, or are translated to strings. (The first argument is a template that contains a placeholder of its own ("__1__"), and we've passed on no argument for that, so the placeholder is printed instead.)

Now let's look at your code again:

Code: Select all

  localised_name = { "" , { { "base.one" }, 1 }, { "base.hello" } },

You've got the empty template and 2 arguments:

• { { "base.one" }, 1 }
• { "base.hello" }

There's nothing wrong with the second, ({"base.hello"} will be translated to a string alright. But the first argument is a bare table! It's not recognizable as a localized string because the outer table contains no template. Changing it to

Code: Select all

{ "", {"base.one"}, 1}

would work and output "Count: __1__1". Not quite what you want yet, but at least it wouldn't crash. To get it right, you should use this:

Code: Select all

  localised_name = { "" , { "base.one", 1 }, { "base.hello" } },

However, this still would silently fail because there's a bug in your locale file:

Code: Select all

--in local.cfg:
[base]
uno=Count: __1__\n
hollo=Hello, player.

You are looking for a key named "one" and a key named "hello" in the category "base" -- but you've never defined these keys! For some reason, you've translated the key names as well as the values. You should never do that, the key names must be the same in all languages! Change that to

Code: Select all

[base]
one=Count: __1__\n
hello=Hello, player.

and you'll get the expected output:

Code: Select all

Count: 1
Hello, player.

[yaim904]

you're right

I built the localized_name wrong
The names in are different local.cfg
And I understood what you escplicate.

Now I can do what I want, build localized_name at runtime.

Thank you, thank you very much.

[Pi-C]

I'm glad I could help.