Page 1 of 1

Breaking changes: aligning furnace.cant_insert_at_source_message_key and the rest

Posted: Fri May 23, 2025 10:31 pm
by Honktown
A small discrepancy in some of the new localised things for furnaces, and maybe other prototypes. It was decided they used plain strings, omitting the table of localised strings.

Considering localised strings in the regular use has tables, I think there should be an alignment one way or the other to simplify things: 1) all localised strings in data omit tables, or may optionally omit tables and be interpreted as localised strings, or 2) the newer parameters be changed to localised strings for consistency.

Re: Breaking changes: aligning furnace.cant_insert_at_source_message_key and the rest

Posted: Fri May 23, 2025 11:55 pm
by curiosity
It receives a parameter from the outside. How do you suppose that should be passed to a fully specified localized string?

Hence also the word "key" in the name of the property. The key being the name of the locale string it uses to look it up. If you want to change it to a localized string, it can't be called a key anymore.

Re: Breaking changes: aligning furnace.cant_insert_at_source_message_key and the rest

Posted: Sat May 24, 2025 12:46 am
by Honktown
curiosity wrote: Fri May 23, 2025 11:55 pm It receives a parameter from the outside. How do you suppose that should be passed to a fully specified localized string?

Hence also the word "key" in the name of the property. The key being the name of the locale string it uses to look it up. If you want to change it to a localized string, it can't be called a key anymore.
1) I think they should automatically populate the numbered parameters, which is literally what they do at the moment, they just don't leave open specifying more. Pick a result: trample parameters given (ignoring [n] of the table) , or start values provided from the localised string at the Nth+1 index.
Starting from:
cant_smelt=Can't smelt __1__ because it won't __2__.

Case a) {"my_category.cant_smelt", nil, "melt"}
Case b) {"my_category.cant_smelt", "melt"}

2) ' If you want to change it to a localized string, it can't be called a key anymore. '
I don't understand this statement. Yes. Changing the type permitted changes the type permitted.

Re: Breaking changes: aligning furnace.cant_insert_at_source_message_key and the rest

Posted: Sat May 24, 2025 12:49 am
by Honktown
Small desired edits: Nth being the length of the pre-defined parameters, localised parameters being n+1 of the localised string, etc

Re: Breaking changes: aligning furnace.cant_insert_at_source_message_key and the rest

Posted: Sat May 24, 2025 12:50 am
by curiosity
Honktown wrote: Sat May 24, 2025 12:46 am 2) ' If you want to change it to a localized string, it can't be called a key anymore. '
I don't understand this statement. Yes. Changing the type permitted changes the type permitted.
Can't be called a key. Because it's not a key. And right now it's called a key.

Re: Breaking changes: aligning furnace.cant_insert_at_source_message_key and the rest

Posted: Sat May 24, 2025 12:58 am
by Honktown
curiosity wrote: Sat May 24, 2025 12:50 am
Honktown wrote: Sat May 24, 2025 12:46 am 2) ' If you want to change it to a localized string, it can't be called a key anymore. '
I don't understand this statement. Yes. Changing the type permitted changes the type permitted.
Can't be called a key. Because it's not a key. And right now it's called a key.
Yes, and that's why any such changes would be a breaking change. Change the type and start using what it would be, a localised string, instead of a key to a strict only-one-parameter localisation

Re: Breaking changes: aligning furnace.cant_insert_at_source_message_key and the rest

Posted: Sat May 24, 2025 1:01 am
by curiosity
Change type and name. Then why remove the old property now? This breaking change can be postponed till 2.1. It's just a regular feature request aside from that.