Re: Keyboard layouts and CLDR

[Philippe Verdy via Unicode]

The spell checker I was invoking was to allow fixing basic the typography
(e.g. the ae and oe ligatures contextually, it does not have to be a full
spell checker, but only concentrate on the typography, not the orthography,
most transforms should be limited to one or two characters, so that it is a
true "input mode", It could fix the leading capitals with accents : you
type the normal accent and it gets capitalized for you; the apostrophe does
not need a spell checker, the key produces directly the curly apostrophe
U+2019 and not the vertical apostrophe from ASCII in the
technical/programmer's mode)
But multiple layouts available in one click allows setting a context for
automatic transforms, or for typing more advanced character subsets.

The two codes in ISO639-2 are just suggested for a visual distinction (in
the language bar that displays "FRA" only for French, but does not display
the layout currently used) instead of appending some digit (a layout
number) to distinguish it. The language bar unfortunately does not clearly
display the layout in current use, but a combination of a language+layout
can have a visible code so that pressing a single key will make the change
visible: the layout selector can really be used as an input mode selector
which complements the existing mode keys (Shift, Ctrl, Alt, AltGr).

Even the touch keyboard in Windows has several layouts builtin (including
the Emoji selector, and some input modes where you can maintain a key
pressed to have a choice of "related" characters: the layout is really
different on screen, but I don't see why it cannot change also on the
physical keyboard, and made visible correctly also on the full layout of
the touch input panel, where key labels change dynamically according to the
state of mode keys). Additionally each application has its own input mode
builtin (own language and own layout), so the input mode in one app is not
necessarily the same as another app on the same screen, depending on which
one has the input focus.

Even within the same application, you could have several input areas using
different input modes, and depending on where you put the focus, the app
can automatically memoize its input mode when we leave a text input field
and restore it when we reenter it. The top bar of the touch panel is a
precious area where we can give more visual info...


2018-01-31 23:44 GMT+01:00 Marcel Schneider :

> On Wed, 31 Jan 2018 19:05:17 +0100, Philippe Verdy wrote:
> >
> > 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);
>
> Czech, Polish and Romanian have Programmer layouts shipped with Windows 7.
> But more than one single and easy keypress to switch between is
> inefficient.
> And a French Programmer layout as I see it cannot be called French, and the
> Programmer mode is needed as an ALtGr Lock on the upper row digits for
> convenience.
> Nothing of all these requirements is met by proposing two distinct layouts.
>
> > 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.
>
> I donʼt really see the point of spell-checking. Usually their libraries
> are so poor
> they donʼt even make the equivalence between U+2019 and U+0027. For me it
> suffices to see wavy underlines in the Google search bar. (And fortunately
> I
> donʼt do many searches a day with the Google search *bar.*)
>
> >
> > 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.
>
> The Language bar is a good feature, but it has little to do with what I
> try to achieve
> with the Programmer toggle. Itʼs part of the layout like CapsLock on
> bicameral layouts.
> Imagine that you had to toggle between a lowercase layout and an uppercase
> layout,
> and you understand why switching back and forth between two layouts is
> unpractical,
> though many users must actually rely on it. Surely that impacts
> productivity, and
> therefore, all non-Latin scripts are sort of digitally disadvantaged. What
> we need is a
> real layout toggle on our keyboards. As most scripts are unicase, the
> CapsLock key
> is the best candidate. (The more as many Latin script users hate
> CapsLock.) And
> those locales that require typing in uppercase usually have also the ISO
> B00 key,
> where CapsLock can be mapped. (Too bad that US-QWERTY is lacking key B00.)
>
> >
> > For French 

Re: Keyboard layouts and CLDR

[Marcel Schneider via Unicode]

On Wed, 31 Jan 2018 19:05:17 +0100, Philippe Verdy wrote:
> 
> 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);

Czech, Polish and Romanian have Programmer layouts shipped with Windows 7.
But more than one single and easy keypress to switch between is inefficient.
And a French Programmer layout as I see it cannot be called French, and the 
Programmer mode is needed as an ALtGr Lock on the upper row digits for 
convenience.
Nothing of all these requirements is met by proposing two distinct layouts.

> 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.

I donʼt really see the point of spell-checking. Usually their libraries are so 
poor 
they donʼt even make the equivalence between U+2019 and U+0027. For me it 
suffices to see wavy underlines in the Google search bar. (And fortunately I 
donʼt do many searches a day with the Google search *bar.*)

> 
> 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.

The Language bar is a good feature, but it has little to do with what I try to 
achieve 
with the Programmer toggle. Itʼs part of the layout like CapsLock on bicameral 
layouts. 
Imagine that you had to toggle between a lowercase layout and an uppercase 
layout, 
and you understand why switching back and forth between two layouts is 
unpractical,
though many users must actually rely on it. Surely that impacts productivity, 
and 
therefore, all non-Latin scripts are sort of digitally disadvantaged. What we 
need is a 
real layout toggle on our keyboards. As most scripts are unicase, the CapsLock 
key 
is the best candidate. (The more as many Latin script users hate CapsLock.) And 
those locales that require typing in uppercase usually have also the ISO B00 
key, 
where CapsLock can be mapped. (Too bad that US-QWERTY is lacking key B00.)

> 
> 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). 

Isnʼt the fre/fra alternative linguistic only, like gre/ell? 
Otherwise, every non-ASCII language writing system should have two codes.
And it isnʼt as if tech writers shouldnʼt use correct French orthography.

Regards,

Marcel

Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Philippe Verdy via Unicode]

