%prefixes should only be necessary for embedded translations where the key isn't at the start of the string.
Longer term we should just drop raw string translation entirely and just translate Translatables exclusively, but this is a stepping stone.
this is a far stretch, since the documentation doesn't mention that the string needs to be tokenized. Anyone passing an array in here is most likely doing so by mistake.
this is a far stretch, since the documentation doesn't mention that the string needs to be tokenized. Anyone passing an array in here is most likely doing so by mistake.
this is not used in the PM core, and is only used by 1 plugin in the whole public ecosystem: BigBrother. It makes more sense to make BigBrother maintainers shoulder the responsibility of maintaining this code, since they are the only ones that need it - besides, if this changed in any MCJE update in the last 5y, nobody has updated it, and nobody has maintained it either due to not having a fucking clue what the thing is for (the documentation is basically nonexistent).
this makes translation usage much more statically analysable.
The only places this isn't used are:
- places that prefix translations with colours (those are still a problem)
- places where server/client translations don't match (e.g. gameMode.changed accepts different parameters in vanilla than in PM)
this also fixes use cases like:
[1] = something;
[0] = match(...)
It made no sense whatsoever to discard the keys anyway.
Language::translateString() already supported named parameters since
forever anyway.
I was never able to reproduce this, but it appears that Windows breaks the character encoding of command parameters (and also unicode environment variables, even though UNICODE_ENVIRONMENT should be set in php-src) when the file path contains Unicode characters (such as Cyrillic).
We workaround this problem using base64, which is an abysmally shitty hack, but not worse than using a subprocess for ConsoleReader in the first place. PHP fucking sucks, and so does Windows.
closes#4353
I moved these to a trait in anticipation of having multiple full Inventory implementations. That's no longer necessary because of the abstraction of SimpleInventory.
