> > 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).
Yes, but I am not sure if just using "[ 1, exclam ]" would allow *redefinitions* of the keys on the higher levels (where I've put any's). This was just a "technicality", which depends on the actual implementation of XKB, and I'm not certain on this (I would have to check).
Though, while I don't know if simply "[1, exclam ]" would be enough, I am certain that putting any's in would be enough, and it would work as you expected. (any's are actually placeholders which can be redefined, they're equivalent with "NoSymbol", but shorter to type, and more clear in this context).
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?
Yes, for a dozen of languages like the ones you're mentioning, there's this obscurity. For *most* of the other languages and nations, there's no collision.
In any case, just for this reason is the latter proposal about providing *both* country based and language based.
(I was just arguing against *country-only* based keymap names. That's the whole point. I don't mind country based keymaps, if there are also language based keymaps)
True, but that's really the problem with yu, isn't it? :)
Nah, it was to imply that your list was incorrect, and based on wrong assumptions -- the codes you listed were not "national", but some were "linguistic" (sr is a ISO 639 code for Serbian *language*).
> 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*.
As much as 6 out of a list of 15? :-)
I think everything is clear -- we need to provide both "nation-based" and "language-based" naming, if we're aiming for consistency, and want to be sure that it won't be a problem in the future to assign a name to a keymap.
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.
Yes, the ISO codes themselves are using only English alphabet, so no problem there.
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.
Depending on how you look at this :-)
I've already pointed out that many of the languages (uhm, nations) you mentioned actually use the ISO 639 two-letter code ;-) Or was it the ISO 3166 country code? If we don't ask the authors, we can only guess -- and guess what? My guess is different from your guess ;-)
I know I'll be a bit boring, but if case differentiation is a problem, I'd go for providing new namespaces for each: nation/ and language/ (perhaps in shorter forms of "n/" and "l/").
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.
As I pointed out, it's a minor work for someone maintaining the files to provide *both* possibilities.
The "problem", as Andrew Aitchison and you see it, is not a problem in my regard -- everyone has a choice which can be made: choose by the language, or choose by the nation.
> 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.
If systems are single-user, which defeats the purpose of X network transparency. In multi-user environments, you cannot expect every user to use the same language in every occasion.
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.)
I'd prohibit 1-letter filenames because they wouldn't be clear -- there are no ISO codes of length 1 ;-)
Of course, I'd agree with this generally -- this is reasonable and I think (hope?) it wouldn't hurt anyone.
Cheers, Danilo _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
