39aldo39 / klfc

Keyboard Layout Files Creator
GNU General Public License v3.0
215 stars 13 forks source link

LocalIDs #47

Open iandoug opened 2 years ago

iandoug commented 2 years ago

Hi

Do you perhaps have a convenient list of locale IDs?

Microsoft's page is a mess. https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-8.1-and-8/hh825682(v=win.10)

Is there a reason why you don't use their format eg 0409:00000409 but only the 00000409 part?

Thanks, Ian

39aldo39 commented 2 years ago

I also don't really know a lot about the locale IDs. The only reason they are included is because KLC uses them. I didn't even know that apparently KLC uses only part of the ID.

iandoug commented 2 years ago

I'm asking because at the moment (as per other thread) I'm only doing the Conventional ANSI, and English only on top of that.

But there are people trying to make Spanish/English, Dutch/English, even Russian/English layouts and then locale IDs become a bit confused ...

I've even got a layout aimed at Southern Africa that tries to cater for over a dozen languages.

DreymaR commented 2 years ago

The 4-digit part before the colon is the language LangID, which is not necessarily the same as the keyboard ID after the colon. There may be many LocIDs for each language ID. It's the LocID that uniquely identifies a keyboard layout, the LangIDs are for sorting these into which languages they belong to. So KLC shouldn't use the LangID as that's a job for the OS, but define the layout's LocID only.

EPKL has a table of layout LocIDs, and AHK has some functionality to tap into the MS DLL functions for the IDs. In case that's helpful.

https://github.com/DreymaR/BigBagKbdTrixPKL/blob/f443218dc569041df8e83e05d76973e58571fa51/Files/EPKL_Tables.ini#L77

iandoug commented 2 years ago

@DreymaR

That's what worries me ... the scheme does not cater for keyboards meant for more than one language.

Thanks for the table :-)

Cheers, Ian

DreymaR commented 2 years ago

I think you're wrong? The "scheme" consists of a LangID for each language and a unique LocID for each keyboard layout. To use a layout with more than one language. use couplets of LangID1:LocID1 LangID2:LocID1 etc where both are applied. Is anything stopping you from doing that somehow?

Mostly when designing keyboard layouts however, you don't need to worry about LangIDs but focus on the keyboard layout's unique LocID alone.

I can see how it gets somewhat restricting that each layout has to belong to a language in a LangID:LocID pair. But that's typical of OS implementation for you, and as I said it's solved by duplicating your layout to all languages it belongs to. For most languages there are some tweaks you should do to accommodate better locale typing anyway.

iandoug commented 2 years ago

Ah. Did not know you could specify more than one set. Linux does not concern itself to that level with such things, just as far as "region (eg "_us") AFAIK.

I'm generating input files for KLFC and was worried about wrong values in the LocaleID borking someone's install.

I have generated the files for all the "conventional" layouts I have, now need to Take Courage and try a test install and uninstall, and then find people able to test the Win and Mac versions.

I notice the xkb file does not include the usual include "level3(ralt_switch)"

... do I need to add that in to the files I feed KLFC ?

Thanks, Ian