Minimal setup resource pack. Got this under assets/thingy/lang/en_us.json

{
    "block.minecraft.stonecutter": "Cutter",
    "item.minecraft.stonecutter": "Cutter"
}

Vanilla and Fabric without Fabric API installed:

Using Fabric with only Fabric API installed (fabric-api-0.75.1+1.19.3.jar from Modrinth):

/tellraw @s {"translate":"item.minecraft.stonecutter"}
/tellraw @s {"translate":"block.minecraft.stonecutter"}

I'm developing a public project on Paper server core, so I can't really enforce any additional mods to the players. But since I'm changing the functionality of some existing blocks quite a bit, renaming those blocks is rather important for me.
So, I'm interested in fixing the issue, but I don't mind any workarounds that do not involve asking a player to download any additional mods. As a last resort I'm just gonna edit the display names of the blocks I need when a player gets those, but that's not something I'm looking forward for.

Hi @imDaniX yes this is something that has been an issue for a while. When I last brought this up to @FabricMC/fabric-triage I believe we decided the best solution was to adjust the translation key used for the existing Block, overwriting existing translation keys have a number of issues.

I have seen other mods attempt to work around this issue, but it ends up causing many more problems than it solves. Maybe this is something we need to revist?

Ah my bad, I was under the assumption this was not possible with vanilla res packs. If this is breaking existing res packs then yes this needs looking into 👍

@modmuss50 This is also not a case of a mod not being able to override them, it's a resource pack - and the lang file is even under a different namespace.

Changing translations via resource packs is a vanilla feature and it's very concerning if FAPI breaks that functionality.

Can't change any item.minecraft.* and effect.minecraft.* either, so I'd guess overriding vanilla translation with Fabric installed is impossible in general.
I thought I could override item translations, but it seems that I was able to change item.minecraft.stonecutter only because such key doesn't exist in vanilla, as block items are using their block translation names instead.

You cannot put the lang file in the minecraft namespace as it will/may break vanilla en-us translations on the server. This issue should stay open.

@imDaniX

the lang file is even under a different namespace

Have you tried using the same namespace, just in case? I think different namespaces should work, but in other places, you use minecraft namespace when overriding.

@apple502j Hey, thank you! For some reason didn't even think of that. It now does override the vanilla translation just fine.
Not sure about closing the issue tho, as it still an inconsistency with the vanilla, but my problem is pretty much solved.

it will/may break vanilla en-us translations on the server

Another issue that sounds like it needs fixing 👀

Edit: yeah it makes sense that this isn't supported on the server, I think I didn't read the original message properly. It should still work on the client though as that's vanilla behaviour.

Hmm, from my experiment, this does occur in 1.19.4 prod with latest FAPI but not in 1.19.4 runClient.

The root cause is that the namespaces are queried from hashmap keys, which are in a semirandom order depending on the namespaces. In other words, changing the namespaces by adding other packs can break this, and fabric adds a lot of namespaces.

In simpler terms, xxx:lang/en_us.json and yyy:lang/en_us.json can be loaded in either order. If you want to load after Vanilla make sure to use the minecraft namespace for your lang file (resource pack priorities only apply for exactly the same file).

Closing as this is not a Fabric API bug.