>
> Note the French "touch" keyboard layout is complete for French (provided
> you select the one of the 3 new layouts with Emoji: it has the extra "key"
> for selecting the input language in all 4 layouts)
>
> But the "full" (dockable) touch layout in French which emulates a physical
> keyboard is still incomplete.
>
> This "full" layout is also incorrect because the top row has been
> unexpectedly shifted to the right, in order to place the  [Esc] key
> (reducing the [Backspace] at end of row: this row should have been left
> unchanged, placing the [Esc] key at end after the (reduced) Backspace key,
> or just to the right of the [X] icon that closes the touch keyboard panel
> (so that the [Backspace] keeps its size, or in order to place the [Del] key
> at end of this top row)
>
> The placement of [Fn] to the bottom left corner is UI design error (and a
> really bad decision taken by ISO): there should be only THREE keys to the
> left of the [Space bar] (whose size is correct), using larger keys (1.5 x
> 1.0 units) so that the left [Ctrl] remains in the bottom left corner. That
> [Fn] key should better be to the right of the [Space bar].
>
> The "Language" selector button should not be there in the layout  (and
> not in any one of the proposed layouts), it should be in the top bar,
> beside the "layout/option" selector icon in the top-left corner opening a
> popup menu.
>
> Removing the language selector key from the touch layout allows moving the
> arrow keys (in the full layout) to the right, restoring the correct
> position of the Right [Shift] key
>
>
>
The general appearance would then be as  on this image at:
>

https://drive.google.com/file/d/12t_w7fZZ2RKJho_FW9CbVwgIS8B8WmzX/view?usp=sharing

The [Fn] (virtual) key should also allow typing [PgUp], [PgDown], [Home],
> [End] and [Insert] on existing cursor keys, as seen on the right part of
> this image (I've cut most of the layout of the [Fn] key, where [Fn]+1 gives
> [F1] for example)...
>

You'll note the keys resized more conventionnaly, [Fn] placed at right
(after the too long Left Shift), the cedilla mapped in fact on [AltGr]+[,],
and the language selector and [Esc] key moved to the title bar, [Del] added
next to [Backspace]

The second [Ctrl] is still there on the bottom right (before the cursor
keys) but not really needed on the touch layout, and can safely be replaced
by the [App/Menu] key.

The top title bar should also be usable (in its current empty dark area) to
place customizable characters or keystrokes, but it could also be prefilled
with common characters used in the selected language... Also when that
touch layout is displayed, pressing any key physical keyboard could reduce
it to only this title bar which could remain on screen as an horizontal
strip, where the prefered keystrokes are still clickable directly, instead
of closing the panel completely (requiring then to click the small icon in
the task bar to reopen it with the full layout only): this can apply to ALL
touch layouts (not just the full layout).

If the touch layout is displayed, it can be docked at the bottom of screen,
or can be floatting, but when it is reduced to just its top title bar
(because we are typing a key on the physical keyboard), it can combine with
the reduced language bar (that you can place at top of the screen over the
title bar of other applications...)

Re: Keyboard layouts and CLDR

[Philippe Verdy via Unicode]

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 :

> 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 

Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Marcel Schneider via Unicode]

On Tue, 30 Jan 2018 23:30:59 +, David Starner via Unicode wrote:
> 
> On Tue, Jan 30, 2018 at 2:23 AM Alastair Houghton via Unicode  wrote:
>
> > This pattern exists across the board at the two companies; the Windows API 
> > hasn’t changed all that much
> > since Windows NT 4/95, whereas Apple has basically thrown away all the work 
> > it did up to Mac OS 9 and is
> > a lot more aggressive about deprecating and removing functionality even in 
> > Mac OS X/macOS than Microsoft
> > ever was.
>
> I'm not really clear on all the Windows details, as a long time Linux 
> programmer, but Mac OS X (2001) was
> 16 years ago and Windows 95 (1995) is 22, so not much difference even taking 
> your numbers. The .NET framework
> debuted in 2002, and the Universal Windows Platform debuted with Windows 8 in 
> 2012, so Microsoft has made some
> pretty large changes since NT 4. They do seem to more focused on keeping 
> backwards compatibility layers, but it's
> not that they've been not "prepared to make radical changes". 

I donʼt think that Alastairʼs point was about Microsoft not being innovative.
They simply allow old software to be used on new machines and Windows 
versions, something that Apple reportedly does not on macOS.

However, as of Unicode support by keyboard layouts, the current advice
is that adding new functionalities to Windows 10 would keep them out of 
reach for users of older versions of Windows, and new keyboard layouts 
relying on them would be truncated for a still huge part of the users. That is 
surely part of the “significant, perhaps insurmountable headwinds” faced by 
“making significant changes to user32.dll”, Andrew Glass warned in 2015:

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

Perhaps there could be a way to update older frameworks via Windows Update, 
making an end with “limitation[s] of the Windows USER keyboard architecture” 
that Michael Kaplan pointed in response to Karl Pentzlin, January 2010:

http://www.unicode.org/mail-arch/unicode-ml/y2010-m01/0030.html

Several discussions, in the past years, stated that we should be able to input 
combining sequences using dead keys, a feature supported by macOS and Linux 
natively, while Windows does not come along with that kind of support, although 
this is recommended by TUS: “It is straightforward to adapt such a system to 
emit 
combining character sequences or precomposed characters as needed.” (5.12, p. 
222)

http://www.unicode.org/versions/Unicode10.0.0/ch05.pdf#G1076

In a 2015 discussion we/I also learned that Tavultesoft Keyman, now SIL, 
provides 
all these features and is cross-platform, and had a free offer since long, now 
even 
including the Developer tooling thanks to backing by SIL. Iʼm advertising this 
software 
to advocate Microsoftʼs presumed position: For all that goes beyond legacy 
support, 
we can rely on Keyman. 

As a consequence, layouts that are to be shipped with Windows, such as the new 
French, must stick with Windows resources (input editors are excluded by spec), 
whereas minority languages needing extended functionalities can promote 
additional 
software for support, as far as they are not expected to be supported 
out-of-the-box.

Hopefully we can now expect, by contrast, that Apple will add the missing 
toggle, 
internally VK_KANA on Windows (Linux is reported to have it, too), to make it 
available on macOS as well.

Regards,

Marcel

Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[David Starner via Unicode]

On Tue, Jan 30, 2018 at 2:23 AM Alastair Houghton via Unicode <
unicode@unicode.org> wrote:

> This pattern exists across the board at the two companies; the Windows API
> hasn’t changed all that much since Windows NT 4/95, whereas Apple has
> basically thrown away all the work it did up to Mac OS 9 and is a lot more
> aggressive about deprecating and removing functionality even in Mac OS
> X/macOS than Microsoft ever was.
>

