When in singleplayer, if you change the game language settings from english, the internal name ids of all entities appear to change. Please note, I am not talking about the names "displayed" to players as this should be changed, but the internal IDs as well which are the data in datatags and entity lists. This is problematic, because these can be used as arguments in command blocks using @e[name=X] and if these default name ids change with every language you cannot make these kinds of command block arguments compatible for multiple languages.
This may not seem a huge issue due to the fact that we also have the "type" argument which doesn't change with languages, but it actually is. In many cases having both the "name", "type", and "tag" is extremely useful as it allows you to sort entities by 2-3 arguments in a single selector. The name argument is also the best way to discriminate normally-spawned mobs from custom ones as those always are summoned with the same internal name and custom mobs can be given a different one when summoned. This allows for very elegant methods of adding new mobs to the vanilla random spawning so you can get many, many new mobs spawning randomly. I use it extensively in my map and have only recently discovered this bug when reported by my foreign players. Tags are often used for something else so I can't use them to get around this issue every time.
To add incentive for this to be fixed, I should note that this bug does not happen on servers which is strange as I was told that both SP and MP both use a server setup and language settings are only supposed to change what is displayed in chat or overlays to the player. Not ingame data on datatags which can cause compatibility issues.
Here is a quick example of something that is currently impossible to make work in all languages as a result of this issue:
/testfor @e[name=unknown]
to detect the bobber entity on fishing rods only works in english. The name "unknown" which is the only way in java to detect a bobber since it has no entity id, changes in other languages like french and german (tested) making detecting the bobber entity for use in custom modules or other systems impossible in multiple languages.
Comments 6
Oh really? I had heard a rumor this was a bug and that all games, even SP servers would be running english in the background and only change what was displayed as it was displayed. I did not realize the language wasn't implemented this way and thought it was a new bug.
That is a real shame. Just some clarification on what you said there about bobbers. So if I select ALL entity types except something like players, they will be missed because they have no "type" id? I know if I have no type argument they are tagged too because I tried that. They show up on the testfor list as "unknown" in english.
I would love to hear from Mojang if this is really not worth fixing as it seems uneccessary to do it that way. One last example of the usefulness of the name tag:
little known to most creators you can also use it to manually select a specific TYPE of item in one command. The main way I've seen most people detect items is to use a scoreboard searching if a particular id type in the datag and then tagging it. Then they operate on items with that type of tag. However, I have learned you can just search for the extended default name in a single selector and find it immediately without use of scoreboards. It is the name it displays back to you from testfor: item.X.X.
Excluding the type parameter just means you're not looking for any specific entity type in particular.
The method involves using /scoreboard to assign a tag to entities that have a savegame ID or alias and then targeting entities that do not have that tag (i.e. they don't have a savegame ID or alias):
/scoreboard players tag @e[type=minecraft:skeleton,tag=!savegame] add savegame
/scoreboard players tag @e[type=minecraft:creeper,tag=!savegame] add savegame
...
/say Entities with no "savegame" tag: @e[tag=!savegame]As for assigning a savegame ID to fishing bobbers, that wouldn't be possible since bobbers are not supposed to be saved to chunks as they are meant to be tied to the player. However, like lightning bolts and players (which are also not savegame entities), they can have an alias that can be used to target them (though it doesn't work for lightning bolts currently, see MC-64623). But the report for doing so was closed as "Working as Intended": MC-47832
EDIT: Concerning item names, you should not target item entities by their name like that. That is another bug that, when fixed, would require you to change all commands targeting such entities: MC-73495
thanks, that isn't as easy to use as name=unknown, but I'm happy to know there is an actual workaround for other languages. I thought I was stuck there! Thanks skyliner.
Note: I haven't been using the direct names for items much but I did note it worked (for english players at least). The main thing I found it useful for was for command blocks targeting modded entities. I found several modded mobs for which I couldn't get a type argument to work (maybe they didn't assign a unique one?) but for which their extended name did, such as entity.imp.name. This same issue means if players load many mods with my map the workaround you described above doesn't work anymore since bobbers are no longer the only excluded entity. However, in that case it is an unfortunate incompatibility. The grappling hook is the only device I've had so many issues with with mods and language settings so it may just be dropped in the future...
I couldn't get a type argument to work (maybe they didn't assign a unique one?)
Don't forget the namespace, if none is provided it defaults to the normal namespace (minecraft: ) which mods don't use.
The only reason this doesn't happen on servers is because it cannot select a different language.
Everything gets changed to the appropriate language, this includes the names commands return.
This includes item names, block names, entity names, etc.
This is by design.
Side note: name=unknown is not the only way to target bobbers, you can target them by tagging all entities and removing it from savegame ids, or tag all savegame ids and target the untagged.