Problem seems to persist in our game despite the use of GetStringForKeyCode. Users are complaining that random keys are being assigned when using AZERTY keyboards.
1 Like
Hi @KronosFUBAR ,
Thanks for reporting it.
Have you started to see it recently or has it always been the issue with AZERTY keyboards?
i don’t know if you can consider this a bug.
If you look at the azerty layout you will see that if you press the key i highlighted in red it’s first action will always be é in order to type 2 you have to press shift + é
This is the opposite of how a qwerty keyboard does it.
For qwerty you would first type 2 and to type @ you press shift + 2
So for my understanding this is not a bug. The keyboard layouts just do things differently.
To fix your issue you could try changing them using some lookup table like this
local azertyToNum = {
["&"] = 1,
["é"] = 2,
["\""] = 3,
["'"] = 4,
["("] = 5,
["§"] = 6,
["è"] = 7,
["!"] = 8,
["ç"] = 9,
["à"] = 0
}
I haven’t actually tested this but i don’t really see a reason why it wouldn’t work.
Theres 40-50 different major keyboard layouts, how do you expect all of them to be supported with developer created tables like that for their various control schema nuances
Even among the major keyboard layouts, AZERTY is one of the more popular ones.
It has been an issue as far as Im aware
Thank you, we’ll work on that.
AZERTY is definitely among the popular keyboard layouts and we want it to be displayed properly.
1 Like
After more testing with AZERTY and QWERTZ keyboard layouts, it seems like it works correctly with the following caveat. When calling GetStringForKeyCode(Enum.KeyCode.Two) what you’re really asking is: “What’s the string representation of the key where “2” is physically located on the QWERTY keyboard without any key modifiers?”
For instance, when you call:
game:GetService("UserInputService"):GetStringForKeyCode(Enum.KeyCode.W)
it returns W on QWERTY layout, but on AZERTY keyboard layout it returns Z, because that’s what the key would be if you imagine QWERTY keyboard labels over AZERTY keyboard and press W.
Another example:
game:GetService("UserInputService"):GetStringForKeyCode(Enum.KeyCode.Y)
returns Y on QWERTY, but Z on QWERTZ (German) layout.
That’s how ‘1’ turns into ‘&’, ‘2’ turns into ‘é’ and so on. We cannot assume any key modifiers like Shift when we translate between different layouts. As a result it may look strange, but that’s the keys you would actually need to press on a real AZERTY keyboard to get the expected key code in InputBegan/InputEnded/InputChanged signals.
That happens, because for many different layouts you need some baseline from which you calculate all other values. And that baseline happens to be the QWERTY keyboard layout. You can read more on https://create.roblox.com/docs/reference/engine/classes/UserInputService#GetStringForKeyCode