Re: Effectiveness of locale support

In my previous e-mail Iʼve... a typo. Please read *ethnographer* with two greek h's, not one.

And I've started proving that the Canadian Multilingual Standard keyboard is far better than its competitors. No wonder: The only reason it has been created, was to make something better fit for French (and many other languages) to be written in Canada and particularly in Québec. And the reason it has been standardized, was that the users who have been asked for their opinion, clearly preferred the new keyboard over the existing ones (even if at the beginning, it wasnʼt multilingual, and was restricted by the lacks of Latin-1).

One could even make it a rule: Usually one is likely to consider that a national government and standards body are in a far better place to learn about—and cater for—user preferences, than anybody else.

Denying people to write correctly their language and to use their preferred keyboard, is illegal discrimination. If there isnʼt any legal provision prohibiting this discrimination in Québec, thatʼs probably because Canada is not a part of the European Union, I infer from what Richard wrote on 28 Aug 2015 at 00:09:

> I may have scared them into
> silence by noting that people changing code because of one particular
> *new* sentence in Section 23.2, namely:

> > P2S4: Note in particular that the word joiner is ignored for word
> > segmentation.

> are at risk (but see below) of putting themselves in breach of the UK's
> 'Equality Act 2010'; more generally, they may be in breach of
> transpositions of the EU Racial Equality Directive (2000/43/EC). You
> don't need to have racialist intentions to be in breach.

http://www.unicode.org/mail-arch/unicode-ml/y2015-m08/0222.html

To better mind whatʼs on, I invite you to take a glance at some details:

The keyboard symbols that are puzzling strangers at the point that they may ask «where is the right Control key», are on the keycaps because they are in ISO 9995-7 and allow for a-linguality instead of bilingual overload. However, as they stay missing evidence, one is about to set keycaps back to text.

I wrote that the Canadian Standard keyboard is a genuine ISO 9995 implementation. Thatʼs true for the original standard. Unfortunately, this was altered when it was implemented on Windows. This issue is about the group selector, which should be Shift+AltGr, not right Ctrl, and should be remanent. The ISO standard only allows for THREE levels per group; hence, again, no Shift+AltGr level.

That fully ISO 9995 conformant keyboards are restricted to three levels per group, is an accessibility issue: No user must be forced to type his language with more than *two* fingers. (Many people, including me, got started when learning about this fact, as this is also a counter-productive limitation, but Iʼm not discussing an ISO standard here.)

Furthermore, the ISO keyboard standard 9995 always considered that all characters for natioal use must fit into Group 1, while Group 2 (and above) is to contain supplemental characters for all other supported languages. Like it or not, this principle is deeply embedded in ISO 9995. Now we may ask “Why the Œœ isnʼt therein?” Because Œœ had been excluded from ISO 8859-1 on the faith of French representatives (who didnʼt really represent France but only one manufacturer, as for the most voicy of the two), and regardless of the Canadian representative asking for its inclusion because Œœ is *necessary* in French.

Standards need to be read carefully prior to making statements on what is missing in a given implementation. And sometimes you even have to investigate. [To tell it in peopleʼs words following the above blog post: CSA didnʼt do like MS is supposed to have done...]

Thatʼs how Ian James altered the keyboardʼs ergonomics, given that many dead keys, all to the right, are now to be pressed along with Right Control! Itʼs as if he were too tired to add some code conferring the specified behavior to the Right Alt key. I dimly suggest that there could be a relation to what is discussed in another blog post; I would say that for being disliked, the standard has been implemented carelessly:
http://www.siao2.com/2008/10/23/9013000.aspx

Never let other people make an OS implementation of your standard!

Thatʼs why we need to access the C sources of Windows keyboard drivers.
And thatʼs why we need to get our drivers compiled from C sources (as opposed to KLC sources). In the scope of Unicode implementation, feeding KLC files into KbdUTool is not too bad as a method, as this allows for chained dead keys, and for ligatures under a five units length ceiling even when missing defines are added in kbd.h. But this way, locales support is suboptimal, because Windowsʼ potential is not fully available.

Best regards,

Marcel
Received on Wed Sep 02 2015 - 12:46:50 CDT