Date: Thu, 14 Aug 2014 23:40:30 +0200 From: Stefan Esser <se@freebsd.org> To: Ed Maste <emaste@freebsd.org>, freebsd-stable stable <freebsd-stable@freebsd.org> Cc: "Andrey V. Elsukov" <ae@freebsd.org>, Aleksandr Rybalko <ray@ddteam.net>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Keymap definitions for VT / NEWCONS Message-ID: <53ED2CCE.2030103@freebsd.org> In-Reply-To: <CAPyFy2B6bqiRnqv5kURUYhcGbtR-NqzUcuLDFntPXH4ChnS0mQ@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 14.08.2014 um 19:13 schrieb Ed Maste: > On 14 August 2014 08:21, Stefan Esser <se@freebsd.org> wrote: >> There probably won't be a 1:1 mapping for all cases, but I think >> that there is value in going for a regular naming scheme. >> >> We can use "fr.kbd" as a short form of "fr_FR.kbd", but there >> will be a "fr_CH.kbd" and possibly a "fr_CA.kbd". The "fr" in >> the short form will correspond to the "FR" in "fr_FR.kbd", >> which is hidden by the fact, that both parts read "fr". > > I agree that consistency is a useful overall goal, and I don't have a > very strong preference for the short names, it just seems to me to map > well to what it seems users actually call the keyboard layouts. > French, Swiss French, and French Canadian keyboard layouts in these > three cases. Also, Linux console setting seems to generally use > 2-letter names as far as I can tell. The existing 2-letter names are inconsistent: most are country codes, but in a few cases the language code was used. I do not know why "iw" is used for he_IL (hebrew / Israel), since "iw" does match neither "he" nor "il" ... You can download and check my not-yet committed working files from: http://people.freebsd.org/~se/vt-keymaps.tar.bz2 That TAR file contains a draft version of INDEX.keymaps, which uses keymap files named after locales. I have removed the now obsolete encoding from the explanation for each keymap file. What's missing is the conversion of the localized texts to Unicode (from some ISO8859 variant or CPxxx or koi8-[ru]). I only fixed the English and German texts, so far. > Would every locale we support have either a file or symlink? Or only > a subset, roughly equivalent to what's provided by the syscons keymaps > today? I think we should try to have at least one default keymap file per locale. A special case is es_LA (which Tom Evans mentioned to be used as a pseudo-locale for spanish speaking latin-american countries by e.g. Facebook). But we could link or symlink other locale names to the generic file, for these cases. >> But look at "uk_UA.kbd", which will be short-named as "ua.kbd", >> or "be_BY.kbd" mapped to "by.kbd" versus "nl_BE.kbd" mapped to >> "be.kbd". >> >> For some language/country combinations, the short form ends up >> in a distant location to the long form names. > > But I expect most users would choose from a menu without seeing the > underlying keymap filename anyway, so I don't think this matters much. Well, if you already have a locale set by the user, then you could prefer keymap files that start with the locale name (sans encoding). I have committed an initial fix to kbdmap/vidfont to make it use share/vt instead of share/syscons if started on a system using NEWCONS. But I guess the selection logic is not correct or at least not optimal. There ought to be sufficient time to fix this for 10.1, though. >> And will there be a "ch.kbd" for "de_CH.kbd" (the majority of >> Swiss users will use that keymap), or will they all be of the >> form "??_CH.kbd" ... ??? > > I would assume ??_CH.kbd since I suspect users would generally not > refer to a "Swiss" keyboard layout, but rather a "Swiss German" or > "Swiss French" layout. (I'm happy to be corrected if wrong.) The selection in Windows is (AFAICR, it's been quite some time since I last installed Windows from DVD) to first choose a language (which changes the messages displayed for the following selections). Then you choose a country to complete the selection of a locale. E.g. first selection is "German" or "French", next selection is the country from a list where this language is spoken (which would offer e.g. Germany, Switzerland, Austria for "German" and Belgium, France, Switzerland for "French"). I really should start the Windows installer to check whether this actually is what Windows does ... ;-) >> For all these reasons I think the short form serves no real >> purpose. If you want to support it, you could symlink a short >> name to the locale based name (to allow the use of just the >> country code, if people edit rc.conf by hand, while I'd expect >> the installer to use the locale based keyboard names). > > If we do end up with locale names I don't think there's much value in > having short name symlinks. It's just another level of indirection > that needs to be kept up to date. Yes, I agree. If the selection of the language (and country, where required) is from a menu, the locale names are as good as any other ID. >> I think this should be implemented in time for 10.1, if at >> all possible. > > Indeed, that is exactly why I wanted to move ahead with the "trivial" > cases, even if they turned out not to be so. I'm sorry for the > conflict that caused with your work in progress. Well, nothing has been lost ;-) I had wanted to commit the keymaps named after locales, today, but held back the commit to wait for your reply and further comments. It's already near midnight, here - so I'll do the commits tomorrow, to avoid making silly mistakes (and it has been shown to be bad practice to go to bed immediately after a commit ;-) >> Most users will either use the installer (and will thus >> never see the locale IDs) > > I think we agree that for these users it makes very little difference > what the keymap name actually is, since they won't see it. > >> or they'll manually edit rc.conf and will know their way. > > And in this case I think the country codes are often the way these > users think of a layout, with a few cases where more specific names > are needed. For example, I wouldn't think of a US English keyboard, > but just a US keyboard, and similarly for a French keyboard. I would > not expect to look for a Canadian English keyboard, but would look for > a Canadian French or Canadian Bilingual keyboard. 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. >> And then it's easier to mechanically >> put the locale ID in to the keyboard selection variable, >> instead of thinking about (or looking up) whether this is >> a country that does not need the full locale ID to select >> a keymap. > > But then we either need to provide symlinks for all locale names, or > the user needs to determine if their locale is one which has a keymap > or not. And there may be ambiguities in the "default" symlink mapping; > for instance, there are arguments to be made to symlink en_CA to > either en_US or fr_CA. Well, I do not have an easy answer to this. But being explicit in the names allows to provide easily identified correct keymaps. >> In Europe, you'll often need the locale name, >> not only the country. > > We don't seem to have many cases of this in the existing syscons > keymaps, but you certainly understand this better than I do; perhaps > this will be an issue when adding more keymaps. Look at the locale names in share/locales. There are quite a number that are of the form "xx_XX" with no other locale sharing the country or locale part. But there are quite a number where languages and countries are in a n:m relation and some where the language and country IDs are different (e.g. "da_DK"). We are used to identify countries with ISO country codes (most probably because of their use in DNS addresses), but as I said, not all 2-letter keymap names where derived from the country code and I can see how that happened. Using locale names adds a few characters to the ID, but makes it really clear what is meant. >> I really think we'll regret using anything but locale names >> for keymaps, and I'd want to rename those that you committed >> under 2-letter ISO names. Is that acceptable to you? > > The worry I have with using locale names is that it implies there is a > 1:1 mapping, which is sometimes true and sometimes not. Do you know about cases where this is the case? I've seen locales where a "Traditional" and "modern" layout exist, but that's easily added (like the .acc." marker) to the keymap name. The keymap named after the locale should be a good first try for a freshly installed system (I hope ...). Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53ED2CCE.2030103>