I'm not really clear on all the Windows details, as a long time Linux
programmer, but Mac OS X (2001) was 16 years ago and Windows 95 (1995) is
22, so not much difference even taking your numbers. The .NET framework
debuted in 2002, and the Universal Windows Platform debuted with Windows 8
in 2012, so Microsoft has made some pretty large changes since NT 4. They
do seem to more focused on keeping backwards compatibility layers, but it's
not that they've been not "prepared to make radical changes".

Re: Keyboard layouts and CLDR

[Marcel Schneider via Unicode]

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 

RE: Keyboard layouts and CLDR

[Marcel Schneider via Unicode]

On Tue, 30 Jan 2018 11:50:49 -0700, Doug Ewell wrote:
> 
> Marcel Schneider wrote: 
> >
> > http://recycledknowledge.blogspot.com/2013/09/us-moby-latin-keyboard-for-windows.html
> >  
> >
> > Sadly the downloads are still unavailable (as formerly discussed). But 
> > I saved in time, too (June 2015). 
>
> Sorry, try this: 
>
> http://vrici.lojban.org/~cowan/MobyLatinKeyboard.zip

Thank you!

Iʼve gone through John Cowanʼs Home Page, too:

http://vrici.lojban.org/~cowan/

Regards,

Marcel

Re: Keyboard layouts and CLDR

[Marcel Schneider via Unicode]

On Tue, 30 Jan 2018 11:34:40 -0700, Doug Ewell via Unicode wrote:
> 
> Marcel Schneider wrote:
> 
> > That tends to prove that Mac users accept changes, while Windows users
> > refuse changes.
> 
> I was going to say that was a gross over-generalization, but that didn't
> adequately express how gross it was. It's just plain wrong. Pardon my
> bluntness.
> 
> How about: Windows is often used in the workplace, where users may not
> have the freedom or motivation to make their own changes and be
> different from other users, while Macs are often used by individuals who
> do. That's an over-generalization too, but not quite at the level of
> "Windows users refuse changes."

Iʼm relieved to be wrong, and that “such a discrepancy” that “I fail[ed] to 
understand” doesnʼt exist.

I know a company that prescribes and delivers Apple hardware to all its 
affiliates. Second-hand retailers offer very few Apple machines while they 
have plenty of PC computers, whose turnover at business customers is
two years. Apple computers are not replaced every two years in workplaces. 
That may be a reason why Apple Inc. takes steps to get them replaced 
nevertheless, as Alastairʼs report you quoted [and I already answered] 
might suggest (but stop, no more over-interpretation!).

>
> Alastair Houghton replied:
> 
> > I think, rather, that Apple is (or has been) prepared to make radical
> > changes, even at the expense of backwards compatibility and even where
> > it knows there will be short term pain from users complaining about
> > them, where Microsoft is more conservative.
> 
> That too. Good point. 

Very good point.

Regards,

Marcel

Re: Keyboard layouts and CLDR

[Marcel Schneider via Unicode]

On Tue, 30 Jan 2018 10:20:46 +, Alastair Houghton wrote:
> 
> On 30 Jan 2018, at 05:31, Marcel Schneider via Unicode  wrote:
> > 
> > OnMon, 29 Jan 2018 11:13:21 -0700, Tom Gewecke wrote:
> >> 
[…]
> >> 
> >> They are also all on the MacOS "US International PC", provided since 2009 
> >> by Apple
> >> for Windows users who like US International.
> > 
> > I suppose that this layout ships with the Windows emulation that can be run 
> > on a Mac.
> 
> No. It’s included as standard with the macOS itself. Go to System 
> Preferences, choose “Keyboard”, then “Input Sources”.
> Click the “+” button at the bottom left, then enter “PC” in the search field 
> and you’ll see there are a range of “PC” layouts.

Indeed. Itʼs sort of a mix made of Appleʼs common US and Windowsʼ 
US-International. 
So it has the five Windows-style dead keys in Base and Shift, AND the five 
Mac-style 
dead keys (for the same diacritics) in Option.

> 
> >> œ Œ are on alt and alt-shift q
> >> 
> >> ‹› are on alt-shift 3/4
> 
> More of a nitpick than anything, but Apple keyboards have *Option*, not 
> “alt”. Yes, some (but not all) keyboards’ Option keys have an “alt” 
> annotation at the top, but that was added AFAIK for the benefit of people 
> running PC emulation (or these days, Windows under e.g. VMWare 
> Fusion). The “alt” annotation isn’t on the latest keyboards (go look in an 
> Apple Store if you don’t believe me :-)).

Then, “alt” is obsoleted on Mac, and calling them “Option” is correct? Iʼm 
relieved if so, as I 
used “Option” when referring to macOS, or better, “AltGr/Option” to be 
cross-platform…
“Option” is shorter, but “AltGr” is already printed on most keyboards, though 
it isnʼt a short 
form of an easily localizable term, while “Option” is multi-locale (English, 
French, German, …).

> 
> > Then this is ported from the Apple US layout, where these characters are in 
> > the same 
> > places. However that does not include correct spacing, as required for 
> > French.
> 
> Not sure what you mean about spacing. That, surely, is a matter mainly for 
> the software you’re using, rather than for a keyboard layout?

It may be handled by an input editing functionality as embedded in Word, like 
many things 
can be done by input editing, even “œ” (for which Word has also a shortcut: 
Ctrl+&, o) 
because Microsoft and Bill Gates in person were eager to support the French 
locale and 
did a lot to help French efforts in keyboarding. But properly, correct spacing 
must be 
handled on keyboard level, otherwise weʼll always end up with a mass of wrong 
data 
amidst which a subset of correct documents having U+202F NARROW NO-BREAK SPACE 
before ‘?’ and ‘!’ and ‘;’, and even ‘»’ and after ‘«’, and currently also 
before ‘:’ as 
Philippe Verdy wrote to this List on Fri, 26 Jun 2015 22:16:48 +0200:

