Re-arrange keyboard languages and documentation

[jreklund]

This PR re-arranges all language files an "translator" will need to modify. Moving the language parts out from the main file, so you can focus on the translation. Will also help with preventing code conflicts. Adapting a new naming standard for said languages.

• Include ANSI/ISO keycodes layout images to have on a second screen for reference (later on documentation)
• Include fallback language (en-US) in case your config.js have an invalid language
• Re-arrange languages based on the order on Dygma website; then alphabetical; then non-language
• Use en-US (American English) and en-GB (British English) naming convention
• Add support for en-GB (British English)
• Don't seperate layouts by type (ANSI/ISO), you can use them on any device; Raise ANSI, Raise ISO and Defy
• Include inline documentation in the three main language files
• Re-draw all language flags using the same template so that all flags have the same offset

[zoehneto]

I think the correct language code for the Swiss keyboard would be de_CH, not swg_CH, as it refers to Swiss High German, not the Alemannic dialect.

[jreklund]

Sorry if I was incorrect @zoehneto. I just grabbed the most fitting one from CLDR - Language-Territory Information.

[jreklund]

I have now updated this PR to change Swiss German to de-CH. Confirms with kbdlayout.info datasheet as well.

[zoehneto]

The issue with that list is, that it doesn't really map to how most keyboard layouts are defined (which is typically by nation state). From a keyboard perspective it would make more sense to speak of a Swiss layout (which has German, Italian and French subvariants which only differ in two or three keys) and then there is a German layout and that is quite different. At the same time you have layouts like colemak, bepo or neo, which are optimized for usage with a certain language but obviously don't have a corresponding code in the unicode list.

[jreklund]

Thanks for your feedback, I have updated the documentation to refer to Microsoft and Keyboard Layout Info instead.

Yeah, it would be more logical to have Swiss first, not the other way around. It doesn't match for alternative layouts, but it's a start. Right now you need to make up your own for those, e.g. fr-bepo and de-neo. At least we don't need to add Colemak as you can remap your layout however you want.

[AlexDygma]

Hey There @jreklund ! I have tried to fix your code but as @zoehneto stated, we have an issue with how to name keyboards like BÈPO, apart from merging all the recent changes that have conflicts, i can solve that part but will leave out the non-standard layouts, do you know how do you want to proceed?

[jreklund]

We got two routes to choose from @AlexDygma. Either we go with "base language" of the keyboard so en-EU (EurKEY), fr-bepo and de-neo or we store those non-standard versions under xx as e.g. xx-eurokey, xx-bepo, xx-neo.

---

There are pro/con to both, if we store them with the base language we know what these custom layouts try to solve. But there may be conflicts. Apparently EU exists as an language code, but maybe not as an keyboard. So I may have created an conflict there.

According to ISO 3166-1 alpha-2; The code XX is being used by WIPO as an indicator for unknown states, other entities or organizations.

So xx-eu, xx-bepo and xx-neo would be safe according to that specification.

Path; xx/EU, xx/BEPO, xx/NEO

Con: May be hard to see what language they belong to

---

If we want the base language, we could also introduce a second code; en-xx-eu, fr-xx-bepo, de-xx-neo.

Path; en/xx/EU, fr/xx/BEPO, de/xx/NEO

Pro: We know what base language they belong to

---

There are also the alternative; xx-en-eu, xx-fr-bepo, xx-de-neo, if we want to lock in the base ISO-code for only "real layouts".

Path; xx/en/EU, xx/fr/BEPO, xx/de/NEO

Pro: We keep real languages separate, creating a clean structure

[jreklund]

• development branch have been merged and conflicts resolved
• Updated BÉPO and removed unoffical symbols (emojis)
• Renamed community/third-party layouts to en-US-eurkey and fr-FR-bepo "standard"

The hardest part is to decide on what order it should be shown in the UI. Right now I have them in "Keycaps", "Official" and "Community" order. But for that order to look good we kinda need a seperator in the UI (don't know how to do it), and it's not obvious to the user why that order exists.

Positioning BÉPO under French, with the name "French (BÉPO)" seem natural to the user but where should EurKEY go? "English (EurKEY)", as it's base is English? When does a keyboard layout stand on it's own?

Should we always use a natural sorting order in the UI, so that Danish are on top, creating A-Z structure there?

[jreklund]

Hi, after a good night sleep I discovered that more code needed an update. Also fixed an bug introduced after incorrect merge of development branch

• Renamed community languages to en-XX-eurkey and fr-XX-bepo; <language>-<undefined-country>-<name>
• Macro editor didn't use the getLanguage helper function to load layouts.
• Create an translator helper and add the missing languages.
• Updated the sorting of language in the UI to A-Z, with the exception that English (US) comes before GB.

[AlexDygma]

Great @jreklund!

I really like the route that you chose, it's cleaner and easier to maintain, we still need to properly reorganize the UI for this but I will call @thiagohernandez for that 😄, when we have an idea about what to build i will create a local branch on which i will merge your work and add there the new UI 💪

[AlexDygma]

you can keep adding code or bugfixes here if you need to!

[jreklund]

Hopefully I don't find any more bugs, I have no known bugs at least. Below are the order it's displayed in the UI.

Danish
English (US)
English (GB)
EurKEY (1.3)
Finnish
French
French (BÉPO)
German
Icelandic
Japanese
Korean
Norwegian
Spanish
Swedish
Swiss German

[jreklund]

• Added "british" and "frenchBepo" to legacyLanguage translator as they officially exits in 1.3.4 and later.
• Changed "Select language" into "Select keyboard layout" under Preferences, as you don't change Bazecors language. Some Discord users don't think to change "language", so they end up with ANSI instead of ISO and have missing keys.

[jreklund]

• Forgot to install ESLint, those errors have now been fixed.

[jreklund]

• Create a enum with most frequently used base-code for modifiers in keymaps (only en-GB use them atm)
• Removed empty lines in all language files
• Re-wrote Bépo as it didn't use correct alpha and symbols

[jchatard]

Hi @AlexDygma if I want to contribute a new layout, do you think it makes sense for me to add it using this branch as a starting point. Or is this too early? I don't mind keeping a separate branch for now. I'm still waiting for my Defy :-)

[xxxP3g4s0xxx]

Hello everyone, I wanted to ask the same question as @jchatard; while waiting for my new Defy to arrive, I was preparing the layout it-IT.

[jreklund]

• PR updated to solve the conflicts (for the last time?).
• Added "frenchOptimot" to legacyLanguage translator as it officially exits in 1.3.7 and later.

[alexpargon]

• PR updated to solve the conflicts (for the last time?).
• Added "frenchOptimot" to legacyLanguage translator as it officially exits in 1.3.7 and later.

Hey there @jreklund !!

Yes, for the last time 🤣

I will merge your PR on the next release as you have updated it and now we are working on a full typescript rewrite of the app, so we have to close everything that needs to be closed

[jreklund]

Thanks! I will create some new PR:s to improve language creation after you are finished with the TypeScript migration. 👍