Date: Fri, 15 Aug 2014 23:13:48 +0200 From: Stefan Esser <se@freebsd.org> To: Ed Maste <emaste@freebsd.org> Cc: "Andrey V. Elsukov" <ae@freebsd.org>, Aleksandr Rybalko <ray@ddteam.net>, freebsd-stable stable <freebsd-stable@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Keymap definitions for VT / NEWCONS Message-ID: <53EE780C.2060402@freebsd.org> In-Reply-To: <CAPyFy2D0eUEiWtL-vvdv2P%2BmsEX7P5vkQNguzeZNob7W5QBuwA@mail.gmail.com> References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <CAPyFy2DMtFhwosD4z4sVHANB3Bp9_kECNrMWHOH=VpJiPyg2aQ@mail.gmail.com> <53EB0DA0.5000305@freebsd.org> <CAPyFy2BsMzvoYdNiYmRb6RTB_=TzDBoCW7PVETchuNirTJ%2BS2g@mail.gmail.com> <53EBEDC8.3080303@freebsd.org> <CAPyFy2DY20CJA6zc18%2Beie7%2BAm5UOV3ucu4vbirFhwcxgptttg@mail.gmail.com> <53ECA9CE.3070106@freebsd.org> <CAPyFy2B6bqiRnqv5kURUYhcGbtR-NqzUcuLDFntPXH4ChnS0mQ@mail.gmail.com> <53ED2CCE.2030103@freebsd.org> <CAPyFy2D0eUEiWtL-vvdv2P%2BmsEX7P5vkQNguzeZNob7W5QBuwA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 15.08.2014 um 17:30 schrieb Ed Maste:
> On 14 August 2014 17:40, Stefan Esser <se@freebsd.org> wrote:
>>
>> Please look at the TAR file I prepared. I rank the symmetry
>> in the format of the names higher than the shorter names.
>> And in fact, keyboard layouts are often specific to a country,
>> and not to a language. The 2-letter names hide the difference
>> for the simple case ("fr" is really sufficient if "fr_FR" is
>> meant), but if you look at syscons/keymaps there are examples
>> of keymap files named after the language code and others named
>> after the country code.
>
> I've been thinking about it some more, and I think this point is
> precisely why I'm not a fan of using the locale name. You're correct
> that keyboard layouts are mainly correlated with location, not
> strictly language, and I think the names should reflect that. Most
> keymaps don't require a specific language part, but the locale scheme
> puts it first.
I see your point and I agree, that the locale names are not really
pretty. But I still think that it is better to use a scheme that
is well known and established (the locale IDs) for this purpose,
since it will give some structure to the file names.
> We should be able to offer an appropriate default layout based on a
> user's locale. I don't think it follows though that the keyboard
> should be named the same as the locale. Using the locale name implies
> a relationship between the locale and keymap that just doesn't exist.
I agree, that we could have a different naming scheme and still
derive a suggested keymap from the locale name.
> You brought up Latin America (es_LA) as one exception so far, and the
> Canadian Multilingual keyboard has a similar issue - what would we
> call it? Why is the Belgian keyboard fr_BE and not nl_BE? Presumably
> because it's AZERTY, but naming it fr_BE seems to imply there should
> be a separate Dutch Belgian layout. Other than consistency for its own
> sake, what do we gain by requiring the ab_CD naming?
Well, looking at the existing names, I think there is lack of a
system for naming the keymap files. I agree, that there may be
cases where a noational standard supports multiple languages
with the same keyboard layout (haven't looked at the Canadian
keyboard). In the case of the Belgian keyboard, we could support
both names (and link them to the same file, with the option to
support different preferences with regard to the Accents handling
for either language by later having separate files for each one).
> For comparison, I looked at the list of keymaps in Debian/Ubuntu. They
> generally use the country code, with some non-ISO 3166 2-letter short
> forms (e.g. "cf" for Canadian French). For the two examples above they
> use the names la-latin1 and ca-multi. I won't suggest we follow their
> names in all cases since there's a lot of inconsistency (e.g. "sg" for
> Swiss German, but fr_CH for Swiss French). But as an overall scheme I
> like starting with the ISO 3166 country code, and adding more specific
> parts where necessary.
Well, but apparently they also use locale names as in the example
of fr_CH, at least in some cases.
I really wound want to have a clear system, and I think that the
locale names are the best system at hand.
> This could give us, as examples:
>
> be Belgian
> ca-multi Canadian Multilingual
> ca-fr French Canadian
> ch-fr Swiss French
> ch-de Swiss German
> us US
Yes, this is also a system that could work. ISO country codes are
well known from their use in domain names, and the mapping would
be to use the country name allone for all cases where there is
only one language in a country and possibly also for the case
where both country and language are the same characters, e.g.:
ch-fr Swiss French (fr_CH)
ch-de Swiss German (de_CH)
de German (de_DE)
it Italian (it_IT)
gk Greek (el_GK)
Would this naming scheme make sense and it is easy to follow
when new definitions are added?
> For layouts not specific to a single country (Latin America, Central
> Europe) we could just use longer names as today.
Hmm, I'll think about this and will hold back the commits I planned
for another day or two.
I'm currently working on the INDEX.keymaps file, which uses a
number of different encodings (as typically used in for the
supported languages, ranging from ISO8859-x over CPxxx to KOI-R/U
and PT154).
I've written a script that should translate the descriptions in
the INDEX.keymaps file to UTF, based on the country code in the
second column. But I have to verify that the conversion result
makes sense, when viewed on a Unicode terminal with support for
all the languages (e.g. by pasting some of the result strings
into Google translate for the respective language ...).
And I found, that the kbdmap command has not been correctly
translated from Perl to C. The selection logic in find_token()
does not implement the regular expression matching that used
to be in the Perl version. This may not cause any problems,
since in fact only the comparison with "lang_abk" is relevant
(other cases are not used in INDEX.keymaps), but I'll have to
verify this assumption.
And it would be good to place the cursor on a list item that
is likely to match the locale selected, instead of placing the
cursor into the first line of the list.
Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53EE780C.2060402>