> Sorry, I meant shift levels. my proposed us-ascii would have just
>
> key <AE01> { [ 1, exclam ] };
>
> not
>
> key <AE01> { [ 1, exclam, onesuperior, exclamdown ] };
>
> Sorry for misusing the terminology.
>
> > But basicaly, this could be done simply without breaking
> compatibility.
> > You just create a xkb_symbols("ascii") in pc/us file, and put
> > "NoSymbol" or "any" on higher levels, and just include that from
> > "basic".
>
> Yeah. My simple proposed change here is to move these
> definitions to the latin
> symbol file, then include them from the appropriate us symbol
> files. I don't
> think it would break compatability. I do think that it would
> remind people
> who make new keymaps that the default US behavior has to be
> to only output
> ASCII, because that is the lowest common denominator for the US.
I think that first of all "us" (or "en_US") should be handled just like
everyone else. It should have no special status in any way.
Secondly, it is probably better to use a "US extended" keymapping
as the basic "US" keymapping. It should be possible even for naïve
users to type (current) US names like "Cañon" and "San José" without
having to change keyboard layout.
...
> Using a German keymap doesn't prohibit you from typing in
> English. However, if
> you own a keyboard made for Switzerland, but you set the
> keymap to be German
> (the dominant language here), you won't be able to type the
> characters on
> your keyboard -- like finding the @. Besides novices won't be
> setting this, the administrator will.
?? Each user should easily be able to choose which keymapping to
use. It's very easy for anyone to change keymapping on Windows
and on Mac (among the installed/enabled ones). Hence the names
should be cleaned up, so as not to be too confusing.
> However, I imagine that using a Bengali keyboard will prevent
> one from typing in Hindi (or something).
In principle one could type in Hindi (the language) using Bengali
characters (though that would be a bit odd).
...
> Looking just in the pc/ directory, I see the following breakdown:
...
I agree that there should be some kind of cleanup. E.g. SE is country
code for Sweden, but se is language code for Sami (which has been
confused in the "symbols/" keymappings). Oddly enough there are
also different se (sv really) *and* fi keymappings, even though they
should be identical.
> For the random ones, dvorak will have to stay, and both latin
There are Dvorak layouts also for other languages than English.
E.g. Norwegian and Swedish.
...
> > > This is kind of an odd request and has to do more with
> the keycodes
> > > than the symbols. But, if all the files distributed with
> XFree86 used
> > > the new RLGO symbols, then the only problem would be for users who
> > > were doing customisation with xmodmap or who had their
> own xkb files
> > > that hadn't been sent to XF86 for inclusion. Or perhaps
> there's a way
> > > to preserve the compatability.
And use AE00 instead of TLDE...
----
The "symbols" files for keyboard layouts should be the same (file)
for SUN, PC, Apple, etc. Differences (which there are some) should be
mediated some other way.
My tentative scheme for this is as follows:
In "ng/keyboard" (ng for "new generation"):
hidden partial xkb_symbols "common",
which:
include ng/keyboard(editing);
include ng/keyboard(numeric);
include ng/keyboard(function);
partial xkb_symbols "microsoft",
which:
include ng/keyboard(common);
include ng/keyboard(microsoftsymmetricA);
and similarly for SUN and Apple keyboards, handling the
special keys on those keyboard types. ng/keyboard would be
common to all (ng) keyboards. It handles the editing, numeric
and function sections of the keyboard (except for additions
that some keyboard "manufacturers" have).
Then in "ng/latinbase":
partial xkb_symbols "common-ZoneA"
(this contains mappings for row E in Zone A;
could possibly be put in the "keyboard(common)"
mapping).
and
default partial alphanumeric_keys xkb_symbols "qwerty",
which:
include ng/latinbase(common-ZoneA);
and
partial alphanumeric_keys xkb_symbols "dvorak",
which also:
include ng/latinbase(common-ZoneA);
ng/latinbase would be common to all (or almost all) keyboards
that are primarily for the Latin script.
And finally the keyboards for specific languages, e.g.:
in ng/sv (Swedish):
default partial alphanumeric_keys xkb_symbols "qwerty"
(including "latinbase(qwerty)"), and
partial alphanumeric_keys xkb_symbols "svorak" (for a
Swedish Dvorak layout; including "ng/latinbase(dvorak)").
and in ng/de (German):
default partial alphanumeric_keys xkb_symbols "qwertz", and
partial alphanumeric_keys xkb_symbols "dvorak" (for a German
Dvorak layout, if there is any such).
The idea is then to combine keyboard type (Apple, Sun, MS, ...) and
language mapping; something like "ng/keyboard(apple)+ng/sv(svorak)"
for a Swedish Dvorak mapping on an Apple keyboard.
Comments?
B.t.w., regarding country codes/language codes, the ISO three-letter
language codes are not really entirely sufficient, given that there are
something like 7000 living languages in the world, and ISO covers only
a fraction of them (plus some historic ones, and group codes as well).
(Maybe not all would get their own keymapping, though.)
And no, keymappings are not for countries, they are for languages,
though there may be some country variation, so names like en-US
(which is a RFC 3066 language tag) are quite appropriate. E.g. even
though the Swedish standard keyboard layout was made by the
Swedish National (standardisation) Body, it's for making it easy to
type the Swedish *language* (and, as it happens, the Finnish
language; of course it covers English too). In addition there is a
suggestion for a Swedish keyboard layout for the Sami *language*
(appropriate name: se-SE, which again is an RFC 3066 language tag
for Sami as used in Sweden).
/Kent Karlsson
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