http://www.unicode.org/mail-arch/unicode-ml/y2015-m06/0220.html

“Les éditeurs de presse et de livres en France utilisent tous des fines de
chasse fixe dans leurs moteurs de composition”
(“Print media and book publishers in France all use fixed-width narrows in 
their typesetting engines”)

Unicode did not support interoperable French typesetting until it encoded 
U+202F for Mongolian, in 1999, six years after v1.1 of the Standard. 
Making U+2008 PUNCTUATION SPACE a no-break space would have been
well done. This was seemingly encoded for hot-metal typesetting of tables, 
like U+2012 FIGURE DASH and U+2007 FIGURE SPACE that is non-breakable.
While U+2007 can be considered a fixed-width counterpart of U+00A0, and
U+2012 could have been a longer variant of U+2212 to denote intervals 
*if only* it had been specified as such, U+2008 could have been the proper 
representation of French punctuation spacing, instead of ending up as a 
completely useless character, depriving the French locale of Unicode support.
See the feedback items about these topics that have been posted so far:

http://www.unicode.org/L2/L2018/18009-pubrev.html#Error_Reports

> 
> >> (US Extended has also been renamed ABC Extended back in 2015)
> > 
> > Presumably because it is interesting for many locales worldwide accustomed 
> > to the 
> > US QWERTY layout. That tends to prove that Mac users accept changes, while 
> > Windows users refuse changes. However I fail to understand such a 
> > discrepancy.
> 
> I don’t think it’s the users.
> 
> I think, rather, that Apple is (or has been) prepared to make radical 
> changes, even at the expense of backwards compatibility and even where it 
> knows there will be short term pain from users complaining about them, where 
> Microsoft is more conservative. This pattern exists across the 
> board at the two companies; the Windows API hasn’t changed all that much 
> since Windows NT 4/95, whereas Apple has basically thrown away 
> all the work it did up to Mac OS 9 and is a lot more aggressive about 
> deprecating and removing functionality even in Mac OS X/macOS than 
> Microsoft ever was.
> 
> This is exemplified, actually, by the 

RE: Keyboard layouts and CLDR

[Doug Ewell via Unicode]

Marcel Schneider wrote:

>> http://recycledknowledge.blogspot.com/2013/09/us-moby-latin-keyboard-for-windows.html
>
> Sadly the downloads are still unavailable (as formerly discussed). But
> I saved in time, too (June 2015).

Sorry, try this:

http://vrici.lojban.org/~cowan/MobyLatinKeyboard.zip
 
--
Doug Ewell | Thornton, CO, US | ewellic.org

Re: Keyboard layouts and CLDR

[Doug Ewell via Unicode]

Marcel Schneider wrote:

> That tends to prove that Mac users accept changes, while Windows users
> refuse changes.

I was going to say that was a gross over-generalization, but that didn't
adequately express how gross it was. It's just plain wrong. Pardon my
bluntness.

How about: Windows is often used in the workplace, where users may not
have the freedom or motivation to make their own changes and be
different from other users, while Macs are often used by individuals who
do. That's an over-generalization too, but not quite at the level of
"Windows users refuse changes."

Alastair Houghton replied:

> I think, rather, that Apple is (or has been) prepared to make radical
> changes, even at the expense of backwards compatibility and even where
> it knows there will be short term pain from users complaining about
> them, where Microsoft is more conservative.

That too. Good point.

--
Doug Ewell | Thornton, CO, US | ewellic.org

Re: Keyboard layouts and CLDR

[Marcel Schneider via Unicode]

On Tue, 30 Jan 2018 08:54:19 -0700, Tom Gewecke wrote:
> 
> > On Jan 30, 2018, at 3:20 AM, Alastair Houghton  wrote:
> > 
> > The “alt” annotation isn’t on the latest keyboards (go look in an Apple 
> > Store if you don’t believe me :-)).
> 
> Interesting! Apple’s documentation shows these keys mostly with “alt” and “⌥”.
> 
> https://support.apple.com/en-us/HT201794

While the “⌥” symbol is persistent across locales, the “alt” label is somewhere 
replaced with “option” and I believed that this the macOS name, whereas “alt” 
is merely wrt BootCamp users. However that is confusing as Windows “Alt” has 
not the “option” functionality but rather the quick access like its internal 
name of 
“MENU” (‷LMENU‴, ‷RMENU‴), while “option” equals “AltGr” since there are 
alternate graphics, too. But now since we need a “Numbers” modifier, none of 
both schemes seems appropriate: Left Option should be Numbers, and Alt should 
become Numbers, too, while itself could be mapped to Left Windows or so. See:

https://unicode.org/cldr/trac/ticket/10851#comment:2

Regards,

Marcel

Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Tom Gewecke via Unicode]

> On Jan 30, 2018, at 3:20 AM, Alastair Houghton  
> wrote:
> 
>   The “alt” annotation isn’t on the latest keyboards (go look in an Apple 
> Store if you don’t believe me :-)).

Interesting!  Apple’s documentation shows these keys mostly with “alt” and “⌥”.

https://support.apple.com/en-us/HT201794

Re: Keyboard layouts and CLDR

[Eric Muller via Unicode]

Indeed.

But "Faÿ-lès-Nemours" / "FAŸ-LÈS-NEMOURS". "lès" in French place names 
means "near", typically followed by another city name or a river name.


In the case of "L'Haÿ-les-Roses", it's just that they have a famous rose 
garden, so "les".


Eric.

On 1/30/2018 12:06 AM, Martin J. Dürst via Unicode wrote:

On 2018/01/30 16:18, Philippe Verdy via Unicode wrote:

  - 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.


Wikipedia has this as L'Haÿ-les-Roses (see 
https://fr.wikipedia.org/wiki/L'Haÿ-les-Roses). It surely would be 
L'HAŸ-LES-ROSES, and not L'HAŸE-LÈS-ROSES, when capitalized. I of 
course know of the phenomenon that in French, sometimes the accents on 
upper-case letters are left out, but I haven't heard of a reverse 
phenomenon yet.


Regards,   Martin.

Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Alastair Houghton via Unicode]

