Breaking changes: aligning furnace.cant_insert_at_source_message_key and the rest

[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.

[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.

[Honktown]

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.

[Honktown]

Small desired edits: Nth being the length of the pre-defined parameters, localised parameters being n+1 of the localised string, etc

[curiosity]

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.

[Honktown]

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

[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.