Frank Murphy wrote:
> Also, it is currently possible for naïve users to type Latin1
> characters. By
> using Multi_key (mapped to right Windows-logo by default on
> Debian, at
> least). I think that this is handled through the widget
> library on the client
> side, but I don't know for sure. Multi_key+, followed by c
> generates ç, and
> that methodology would need to be taught.
Eeeh, no. Not that method. There is no such method on Windows
(as far as I know), and definitely not on MacOS. Instead they use
"deadkeys" (which is supported by XKB too, but I cannot figure
out why the "Compose" files are not located among the other
XKB keylayout configuration files, where they belong).
The other good approach is to use a "live" keyboard, that in place
of having "dead" keys, generate combining characters.
...
> > There are Dvorak layouts also for other languages than English.
> > E.g. Norwegian and Swedish.
>
> I didn't realize. Are they different or are the letter keys
> the same? If they
Since there are three (six if you count case) extra letters assigned to
their three own keys, the layout cannot be exactly the same.
> are, then Xkb could be configured with se+dvorak and avoid all the
That will not work since the default Swedish map is qwerty-ish one,
and åäö are not in the same place as in Dvorak as in qwerty (some
punctuation is consequently moved too).
...
> > My tentative scheme for this is as follows:
> ...(good long-term plan snipped)...
> > 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).
>
> I totally agree. I've been working on an Apple file for just this.
>
> > 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).
>
> What is row E? What is Zone A?
Row E (in Zone A) generally has digits and punctuation assigned to
the keys. Zone A is the "alphanumeric part" of the keyboard.
You really need 9995... But the Axxx key names in XKB are in Zone A
(hence the A in the names).
> > ng/latinbase would be common to all (or almost all) keyboards
> > that are primarily for the Latin script.
>
> I like the idea. While working on my proposal, I thought that
> a main keymap
> per script was the way to go. Have a latin, cyrillic, greek,
> gujarati base,
> and change from there (qwerty, azerty, etc.).
Good.
I can send you my files on this; maybe we can coordinate something.
> > 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.
>
> I really like the idea. However, I don't think we can move to
> fast. I'd prefer
> to do incremental changes towards something like this.
I see no reason to drag on it too much...
> > 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.)
>
> There are a lot of languages, but with the data we have now
> (keymaps in XFree
> CVS) we can only worry about 75 or so. Plus, if ISO can't
> resolve this, I
> don't think we can.
>
> > 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.
>
> People have been thinking of these mappings as per country,
Mistakenly.
> and in some cases
> it makes more sense than mapping per language. Here in
> Switzerland, the
> keyboard is different than the keyboard in Germany, France,
> and Italy, and
> the people use it to type German, French, and English. Adding
> a different
> keymap to de, fr, and it in order to make the same keymap
> doen't make much
> sense (though it should just be an include "de(ch)").
And the keymappings for Swedish and Finnish are exactly the
same, even though the languages are unrelated...
> Also, with the two-letter domain-names, people think that fr
> is France, not
> French,
Why? I didn't, and regarded the "se" name as a mistake.
> then add the flag of France to the keymaps (because
> flags look good
> in the GUI). The distinction between languages and countries
> can be very
> political.
>
> > 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).
>
> Using my proposal, there would be a file 'se' that would
> define this keymap
> (like there is now). Then there would be a file 'fi' that
> would include
> "se(whatever)". Plus there would be a file 'sme' that would
> define the
> Northern Sami language (presumably for Finland, Norway, and Sweden).
There would be *at least* two different keyboards: Sami in Sweden
and Finland, and Sami in Norway.
/kent k
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
