a: Sending "The value: @foo" and a table {foo = "the value"} in,and getting the translated "Der Wert: the value" out.
This sounds suspiciously similar to minetest.translate. I am confused.
b: Sending "An Item made of +x from +y" in, and getting "Ein Gegenstand aus +x von +y" out being able to use result:gsub('*.', {['*x'] = 'whatever', ['+y'] = 'something'}) with the return value of the translation value
Again, this sounds like what minetest.translate does for you, but with multiple parameters. I am still confused.
c: Not having to write the following to get a translation of a string with a line break:
OK, I agree this is indeed stupid.
As long as the translator has limited possibilities to actually translate the string the result has to be post-processed.
There is a fix and the fix is called Gettext. :D
This is not a solution: strings in the translation file still need to use the numerical arguments.
Sigh ... Seems like the client-side translations are broken by design :(
No, the system is definitely not BROKEN because of numeric arguments. There is nothing wrong with that, it's just a different syntax than the syntax you desire.
If we call the first argument “@1” or “@whatever” really doesn't make a difference to me.
I seriously don't understand why you make such a big deal about this. Not even Gettext has this feature, and I don't miss it.
I am a major translator of other software projects (including Cataclysm: Dark Days Ahead. If you know this game, you know the crazy amount of text). My voice definitely has weight here. From my years of work, I can tell you that, frankly, that “numeric parameters” were NEVER a problem to me. Actual string problems are very different, like string concatenation, etc.
unhandy, and limited, and non-standard
Unhandy: Yes, because the toolchain is missing. I talked with nore about that and nore agreed to fix this; probably by adapting the intllib toolchain or whatever (because the format is very similar).
Limited: Well, yeah. Having no proper plural support sucks.
Non-standard: I have to agree because it's not Gettext or any other widespread system (well, there aren't many, actually, the only other one which comes to mind would by Qt but this does not apply to Minetest, of course). I hope the switch to Gettext will be made eventually.
The switch to Gettext will fix all 3 of “unhandy”, “limited” and “non-standard” in one go.
Can I at least insert "@5@2@8@9@4@4@4@4" and get what I expect (having @N replaced with the corresponding value, multiple times, mixed)?
I don't know, I haven't tested it. I only tested whether a different order from the original works (and it works). But why don't you test for yourselves? This is a valid use case. If it doesn't work, I'd consider it a bug.