From owner-freebsd-stable@FreeBSD.ORG Fri Aug 15 21:20:59 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7B80E6D; Fri, 15 Aug 2014 21:20:59 +0000 (UTC) Received: from mailout09.t-online.de (mailout09.t-online.de [194.25.134.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52AD52B62; Fri, 15 Aug 2014 21:20:59 +0000 (UTC) Received: from fwd36.aul.t-online.de (fwd36.aul.t-online.de [172.20.26.137]) by mailout09.t-online.de (Postfix) with SMTP id 316933F4517; Fri, 15 Aug 2014 23:14:02 +0200 (CEST) Received: from [192.168.119.26] (XHPJZgZ-Qhq08X6SnHVIoT7zw+H+dkPP9dkRfCyCGGnRMJHgMlC5ciT-8LYzWiPQVe@[84.154.101.219]) by fwd36.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XIOox-2FCJxQ0; Fri, 15 Aug 2014 23:13:59 +0200 Message-ID: <53EE780C.2060402@freebsd.org> Date: Fri, 15 Aug 2014 23:13:48 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ed Maste Subject: Re: Keymap definitions for VT / NEWCONS References: <53EA0EC2.2070601@freebsd.org> <53EA1E5A.5020707@FreeBSD.org> <53EA2D00.7010307@freebsd.org> <53EB0DA0.5000305@freebsd.org> <53EBEDC8.3080303@freebsd.org> <53ECA9CE.3070106@freebsd.org> <53ED2CCE.2030103@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: XHPJZgZ-Qhq08X6SnHVIoT7zw+H+dkPP9dkRfCyCGGnRMJHgMlC5ciT-8LYzWiPQVe X-TOI-MSGID: cbc7b38b-8c36-493c-9193-f7e77e328f13 Cc: "Andrey V. Elsukov" , Aleksandr Rybalko , freebsd-stable stable , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 21:20:59 -0000 Am 15.08.2014 um 17:30 schrieb Ed Maste: > On 14 August 2014 17:40, Stefan Esser 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