On 30 Jan 2018, at 05:31, Marcel Schneider via Unicode  
wrote:
> 
> OnMon, 29 Jan 2018 11:13:21 -0700, Tom Gewecke wrote:
>> 
>>> On Jan 29, 2018, at 4:26 AM, Marcel Schneider via Unicode  wrote:
>>> 
>>> 
>>> the Windows US-Intl 
>>> does not allow to write French in a usable manner, as the Œœ is still 
>>> missing, and does not allow to type German correctly neither due to 
>>> the lack of single angle quotation marks (used in some French locales, 
>>> too, and perhaps likely to become even more widespread). Of course 
>>> these are all on the macOS US-Extended.
>> 
>> They are also all on the MacOS "US International PC", provided since 2009 by 
>> Apple
>> for Windows users who like US International.
> 
> I suppose that this layout ships with the Windows emulation that can be run 
> on a Mac.

No.  It’s included as standard with the macOS itself.  Go to System 
Preferences, choose “Keyboard”, then “Input Sources”.  Click the “+” button at 
the bottom left, then enter “PC” in the search field and you’ll see there are a 
range of “PC” layouts.

>> œ Œ are on alt and alt-shift q
>> 
>> ‹› are on alt-shift 3/4

More of a nitpick than anything, but Apple keyboards have *Option*, not “alt”.  
Yes, some (but not all) keyboards’ Option keys have an “alt” annotation at the 
top, but that was added AFAIK for the benefit of people running PC emulation 
(or these days, Windows under e.g. VMWare Fusion).  The “alt” annotation isn’t 
on the latest keyboards (go look in an Apple Store if you don’t believe me :-)).

> Then this is ported from the Apple US layout, where these characters are in 
> the same 
> places. However that does not include correct spacing, as required for French.

Not sure what you mean about spacing.  That, surely, is a matter mainly for the 
software you’re using, rather than for a keyboard layout?

>> (US Extended has also been renamed ABC Extended back in 2015)
> 
> Presumably because it is interesting for many locales worldwide accustomed to 
> the 
> US QWERTY layout. That tends to prove that Mac users accept changes, while 
> Windows users refuse changes. However I fail to understand such a discrepancy.

I don’t think it’s the users.

I think, rather, that Apple is (or has been) prepared to make radical changes, 
even at the expense of backwards compatibility and even where it knows there 
will be short term pain from users complaining about them, where Microsoft is 
more conservative.  This pattern exists across the board at the two companies; 
the Windows API hasn’t changed all that much since Windows NT 4/95, whereas 
Apple has basically thrown away all the work it did up to Mac OS 9 and is a lot 
more aggressive about deprecating and removing functionality even in Mac OS 
X/macOS than Microsoft ever was.

This is exemplified, actually, by the length of time Microsoft keeps backwards 
compatibility layers, versus the length of time Apple does so.  The WoW 
subsystem is (I think) still part of the 32-bit builds of Windows, so they can 
still run Windows 3.1 software, DOS software and so on (i.e. software back to 
the 1980s).  Apple, on the other hand, dropped support for “Classic” Mac apps 
back in 10.4 and has never supported running PowerPC classic apps on any Intel 
machine.  Indeed, six years ago now, in Mac OS X 10.7, Apple dropped support 
for running PowerPC apps built for Mac OS X, which basically means that 
software Mac users bought to run on their older PowerPC-based Macs is now not 
usable on new machines.

Kind regards,

Alastair.

--
http://alastairs-place.net

Re: Keyboard layouts and CLDR

[Martin J. Dürst via Unicode]

On 2018/01/30 16:18, Philippe Verdy via Unicode wrote:


  - 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.


Wikipedia has this as L'Haÿ-les-Roses (see 
https://fr.wikipedia.org/wiki/L'Haÿ-les-Roses). It surely would be 
L'HAŸ-LES-ROSES, and not L'HAŸE-LÈS-ROSES, when capitalized. I of course 
know of the phenomenon that in French, sometimes the accents on 
upper-case letters are left out, but I haven't heard of a reverse 
phenomenon yet.


