Allow custom system chat labels

[Mailaender]

Closes #17551.

[dragunoff]

I tried tackling that in #17563 but decided it's worth first figuring out a path forward for translations and for configurable strings (and whether they can be treated as the same thing, see #17563 (comment)).

And I think that we should not be mixing visual styles with text strings in ChromeMetrics. Perhaps a new class should be created to handle them 🤔

[pchote]

We already know what that new class is: the translation strings file.

I wish that somebody could decide to take the lead on planning and (then only after the plan has been reviewed for technical feasibility) implementing the code-side string translation backend. We have wasted so much time motivation in arguing and rejecting workarounds that all come back to this one thing.

[reaperrr]

I wish that somebody could decide to take the lead on planning and (then only after the plan has been reviewed for technical feasibility) implementing the code-side string translation backend. We have wasted so much time motivation in arguing and rejecting workarounds that all come back to this one thing.

That's one of those things I would have tried to tackle ages ago if it didn't exceed my abilities.

I'd gladly volunteer to help out with any 'grunt work' involved, but as long as nobody else tackles that first hurdle, I can't help with the rest.

[Mailaender]

Moved it to the translation system.

[pchote]

My comment about reviewing the plan for technical feasibility before making any changes was important: we know that the current stub translation code is not suitable, so it would be a mistake to start moving anything to it now.

[Mailaender]

My explorative implementation here proofs that it is indeed already suitable for this task.

[pchote]

This is missing the point that the current stub implementation is hazardous to project maintainability due to having no safe handling for format string variables (which will essentially guarantee un-lintable runtime crashes when translations get out of sync) and no integration with existing formats for crowd-sourced translations. It also ignores the other benefits that would come from a proper translation system such as support for distinguishing zero/one/few/many and genders.

[Mailaender]

This is just moving a hard-coded string into a .yaml so it can be translated at a per mod level.

[abcdefg30]

Tbh, I think the best way forward here is to move this back to metrics. As weird as it is, using the incomplete/broken language stuff seems even weirder to me. One problem with metrics is still that this would break in the future if we add translation support, but not as bad as when placing this in the language files. Otherwise it would likely be better to close this PR.

[Mailaender]

Where would you place the hard-coded string instead?

[abcdefg30]

I can only repeat #18044 (comment): We already established putting it in metrics isn't great, but using the current language "system" is even worse. So I'd put it into metrics unless someone else has a better idea. (An we should really think about removing the stub language stuff.)

[Mailaender]

You were both adding so much worry bearing afterwards that I got confused. Reverted.

[pchote]

https://github.com/OpenRA/OpenRA/wiki/Changelog-(bleed)/_compare/1fa06ede806db9dac9e3692c8b277d22e3c2b204