> > Sorry, I meant shift levels. my proposed us-ascii would have just
> >
> > key <AE01> { [ 1, exclam ] };
> >
> > not
> >
> > key <AE01> { [ 1, exclam, onesuperior, exclamdown ] };
>
> I'd go for:
>
> key <AE01> { [ 1, exclam, any, any ] };
>
> (I'm not sure if your idea would work like this -- if it would,
> then this is unneccessary burden).
It's already done with only two levels in the pc/us keymap. I don't see a
reason to add the 'any's. The point was to move the generic us layout from
pc/us to pc/latin so that sun/, sgi/, etc could include them without getting
any PC-keyboard-specific baggage (like function keys or whatever).
> > 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.
>
> The thing I wanted to point out that if someone was offered with a
> choice that read "Germany" (implying a country name) instead of
> "German", it'll be easy to mistake it for "enter your current location".
>
> It's a sort of "Great Britain" for the english layout -- would you ever
> look for that if you needed english layout?
>
> OTOH, when it says "German" there are no doubts, even if you're right
> now sitting in a hotel in Germany wishing to type in English ;-)
The problem is that there is no English-language keyboard layout, nor is there
a German-language layout. There are different layouts for Britian, Ireland,
Canada, Australia, Germany, Switzerland, and Austria. So saying German or
French or English does leave doubts: is this a keyboard from France or does
this keyboard allow me to type the French language?
> > > So, I cannot see any advantage to the naming scheme you seem to be
> > > proposing, yet there are many disadvantages.
> >
> > I agree. I think there are two ways of looking at this, but there are
> > three
> > types of keymap files: national (based on ISO 3166 country codes),
> > linguistic (ISO 639 language codes) , and random.
> >
> > Looking just in the pc/ directory, I see the following breakdown:
>
> Actually, many of these are the same for language and nation name,
> thereby, this category would shrink very much. Besides, some would even
> go to only lingustic (like "sr" for Serbian, because "Serbia" is a part
> of larger country "Serbia and Montenegro" with ISO 3166 codes of "CS" and
> "SCG").
True, but that's really the problem with yu, isn't it? :)
> The others, like "de", "es", "fi", "fr", "hr", "it", "mk", "nl", "no",
> "pt", "ro", "ru", "sk", "th", "tr" apply to *both* language and country
> (actually, these are the ones I know about; there are probably others).
The problem is that de, es, fi, fr, nl, and pt have different keymaps
depending on the *nation*.
> > Random: dvorak en_US la latin pc
> >
> > So it seems that a good compromise would be to recomment the ones of
> > the national type to reflect the name of the country (in English), and
> >
> > to leave the ones of the lingustic type to refect the name of the
> > language (in English). Does that address your concerns?
>
> I see your point and it makes sense. Though, I'd go for an international
> standard, because they've already invested time into avoiding
> collisions.
I'd like to us an ISO standard for the filenames. For the description of the
group name, I would bet that we're constrained to 7-bit characters. Besides,
they are all in English now. Plus, in the ISO document, the country names are
listed in English.
http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html
> For the sake of difference, I would recommend the following:
> - National keymaps should use ISO 3166 code in all UPPERCASE (eg. "US")
> - Linguistic keymaps should use ISO 639 code in all lowercase (eg. "en")
>
> This would allow one to have "de" which could apply to all the
> countries where German is used (eg. "de(DE)") and also a "DE" which
> would only apply to Germany. In your example, "CA" (if that's the code
> for Canada) would have "CA(en)", "CA(fr)", while "fr" would have "fr(CA)",
> "fr(FR)",... It's up to the implementor to choose and see where to put
> the actual definitions, and where to simply include them from the other.
I think this is a bad idea. Differentiating based on case can be problematic
(as was pointed out). However, I would think that using ISO 3166 2-letter
national codes and ISO 639 3-letter codes would work OK. Besides, most of the
current entries already follow this.
But I wouldn't encourage a large proliferation of these. For European and
North & South Amarican keyboards, recommend the 3166 code. For Asian and
Arabic keyboards, recommend the 639 code. But don't go wild with all the
possibilities, otherwise we end up with the pt(BR)/en(US) problem that Andrew
Aitchison mentioned.
> Of course, this would cause *major* breakage for old applications which
> rely on one layout being there with a specific name.
The only applications that should care would be the installation programs.
> And just as a sidenote, this wouldn't prohibit any other variations. It
> would just be unwise and unrecommended to use two-letter codes for
> naming xkb_symbols sections in these kind of maps.
I would actually prohibit all 1-, 2- and 3-letter files in these directories
unless they were ISO codes. (Otherwise, we end up with the Latin America/Laos
problem.)
> > For the random ones, dvorak will have to stay, and both latin and pc
> > are kind of include files (though it there ever comes a country or
> > language with ISO code pc ...) The two that I'm worried about are
> > en_US (which looks like a locale for no good reason) and la (which
> > stands for Latin America, but la is the country code for Laos, which
> > has taken lo instead).
>
> Just like the names of xkb_symbols sections, anything that doesn't
> follow a pattern of "two-letter" code (perhaps it could be extended
> to "three-letter" code of ISO 639-2 to accomodate more languages), is
> to be considered "random" in your qualification.
I think so.
> > So, any ideas for what the Latin America keymap should be called?
> > latin_america comes to mind. :)
>
> Perhaps "latin(america)" :-)
:)
> > But for en_US, I'd like to integrate it into the us file and make
> > en_US just include us(latin1). I'd like to make these changes and send
> > patches to someone with access. Is anyone here willing to check them
> > in?
>
> I don't think Ivan will have a problem with that -- from the users'
> point of view, there's no change.
>
> Though, for my proposition, there should probably be a new "namespace"
> appointed (like "pc/" was introduced in XFree86 4.3).
I was thinking that I'd leave the current files existing, but just including
the proper new keymap. I don't think a new namespace is necessary. However,
the Laos keyboard is a strange problem. Anyone have any migration ideas?
> > I'd like to do this, too. Do you know how to map multipe symbols to
> > one key code and how to make it usable? (Perhaps adding an XkbOption?)
>
> Look at the "alias" keyword in keycodes section (eg. check the current
> /etc/X11/xkb/keycodes/aliases). The following in the
> /etc/X11/xkb/keycodes/xfree86 file did it for me:
>
> // Microsoft keyboard extra keys
> <LLGO> = 115;
> <RLGO> = 116;
> alias <LWIN> = <LLGO>;
> alias <RWIN> = <RLGO>;
Cool. Thanks for that.
Frank
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