Regards,   Martin.

Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Philippe Verdy via Unicode]

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:

 - [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; spell checkers forget the
frequent words: Ça or Ç'.

 - [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.

 - [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".

 - [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.

 - 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.

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, " ÃÕ" 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.



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.


2018-01-30 6:31 GMT+01:00 Marcel Schneider via Unicode 
:

> OnMon, 29 Jan 2018 11:13:21 -0700, Tom Gewecke wrote:
> >
> > > On Jan 29, 2018, at 4:26 AM, Marcel Schneider via Unicode  wrote:
> > >
> > >
> > > the Windows US-Intl
> > > does not allow to write French in a usable manner, as the Œœ is still
> > > missing, and does not allow to type German correctly neither due to
> > > the lack of single angle quotation marks (used in some French locales,
> > > too, and perhaps likely to become even more widespread). Of course
> > > these are all on the macOS US-Extended.
> >
> > They are also all on the MacOS "US International PC", provided since
> 2009 by Apple
> > for Windows users who like US International.
>
> I suppose that this layout ships with the Windows emulation that can be
> run on a Mac.
> Itʼs hard to find through especially when I canʼt see the layout or find
> on the internet.
> Thanks anyway. They seem to be always first, and then, other wendors canʼt
> copy nor
> invent something else people 

Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Marcel Schneider via Unicode]

OnMon, 29 Jan 2018 11:13:21 -0700, Tom Gewecke wrote:
> 
> > On Jan 29, 2018, at 4:26 AM, Marcel Schneider via Unicode  wrote:
> > 
> > 
> > the Windows US-Intl 
> > does not allow to write French in a usable manner, as the Œœ is still 
> > missing, and does not allow to type German correctly neither due to 
> > the lack of single angle quotation marks (used in some French locales, 
> > too, and perhaps likely to become even more widespread). Of course 
> > these are all on the macOS US-Extended.
> 
> They are also all on the MacOS "US International PC", provided since 2009 by 
> Apple
> for Windows users who like US International.

I suppose that this layout ships with the Windows emulation that can be run on 
a Mac.
Itʼs hard to find through especially when I canʼt see the layout or find on the 
internet. 
Thanks anyway. They seem to be always first, and then, other wendors canʼt copy 
nor 
invent something else people wonʼt like.

> 
> œ Œ are on alt and alt-shift q
> 
> ‹› are on alt-shift 3/4

Then this is ported from the Apple US layout, where these characters are in the 
same 
places. However that does not include correct spacing, as required for French.

> 
> (US Extended has also been renamed ABC Extended back in 2015)

Presumably because it is interesting for many locales worldwide accustomed to 
the 
US QWERTY layout. That tends to prove that Mac users accept changes, while 
Windows users refuse changes. However I fail to understand such a discrepancy.

Regards,

Marcel

RE: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Marcel Schneider via Unicode]

On Mon, 29 Jan 2018 16:07:11 -0700, Doug Ewell wrote:
> 
> Marcel Schneider wrote:
> 
> > Prior to this thread, I believed that the ratio of Windows users
> > liking the US-International vs Mac users liking the US-Extended was
> > like other “Windows implementation” vs “Apple implementation” ratios.
> 
> For many users, it may not be a question of what they like, but rather
> (a) what they are aware of, (b) what comes standard with their Windows
> installation, and (c) in the workplace, what their IT overlords have
> granted them permission to use.

c: Hierarchical relationships may be complicated in some places but generally 
there should be an open door, and suggestion boxes or pinwalls may also be 
available. As an “overuser” the IT manager must think and evaluate in the place 
of his employees/coworkers, but professional stress and the desire to unplug 
during week-ends could be mainly responsible of his unawareness. Though I 
thought that for professionalismʼs sake they should deploy an appropriate 
layout fork, and I canʼt see any point in not using MSKLC at that level.

b: There is often much reluctance to add only an extra font, and I hesitated a 
long time prior to installing Firefox or any other extraneous (third-party) 
software, but that is actually so common — Chrome browser doesnʼt ship with 
Windows neither but weʼre often encouraged to download it — that failing to 
update oneʼs keyboard is due to a lack of marketing and thus, resolves to point 
(a).

> 
> I use a modified version of John Cowan's "Moby Latin" layout on all my
> machines:

It would be interesting to know more about your modifications.

> 
> http://recycledknowledge.blogspot.com/2013/09/us-moby-latin-keyboard-for-windows.html

Sadly the downloads are still unavailable (as formerly discussed). But I saved 
in time, too (June 2015).

> 
> which allows me to type about 900 characters *in addition* to Basic
> Latin, with 100% backward compatibility with U.S. English (i.e. none of
> the apostrophe and quotation-mark shenanigans we are talking about). But
> (a) I happen to know about Moby Latin, (b) it doesn't ship with Windows,
[Addition on Mon, 29 Jan 2018 19:08:55 -0700:
> Of course that is not a "luxury." Knowing that third-party options are
> available, let alone free and easily installed ones, is the luxury. 
]
> and (c) I am able to install it (and even modify it). Many users do not
> have all or even any of these luxuries.

I agree. It is a blessing to be able to fine-tune oneʼs keyboard. Often those 
knowing about correct diacritics but not about keyboarding canʼt help clicking 
in charmaps and symbol dialogs at document length. That is utter time waste.
And thatʼs what is wrong about letting people waste their time while knowing 
better.

> 
> There is perhaps another factor: many Americans, who are probably the
> majority users of US-International though not the only ones, simply do
> not know or care about accents and other "foreign stuff." Even those who
> know a language other than English often write it in ASCII, and see it
> that way in marketing and other professionally created material. For
> example, menus in Mexican restaurants often list "albondigas" and
> "jalapenos."

French too, though being an accented language/script, is prone to omitting 
other localeʼs diacritics as far as they are supposed not to be on the AZERTY.
(It happened that a tilde was refused for lack of support, while we do have 
that dead key!) The more when accents merely indicate correct intonation, 
as in “albóndigas.” When reading “jalapenos” we reflexively add the tilde for 
spelling. Compare with locales writing consonants only. Writing in ASCII is 
also a sort of assimilation, as we all like to name things in our own language.

> 
> The non-phonetic spelling of English may further encourage English-only
> speakers to ignore the squiggles and dots that are necessary to indicate
> correct pronunciation of other languages.

That can be OK for common words, but gets dangerous when it comes to 
proper names. Thereʼs a slippery path from easy to sloppy. Itʼs still about 
i18n.
But I wasnʼt aware that by not using diacritics and having to do much effort 
to remember correct spelling, English-speaking people may really hate those 
diacritics even when occurring on foreign stuff.

> 
> Given that, interest among potential users of US-International to find a
> better solution is probably very low.

I was about to make a quick update of the US-Intl [or ABC-Intl], but 
if so, I could eventually save that for now.

> 
> > If so many people like it, why was Windows Intl not updated, then?
> 
> 1. I'd be surprised if there were "so many people," or much demand to
> update it. Microsoft might have a few other items on their backlogs.

However, resulting from the KLC files you kindly provided me, as of Latin 
keyboard layouts shipped with Windows, from Windows 7 to Windows 8, 
eight layouts were updated, including United Kingdom, Turkish, German 
and 

RE: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Doug Ewell via Unicode]

(b) it doesn't ship with Windows


Of course that is not a "luxury." Knowing that third-party options are 
available, let alone free and easily installed ones, is the luxury.


--
Doug Ewell | Thornton, CO, US | ewellic.org

RE: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Doug Ewell via Unicode]

Marcel Schneider wrote:

> Prior to this thread, I believed that the ratio of Windows users
> liking the US-International vs Mac users liking the US-Extended was
> like other “Windows implementation” vs “Apple implementation” ratios.

For many users, it may not be a question of what they like, but rather
(a) what they are aware of, (b) what comes standard with their Windows
installation, and (c) in the workplace, what their IT overlords have
granted them permission to use.

I use a modified version of John Cowan's "Moby Latin" layout on all my
machines:

http://recycledknowledge.blogspot.com/2013/09/us-moby-latin-keyboard-for-windows.html

