Add Canadian French input locale

[Nebuleon]

Description

This pull request introduces the Canadian French input locale, otherwise known as French Canadian or French (Canada), to QMK. This is not the input locale called "Canadian French (Legacy)".

The commit includes declarations in the required .hjson file, the keymap header and the file for use with SEND_STRING, as well as the reference to those files in the documentation. Key names start with FC_ for French Canadian; as for their 4-character names, I have reused the names of keys that output the respective characters in any other existing input locale; and I have validated the key labels, keyboard diagrams, keycodes, Shift and AltGr use, as well as the lookup tables for the SEND_STRING macro. The input locale works on both Linux and Windows using both layers that output each individual key as well as a SEND_STRING that sends the entire ASCII table.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation
• Other: Input locale (quantum/keymap_extras)

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[Nebuleon]

GitHub Actions pointed out that the generated file had one extra newline compared to what is expected, so I removed it in a second commit, and now the regen check succeeds (and is no longer showing up in the list). This should now be good for review.

[fauxpark]

Windows OSK doesn't have a Euro symbol here.

[sigprof]

Apparently the Euro symbol is a somewhat recent addition to the Canadian French layout — it appears in Windows 10.0.22598.1 (which is apparently a preview release of Windows 11 23H2, released in the Canary channel on 7 April 2023), but does not appear in Windows 10.0.17134.1 (Windows 10 1803). No idea whether that symbol appears there in any proper releases of Windows 10 and Windows 11 — kbdlayout.info does not have any intermediate versions between those two.

[Nebuleon]

The Euro symbol is indeed not output by AltGr+E on Windows 10 22H2 19045.3155, but KDE has had it for a while.

[Nebuleon]

Is it policy to restrict input locale declarations in QMK to only what the most common released versions of Windows can do? If so, I can remove FR_EURO from the list.

[Nebuleon]

And another commit because I realised that, while I had checked that everything that was in the keymap was emitting the correct keycodes, I had not checked whether everything that should have been there was indeed there. I missed FR_RABK, also known as >, and added it to 423b6bf.

[github-actions]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[Nebuleon]

Hi there.

This pull request is still relevant, and I have one outstanding question:

Is it policy to restrict input locale declarations in QMK to only what the most common released versions of Windows can do? If so, I can remove FR_EURO from the list.

[fauxpark]

Basically, yes, because it's better to have keycodes "omitted" from the headers compared to Windows 11, than to have users complain about the keycodes not working on older versions. Perhaps this could be mitigated with notes in the docs, but I have observed many times already users not seeming to even notice or understand the last three columns of this table. So I have little faith it will do much.

[Nebuleon]

Right. I have deleted FR_EURO from the data to ease that burden from user complaints. It's still easy for a user to use ALGR(FR_E) if they need the euro symbol in Canadian French.

I do notice that the PR Regenerate Files test fails, after using this command:
qmk generate-keycode-extras -l canadian_french -v 0.0.1 > quantum/keymap_extras/keymap_canadian_french.h
I'm not sure why PR Regenerate Files wants the final newline removed, but I will delete that too,