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