which allows me to type about 900 characters *in addition* to Basic
Latin, with 100% backward compatibility with U.S. English (i.e. none of
the apostrophe and quotation-mark shenanigans we are talking about). But
(a) I happen to know about Moby Latin, (b) it doesn't ship with Windows,
and (c) I am able to install it (and even modify it). Many users do not
have all or even any of these luxuries.

There is perhaps another factor: many Americans, who are probably the
majority users of US-International though not the only ones, simply do
not know or care about accents and other "foreign stuff." Even those who
know a language other than English often write it in ASCII, and see it
that way in marketing and other professionally created material. For
example, menus in Mexican restaurants often list "albondigas" and
"jalapenos."

The non-phonetic spelling of English may further encourage English-only
speakers to ignore the squiggles and dots that are necessary to indicate
correct pronunciation of other languages.

Given that, interest among potential users of US-International to find a
better solution is probably very low.

> If so many people like it, why was Windows Intl not updated, then?

1. I'd be surprised if there were "so many people," or much demand to
update it. Microsoft might have a few other items on their backlogs.

2. I don't speak for Microsoft, but there is often fear of making
changes to existing standards, even changes that fill in holes in the
standard. Users who type a formerly invalid sequence and get a valid
character, instead of the beep or question mark they once got, and
complain about the change, might seem to be a low-priority constituency,
but you'd be surprised.

> To like a particular layout does not mean to want to stick with it
> when anything better comes up. Userʼs choice is always respected.

See above regarding what users might like if only they had a choice.
 
--
Doug Ewell | Thornton, CO, US | ewellic.org

Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Tom Gewecke via Unicode]

> On Jan 29, 2018, at 4:26 AM, Marcel Schneider via Unicode 
>  wrote:
> 
> 
>  the Windows US-Intl 
> does not allow to write French in a usable manner, as the Œœ is still 
> missing, and does not allow to type German correctly neither due to 
> the lack of single angle quotation marks (used in some French locales, 
> too, and perhaps likely to become even more widespread). Of course 
> these are all on the macOS US-Extended.

They are also all on the MacOS "US International PC", provided since 2009 by 
Apple for Windows users who like US International.

œ Œ are on alt and alt-shift q

‹› are on alt-shift 3/4

(US Extended has also been renamed ABC Extended back in 2015)

Re: Keyboard layouts and CLDR

[Marcel Schneider via Unicode]

BTW the 5 dead keys of Windows US Intl are already on 
Appleʼs *normal* US layout, along with the letter o-with-e. 
US Extended adds 20 more deadkeys.

On Sun, 28 Jan 2018 16:20:16 -0700, Doug Ewell wrote: 
[…]
> Nothing in the PRI #367 blog post or background document communicated to
> me that CLDR was going to try to influence vendors to retire these
> keyboard layouts and replace them with those. […]

The “replacement” would be on user side, not on vendors side. I was never 
thinking that Microsoft could put another layout *in the place of US Intl* 
instead of letting users choose. 

To like a particular layout does not mean to want to stick with it 
when anything better comes up. Userʼs choice is always respected.
But users must also respect other peopleʼs orthographies, as seen 
in the wake of the preceding Kazakh apostrophes thread. Hence we 
are expected to upgrade our tooling if it proves inappropriate.

(Nevertheless the time Iʼm using an Apple instead of my 
Windows-7-driven netbook is less than 0.1 %.)

Regards,

Marcel

Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Marcel Schneider via Unicode]

On Sun, 28 Jan 2018 21:56:25 -0800, Mark Davis replied to Doug Ewell:
> 
> It is not a goal to get "vendors to retire these keyboard layouts and
> replace them" — that's not our role. (And I'm sure that a lot of people
> like and would continue to use the Windows Intl keyboard.)

Instead of “replace” I should have written /provide an alternative to/.
Discontinuing a major layout variant would be bad practice.

Prior to this thread, I believed that the ratio of Windows users 
liking the US-International vs Mac users liking the US-Extended was 
like other “Windows implementation” vs “Apple implementation” ratios.

So far we can tell that failing to be updated, the Windows US-Intl 
does not allow to write French in a usable manner, as the Œœ is still 
missing, and does not allow to type German correctly neither due to 
the lack of single angle quotation marks (used in some French locales, 
too, and perhaps likely to become even more widespread). Of course 
these are all on the macOS US-Extended.

If so many people like it, why was Windows Intl not updated, then?
(Or has it been for Windows 10, and just not on 
https://docs.microsoft.com/fr-fr/globalization/keyboards/kbdusx.html
while the Keyboard layouts index page has come into the benefit of 
a slight enhancement of user experience:
https://docs.microsoft.com/en-us/globalization/windows-keyboard-layouts
)

> 
> It's more about making it easier to have more choice available for users:
> more languages, and more choice of layouts within a language that meet
> people's needs. 

Covering more — and ideally ALL — languages is top priority.
Marc Durdin of SIL Keyman teaming up with the CLDR enhancement 
project is very good news.

Regards,

Marcel (If you wonder why Mark Davis blacklisted me: That happened 
at the 2015 “Apostrophe” thread when I was new to this and any other 
Mailing List.)

Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Mark Davis ☕️ via Unicode]

On Sun, Jan 28, 2018 at 3:20 PM, Doug Ewell  wrote:

> Mark Davis wrote:
>
> One addition: with the expansion of keyboards in
>> http://blog.unicode.org/2018/01/unicode-ldml-keyboard-enhancements.html
>> we are looking to expand the repository to not merely represent those,
>> but to also serve as a resource that vendors can draw on.
>>
>
> Would you say, then, that Marcel's statements:
>
> "Now that CLDR is sorting out how to improve keyboard layouts, hopefully
> something falls off to replace the *legacy* US-Intl."
>

> and:
>
> "We can only hope that now, CLDR is thoroughly re-engineering the way
> international or otherwise extended keyboards are mapped."
>
> reflect the situation accurately?
>
> Nothing in the PRI #367 blog post or background document communicated to
> me that CLDR was going to try to influence vendors to retire these keyboard
> layouts and replace them with those. I thought it was just about providing
> a richer CLDR format and syntax to better "support keyboard layouts from
> all major providers." Please point me to the part I missed.


