Can't create shops of items with the letter "i"
entr0py42 opened this issue · 7 comments
Plugin Version
ChestShop version 3.10 (build 165)
Plugin Config
Server Version
Paper version git-Paper-84 (MC: 1.15.2) (Implementing API version 1.15.2-R0.1-SNAPSHOT)
Server Log
What other plugins are you running?
EssentialsX-2.17.1.53
ChestShop
Vault
What is happening?
Can't create shops of items that include the letter i in their names. i turns to ı. Like diamond to dıamond.
What did you expect to happen?
Creating a shop
Additional context
This sounds really strange and hasn't happened for me. Can you please test without any data pack to see if one of them might interfere?
This sounds really strange and hasn't happened for me. Can you please test without any data pack to see if one of them might interfere?
Tested. Same problem goes on. I noticed that this problem is very common among Turkish users.
Uh, are you actually typing an i and not some other symbol that just looks like an i but is actually a different unicode character specific to your language? I faintly recall something like that happening long ago now that you mention Turkish.
No no no, I am typing the actual i because it works when I create a shop for iron_ingot but the i's are the first letters so the plugin makes them capital and it works. But the i in diamond is not capital and it turns to ı. I asked this on many sites and they told me to run my server with "-Dfile.encoding=UTF-8" but it didn't solve my problem. Also using iConomy plugin fixes diamond but breaks everything else like you cannot even use /balance.
Hm, that might have something to do with the changing of the case and that using your server's encoding (which might be set to something Turkish so change the i to an ı because that's how it works in your language?) Afaik -Dfile.encoding=UTF-8 should be able to solve that, make sure to add it before the server jar name as a java startup argument, not after it (changing the system encoding to UTF8 and language to English should work too I guess but is probably not ideal/easily doable) I guess specifying the encoding on every string case manipulation might help work around that issue.
As for why using iConomy seems to solve this: That's probably due to the plugin breaking and as far as I'm aware iConomy hasn't been properly updated in ages.
Apparently that's based on the locale, you might be able to change that in the startup arguments but that would change it globally for the whole server. Gonna look into specifying that in the used method, unfortunately that is using a part of the Apache commons library so I'm going to have to reimplement a small bit of logic there.