Hi, due to compliance checks from our publisher, we are required to implement and support (or explicitly not support) all keyboard keys in existence. So far, we implement a range of supported keys and for those we do not support, we show a “not supported icon”.
Now, we are facing an issue where some keys are not localizing to their AZERTZ/QWERTZ counterparts.
For example, Delete -> suppr (AZERTZ) / ENTF (QWERTZ), Insert -> Inser (AZERTZ) / Einfg (QWERTZ). This means we have not really a choice but to detect what current keyboards that the user has plugged in (and potentially a runtime swap if multiple keyboards are connected).
How do we set up a detection of the current keyboard layout?
[Attachment Removed]
Hi,
There is some guidance available on [this [Content removed] but generally it’s best to handle this at the Enhanced Input level by providing some presets for common keyboard layouts (along with player remapping for less common ones). That said, it seems the concern here is more the localization of the key names? There isn’t going to be a good way to determine what is physically printed on the keycap corresponding to a given FKey, so our general recommendation is to fetch the label through Enhanced Input’s player-mappable binding, get the FKey’s display name, then localize those display names as best as you can. Basically, rather than try to localize based on keyboard layout, you’d localize based on active language (and assume the user’s keyboard matches that locale). Anything more accurate than that would require a pretty bespoke implementation, and could still be quite error-prone since keycaps on the physical keyboard could still be swapped out to not match the expected names based on the layout.
Best,
Cody
[Attachment Removed]