To reproduce, run a Fedora install and pick "English (United Kingdom)" as your locale. Proceed to the main hub (or check the displayed keyboard layout, for webUI) and note that the keyboard layout remains "us". The UK uses a different keyboard layout called "gb", and we should default to this for UK installs.

I think this happens because anaconda `set_x_keyboard_defaults` does this:

        locale = get_language_id(self.language)
        layouts = get_locale_keyboards(locale)

so the function is called 'get_locale_keyboards' but really we're looking up by *language*, and indeed that's one of the associations langtable has:

https://raw.githubusercontent.com/mike-fabian/langtable/refs/heads/main/langtable/data/languages.xml

if you search that file for "English", you'll find the language called "English". It has a list of associated locales including en_US and en_GB, a list of associated territories including US and GB, and a list of associated keyboard layouts including us and gb. But there's no mapping here between locales or territories and layouts; there's just a list of layouts associated with the language, with 'us' as the highest ranked. So if you pick any "English" locale in anaconda, you get 'us' as your keyboard layout.

langtable has alternative mappings that would work better in this case. As well as 'languages.xml' it has 'territories.xml' which is better here:

https://raw.githubusercontent.com/mike-fabian/langtable/refs/heads/main/langtable/data/territories.xml

if you search that file for United Kingdom you'll find the territory called "GB" with its own list of associated keyboard layouts, which is one item long - it only contains "gb". You can also find the territory called "US" which has only the keyboard "us" associated with it, Hong Kong with "cn" associated, and so on.

I don't know how much work it'd be to rejig anaconda to do this lookup by territory rather than language, though.