Keyboard layouts and CLDR

Wed Jan 31 12:05:17 CST 2018

Another idea: you can already have multiple layouts loaded for the same
language : For French, nothing prohibits to have a "technical/programmer
layout", favoring input of ASCII, a "bibliographic/typographical" one with
improved characters (e.g. the correct curly apostrophe); the
technical/programmer layout has the spell-checker disabled by default,
while the other has a spell checker enabled by default: whever to activate
the spell checker or not will depend on software where it is enable, but it
will switch automatically it on or off according to the state defined by
changing the layout for the same language.

Switching from one layout to another is easy with the Language bar, this
means that even if you keep the first layout unchanged to match the
national standard, additional layouts can be tuned specifically.

For French fortunately there are two ISO 639-2 codes "fra" and "fre"
(technical and bibliographic) which allows also defining the code "FRA" or
"FRE" to display in the language bar (users should be able to tune the
abbreviation or icon or emoji displayed in the language bar when they
switch languages or input layouts, even if there are defaults, and Windows
can infer a non-conflicting visual identification by adding a digit to the
ISO 639-2 or -3 code (which would be the same as the layout ordering number
in the list of loaded layouts, and used in shortcuts like CTRL+ALT+F1...F9).

2018-01-30 22:24 GMT+01:00 Marcel Schneider <charupdate at orange.fr>:

> On Tue, 30 Jan 2018 08:18:49 +0100, Philippe Verdy wrote:
> >
> > I have always wondered why Microsoft did not push itself at least the
> five
> > simple additions needed since long in French for the French AZERTY
> LAYOUT:
>
> Many people in Fɽanƈë are wondering, but it is primarily a matter of
> honoring
> a countryʼs policies and not interfering with official work. France is
> expected to
> fix itself its keyboarding problems and publish a standard, and thatʼs
> what is
> actually happening. See Shawn Steeleʼs blog post about Locale Data in
> Windows 10 & CLDR:
>
> https://blogs.msdn.microsoft.com/shawnste/2015/08/29/
> locale-data-in-windows-10-cldr/
>
> > - [AltGr]+[²] to produce the cedilla dead key (needed only before
> capital C in French) :
> > this is frequently needed, the alternative would be [AltGr]+[C] to map
> "Ç" without the dead key;
>
> That would be easier than Alt+0199. But Alt+something should yield
> consistently either uppercase
> or lowercase. Then, especially in the United States, not having all
> uppercase letters accessed with
> Shift+lowercase is considered counter-intuitive. And when the lowercase
> letter is directly accessed,
> going through a dead key to get its uppercase is not something I would
> recommend. Therefore,
> all uppercase that are used as initials (not Ù) should be Shift+lowercase,
> and digits in AltGr like on
> a few Latin layouts shipping with Windows, plus a Programmer toggle
> described in:
>
> https://unicode.org/cldr/trac/ticket/10851#comment:2
>
> > spell checkers forget the frequent words: Ça or Ç'.
>
> I never use spell checkers, and when they show up with red wavy underline,
> I quickly try to disable
> them (outside of Gooogle Search). That is why I have typos. [This one has
> occurred unintentionally.]
>
> >
> > - [AltGr]+[1&] to produce the acute accent dead key (similar to
> [AltGr+7è`] giving the grave accent deadkey) :
> > this is the most frequent missing letter we need all the time.
>
> Therefore, the É should be mapped to a live key. But the acute dead key is
> really the missing one.
> Belgiumʼs AZERTY has it. Getting É at least by dead key would have divided
> our trouble by half.
>
> >
> > - [AltGr]+[O] to produce "œ" (without ShiftLock or CapsLock mode
> enabled),
> > or "Œ" (in ShiftLock or CapsLock mode), and
> > [AltGr]+[Shift]+[O] to produce "Œ" (independantly of [ShiftLock] which
> is disabled by [Shift], but without [CapsLock])
> > or "œ" (independantly of [CapsLock], but without [ShiftLock]) :
> > this is needed occasionnaly for very few common words, the most frequent
> omission is "Œuf" or its plural "Œufs".
>
> To repay the Œœ for its exclusion from Latin-1 (due to a Frenchman), it
> should be granted
> two key positions in the Base and Shift shift states, amidst the upper row
> letters.
>
> >
> > - [AltGr]+[A] to produce "æ" (without ShiftLock or CapsLock mode
> enabled),
> > or "Æ" (in ShiftLock or CapsLock mode), and
> > [AltGr]+[Shift]+[O] to produce "Æ" (independantly of [ShiftLock] which
> is disabled by [Shift], but without [CapsLock])
> > or "æ" (independantly of [CapsLock], but without [ShiftLock]) :
> > this is rarely needed, except for a few words borrowed from Latin used
> in biology or some legal/judiciary terminology.
>
> And one spelling of _Lætitia_.
>
> >
> > - Adding Y to the list of allowed letters after the dieresis deadkey to
> produce "Ÿ" :
> > the most frequent case is L'HAŸE-LÈS-ROSES, the official name of a
> French municipality when written with full capitalisation,
> > almost all spell checkers often forget to correct capitalized names such
> as this one.
>
> Thatʼs really something I never understood neither. Why that deadlist was
> not updated.
> Maybe like above: If Microsoft had updated our layout with 'Ÿ', we could
> have wondered
> why they didnʼt add the other missing stuff while they were on it.
>
> >
> > This would allow typing French completely including on initial capitals.
> > All other French capital letters can be typed (ÂÊÎÔÛ with the circumflex
> dead key,
> > ËÏÜŸ with the dieresis dead key which already allows ÄÖ not needed for
> French but for Alsatian or some names borrowed from German).
> >
> > But we have mappings already in the AZERTY layout for:
> > - the tilde as a dead key on [AltGr]+[2é~], even if it is not used for
> French but only for "ñ" or "Ñ" in names from Spanish or Breton,
>
> That didnʼt prevent Breton authorities from refusing it in a first name,
> Denis Jacquerye reported in the wake of the Kazakh apostrophe thread:
>
> http://unicode.org/mail-arch/unicode-ml/y2018-m01/0133.html
>
> > " ÃÕ" not needed at all, /ãõ/ needed only for standard French
> IPA phonetics where we still can't type /ɑɡʀɔɲ/ for French phonetics
> > - the grave accent as a dead key on [AltGr]+[7è`], needed for "ÀÈ" but
> allowing also "ÌÒÙ" not used at all in French.
> >
> > There's not any good rationale in the French AZERTY layout to keep it
> incomplete on capitals
> > while maintaining other capital letters with diacritics composed with
> dead keys but not needed at all in French,
> > except the case of "ŸœŒ" missing from ISO 8859-1 but present in
> Windows-1252.
>
> There is even a way of putting all into the existing dead keys, if
> ‹ circumflex accent › (that is our directly accessed
> dead key) followed by any diacriticized letter did yield its uppercase,
> and followed by b or q, yield æ or œ…
> But that isnʼt what one would call a properly designed keyboard layout.
>
> >
> ----
> > Using the Windows "Charmap" accessory with the "Unicode" charset and
> "Latin" subset is still too difficult to locate the missing letters,
> > as it is only sorted by code point value but still does not cover all
> Latin letters;
> > the Windows "Charmap" tool is usable for French only when selecting the
> Windows-1252 charset (aka "Windows : Occidental").
> >
> > But I don't understand why this accessory cannot simply add some rows at
> top of the table for the current language selected
> > on the "Languages Bar", or why it does not simply features the complete
> alphabet of the current language, sorted correctly
> > according to CLDR rules for that language (not sorted randomly by code
> point value) to make it really usable. If we select
> > another subset, it should also be sortable according to language rules
> (or CLDR default root otherwise) and not according to code point value:
> > this could be a simple checkbox or a pair of radio buttons (binary sort,
> or alphabetic sort).
> >
> > Finally, the Charmap tool should be updated to add missing characters
> that are not covered in the "Unicode" charset selection,
> > even if they are encoded in Unicode and really mapped in fonts: the
> coverage of proposed "subsets" is an extremely old version of Unicode.
>
> I see that as a very valuable feature request. And this one doesnʼt need
> to wait for any national standard
> to get implemented.
>
> Regards,
>
> Marcel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20180131/22540b4a/attachment.html>