> No, I didn't mean to imply that "FR" was choosen as a default for "fr"
> because of "textual similarity", but rather, because France, with ISO
> 3166 code of "FR", is the "originator" of French language "fr" (perhaps
> this is not a good enough reasoning, and your reasoning based on
> population might be more adequate, but that's another topic).

The problem is that as "the originator of the French language" France has 
nothing to do with the keymaps that, say, Canada has chosen. Perhaps this 
model of keymap orientation works for other parts of the world, but not in 
Europe, or with European languages.

> This would imply that we would have "en(GB)" as default for "en" and
> "pt(PT)" (if "PT" is indeed a code for Portugal) for "pt".
>
> > Portugese (pt iirc) is worse; iirc pt(BR) massively outweighs pt(PT).
>
> The idea was exactly to try to limit these "collisions". The Brazilian
> user would actually prefer to use "BR" (which would default to "BR(pt)"
> and be the same as "pt(BR)"), same as US user would probably prefer to
> use "US" (which would default to "US(en)", being equivalent to "en
> (US)").

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.

> I believe that everyone can be satisfied at least a bit -- I don't
> expect Brazilians to mind that using just "pt" will not give them
> adequate keymap, if "BR" would do the trick. Still, Portuguese would be
> very happy that their keymap is considered "default" for "pt".
>
> > I think we have established that this is an area where people's
> > prejudices will cause them to make unexpected assumptions.
>
> Yes, quite so. I was just trying to remedy that by providing *both*
> choices -- based on country, and based on language. So, if one
> Brazilian fellow actually insisted to access the keymap using the
> language name, it wouldn't (or shouldn't) be a problem for him to use
> "pt(BR)".

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.

> But, if we count in the prejudices, there'll probably never be a
> perfect solution. If there were, there would be no need to discuss this
> at all, and we would continue with the current trend of assigning
> keymap names on the "when it comes" basis.

I would agree, with just the caveat that no 1-, 2-, or 3-letter files. Unless 
they fall into *some* category.

Frank

_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n

Reply via email to