Your message didn't quote
​the part about «replace the *legacy* US-Intl."»

The PRI blog post is talking about the technical changes, not process. The
goal there is to be able to represent keyboard structures and data in a
"lingua franca", and to expand the features needed to cover more languages
and more vendor requirements. Of course, more extensions will be needed in
the future, as well.

As far as process goes, we foresee (a) continuing to reflect what is being
used in practice, and (b) extending to a repository for keyboards for
languages that are not represented by current vendors. That is to enable
vendors to easily add keyboards for support of additional languages, if
they want.

It is not a goal to get "vendors to retire these keyboard layouts and
replace them" — that's not our role. (And I'm sure that a lot of people
like and would continue to use the Windows Intl keyboard.)

It's more about making it easier to have more choice available for users:
more languages, and more choice of layouts within a language that meet
people's needs.


>
>
> --
> Doug Ewell | Thornton, CO, US | ewellic.org
>
>

Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Marcel Schneider via Unicode]

On Sun, 28 Jan 2018 14:11:06 -0700, Doug Ewell wrote:
>
> Marcel Schneider wrote:
> 
> > We can only hope that now, CLDR is thoroughly re-engineering the way
> > international or otherwise extended keyboards are mapped.
> 
> I suspect you already know this and just misspoke, but CLDR doesn't 
> prescribe any vendor's keyboard layouts. CLDR mappings reflect what 
> vendors have released.

Sorry I didnʼt see the thread until I replied at the point where it is.
But looking harder I can see that what I meant when trying to input my 
concern into the project, is already implied by the wording of the initial 
blog post (Mark has shared the link of:
http://blog.unicode.org/2018/01/unicode-ldml-keyboard-enhancements.html
) when it comes to a detailed overview of the goals:

“As a part of this work, keyboards […] provide better layouts overall.”

E.g. a Numbers modifier is required for locales using U+202F NARROW 
NO-BREAK SPACE as a thousands separator (and is useful for all others), 
while a Programmer toggle is required on keyboards using the upper row 
for special letters lower-and uppercase, and is handy for all those that have 
dead keys in the righthand part. Windows Vietnamese is one example, and 
Michael Kaplan wrote a series of blog posts about it, that you know well:

http://archives.miloush.net/michkap/archive/2005/08/27/457224.html
http://archives.miloush.net/michkap/archive/2005/11/11/491349.html
http://archives.miloush.net/michkap/archive/2007/01/31/1564299.html

I was aware that CLDR is a repository, and now Iʼm amazed how things 
go on.

Regards,

Marcel

Re: Keyboard layouts and CLDR

[Marcel Schneider via Unicode]

On Sun, 28 Jan 2018 16:20:16 -0700, Doug Ewell wrote:
> 
> Mark Davis wrote:
> 
> > One addition: with the expansion of keyboards in
> > http://blog.unicode.org/2018/01/unicode-ldml-keyboard-enhancements.html
> > we are looking to expand the repository to not merely represent those,
> > but to also serve as a resource that vendors can draw on.
> 
> Would you say, then, that Marcel's statements:
> 
> "Now that CLDR is sorting out how to improve keyboard layouts, hopefully 
> something falls off to replace the *legacy* US-Intl."
> 
> and:
> 
> "We can only hope that now, CLDR is thoroughly re-engineering the way 
> international or otherwise extended keyboards are mapped."
> 
> reflect the situation accurately?
> 
> Nothing in the PRI #367 blog post or background document communicated to 
> me that CLDR was going to try to influence vendors to retire these 
> keyboard layouts and replace them with those. I thought it was just 
> about providing a richer CLDR format and syntax to better "support 
> keyboard layouts from all major providers." Please point me to the part 
> I missed.

A replacement candidate for US-International would only be a handy fall-off, 
and it is up to MIcrosoft to decide whether it has the potential to enhance UX.

It all started up when Mark accepted to embrace the idea of adding a Numbers 
modifier and a Programmer toggle after submission of CLDR ticket #10851:

unicode.org/cldr/trac/ticket/10851

I figure out that the working group is on a proof of concept.
Iʼm trying to make up some additions by the deadline of PRI #367.

Regards,

Marcel

Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Doug Ewell via Unicode]

Mark Davis wrote:


One addition: with the expansion of keyboards in
http://blog.unicode.org/2018/01/unicode-ldml-keyboard-enhancements.html
we are looking to expand the repository to not merely represent those,
but to also serve as a resource that vendors can draw on.


Would you say, then, that Marcel's statements:

"Now that CLDR is sorting out how to improve keyboard layouts, hopefully 
something falls off to replace the *legacy* US-Intl."


and:

"We can only hope that now, CLDR is thoroughly re-engineering the way 
international or otherwise extended keyboards are mapped."


reflect the situation accurately?

Nothing in the PRI #367 blog post or background document communicated to 
me that CLDR was going to try to influence vendors to retire these 
keyboard layouts and replace them with those. I thought it was just 
about providing a richer CLDR format and syntax to better "support 
keyboard layouts from all major providers." Please point me to the part 
I missed.


--
Doug Ewell | Thornton, CO, US | ewellic.org

Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Mark Davis ☕️ via Unicode]

One addition: with the expansion of keyboards in
http://blog.unicode.org/2018/01/unicode-ldml-keyboard-enhancements.html we
are looking to expand the repository to not merely represent those, but to
also serve as a resource that vendors can draw on.

Mark

On Sun, Jan 28, 2018 at 1:11 PM, Doug Ewell via Unicode  wrote:

> Marcel Schneider wrote:
>
> We can only hope that now, CLDR is thoroughly re-engineering the way
>> international or otherwise extended keyboards are mapped.
>>
>
> I suspect you already know this and just misspoke, but CLDR doesn't
> prescribe any vendor's keyboard layouts. CLDR mappings reflect what vendors
> have released.
>
> --
> Doug Ewell | Thornton, CO, US | ewellic.org
>
>