The Bug:
The word "blocks" within some "/locate" command feedback messages is always pluralized.
This is an issue because when the value before the given noun is "1", the noun's plural form is used instead of its singular one, therefore making the string grammatically incorrect in some cases.
Affected Strings:
Before reading the table, please note the following:
Words colored in GREEN are correct.
Words colored in RED are incorrect.
Translation Key | Current String | Expected String | String URL on Crowdin |
|---|---|---|---|
commands.locate.biome.success | The nearest %s is at %s (%s blocks away) | The nearest %s is at %s (%s block(s) away) | https://crowdin.com/translate/minecraft/10038/enus-engb#5341660 |
commands.locate.poi.success | The nearest %s is at %s (%s blocks away) | The nearest %s is at %s (%s block(s) away) | https://crowdin.com/translate/minecraft/10038/enus-engb#5341666 |
commands.locate.structure.success | The nearest %s is at %s (%s blocks away) | The nearest %s is at %s (%s block(s) away) | https://crowdin.com/translate/minecraft/10038/enus-engb#5341654 |
Alternatively, instead of having one string cover both the plural and non-plural variants of the word, two separate translation strings could be created, one of which covers the plural variant and the other that covers the non-plural variant.
Steps to Reproduce:
Display any of the affected strings as listed above by using the command provided below and replacing "XYZ" with the string's translation key.
/tellraw @s {"translate":"XYZ"}Look closely at the affected word within the string.
Take note as to whether or not some words within "/clear" command feedback messages are always pluralized.
Observed Behavior:
The word "blocks" is always pluralized.
Expected Behavior:
The word "blocks" would be correctly singularized or pluralized where appropriate.
Linked issues
is duplicated by 1
Attachments
Comments 5
I have been unable to reproduce this bug in an actual in-game scenario. The translation string hasn’t changed, but the behaviour of {{/locate}} seems to have changed, because it now reports biomes as being at least 32 blocks away if you are not already in the biome. For example, in the screenshot below, I walked one block in between running the locate commands:
[media]I did some testing to attempt to find a point that will report as 1 block away from a beach biome, but didn’t find any. The results are shown in the image below, with emerald blocks placed where the biome was reported as 32 blocks away, melon blocks where it was 45 blocks away, and chiseled stone bricks where it was 0 blocks away.
This means that it is now impossible for the command to report “1 blocks away”, meaning this issue is now impossible to observe.
Alternatively, it’s possible that the new behaviour of /locate is itself a bug - do let me know if there’s a report I am unaware of.
Why isn't this going to be fixed?