The problem is that as "the originator of the French language" France
has nothing to do with the keymaps that, say, Canada has chosen.
Of course -- that's why there would be no direct relation between "FR" file which is the one that "France is in charge of", and "CA" file which is the one that "Canada is in charge of".
"fr" file governs keymaps for the French language, and it's sane (I already mentioned that there are other criteria, like population -- the criterium of "language origin" is just a sample one, for the sake of discussion) to have a "default" behaviour when loading a keymap for French *language* -- whether the default keymap would be Canadian or French is not directly relevant in this discussion -- it depends on the motives one has when defining a default.
You seem to be misunderstanding my idea.
Idea is to *allow* choosing a keymap on either language (eg. "fr(CA)") or country (eg. "CA(fr)"). I never mentioned that any specific country would have "supremacy" over the keymap based on the language.
Perhaps this model of keymap orientation works for other parts of the world, but not in Europe, or with European languages.
Perhaps you're thinking of Poland and Polish? Hungary and Hungarian? Russia and Russian? Finland and Finnish? Serbia and Montenegro and Serbian? Italy and Italian? Greece and Greek? Romania and Romanian? ...
(As many examples you can give in your favour, I can perhaps give twice more -- and yes, they're all in Europe ;-)
Why do I have a strange feeling that you're generalizing based on the (so many times) mentioned 5 or 6 languages? There are thousands of languages in the world, and hundreds of countries.
AFAIK, Europe is not only about them, and that scheme would not work that nice for *most* of the other countries/languages.
At least, you can see that it wouldn't work that nice in regards to me -- I am in Europe, but I am not using any of those languages as my mother tongue.
Another problem with the US(en) model is that the current us file has lots of settings for 105-key keyboards and such things, that would be specified by US(105-key) or something, which has no language code.
Didn't we already agree that anything which doesn't represent a ISO code is to be considered "custom"?
Though, you'll certainly agree that this kind of thing ("105-key") doesn't belong in the "US" keymap, but more like "hardware" or something along those lines.
It isn't necessary to fill this matix of language and country. I think a compromise of using nation or language codes when appropriate is a better idea than trying to manage an unwieldy matix. We have enough troubles keeping the keymaps supported.
I cannot grasp what is so troublesome in:
for i in `cat mapping`; do
first=`echo $i | cut -f 1`
second=`echo $i | cut -f 2`
echo -e "xkb_symbols \"$first\" {\n include \"$second\"\n}\n"
done$first
(this is a lot simplified, but it's the work of running a script which will do a job along these lines).
Cheers,
Danilo _______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
