Keyboard layouts and CLDR

Wed Jan 31 17:30:45 CST 2018

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 <charupdate at orange.fr>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20180201/5d847556/attachment.html>