Summary: | Changes to Finnish symbols file | ||
---|---|---|---|
Product: | xkeyboard-config | Reporter: | Troy Korjuslommi <tjk> |
Component: | General | Assignee: | xkb |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | high | CC: | anssi, matti.aarnio, tjk |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://kotoistus.tksoft.com/linux/symbols_fi.txt | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Troy Korjuslommi
2007-10-10 02:08:57 UTC
No need for a separate bug. But I am not sure it should be default - if the only reason it is the national standard. The default one should be the one which people are used to. Most of the users, I mean. Is kotoistus the one? Anyway, it is committed The Kotoistus layout is designed so that current keyboards work as before. Only the unmarked positions are changed. In other words, most users will notice nothing different switching to Kotoistus. In terms of the unmarked characters, people will have to learn the new positions anyway, so we might as well change now. I think there are more pros in favor of switching sooner rather than later. Well, since that variant is not a national standard yet, I'd prefer to postpone that change (and even after that, no promises - I'll keep thinking about it). Changing default variant is a dangerous thing, so I need very serious reasons for it. There are already precedences where official national standard is not the default variant - because people more used to some other variant. The kotoistus layout is the only one able to produce all characters needed in Finland. The older one is iso-8859-15, not utf-8, which is needed in Finland. The keyboards in use today work with the kotoistus layout. Some new functionality is provided, so eventually new keyboards will also appear, with new engravings. The old layout doesn't have any positions which would be different from the kotoistus layout, and would also be engraved on the keyboard. In that sense there is no difference between the old layout and the kotoistus layout. People will of course use whatever is the default, so as long as the default is not changed, most people will not switch. The big difference is that instead of having to guess how to produce some letters needed in Finnish, the new layout specifies them explicitly. The one argument in favor of postponing might be that some applications might have problems with reading Unicode characters from the keyboard. Whether or not some users will find bugs in software is unknown. I guess it is a political decision whether to make it difficult to produce Unicode from the keyboard (by not setting the Unicode compatible layout as the default) and thus protect buggy applications, or to let some time pass and see if bugs appear with the current lower user numbers. Ok, committed. In case of troubles I'll let people blame you:) Thanks Sergey. I am looking forward to all the gratitude I will receive. I'm not sure if it is just me, but the new altgr+space as non-breaking space [1] (previously and still available as altgr+shift+space as well) is driving me crazy. When I'm writing things such as "find blabla | xargs grep" or "[ foo ]", the first space after {}[]| very often becomes a non-break space. It is quite frustrating to debug e.g. scripts that have random invisible non-break spaces here and there, where normal spaces were intended. [1] http://webcvs.freedesktop.org/xkeyboard-config/xkeyboard-config/symbols/fi?r1=1.14&r2=1.15 You're right. This is a clear divergence point for normal users and those who write code. The presumption is that normal users are not able to change their layouts as easily as coders (read "expert users"), so the default layout should be designed for their needs. Of course, some people who write code are not really expert users in terms o X11, and even if so, there should be an easy way to change some settings to be more suitable especially to users writing code. Would it be overkill to define an extra entry for such purpose? And what would it be called? "Kotoistus for Coders" or "Kotoistus2"? Thoughts, anyone? Well IMHO we could just drop the nbsp change. If not, I do not see any other alternatives (I'm not an X expert, though) than two layouts. "Kotoistus" and "Kotoistus (strict)", with "Kotoistus" being the default without nbsp change. Ok, I am dropping nbsp mapping. For people who want nbsp, there are related XKB options (entire group!). Sergey, there is no need to drop nbsp completely, just the new altgr+space combination (third field of <SPCE>). Why cannot people use nbsp options explicitly? They are sooo flexible;) Well, non-expert users likely don't know about that, and there is really no reason to change the behaviour that far from standard, and the previous Finnish layout, now named "classic". I believe we should keep altgr-shift-space as nobreakspace as before. BTW, I just noticed these comments about nbsp in the "classic" Finnish layout: // AltGr+<SPCE> is pressed accidentally too often after AltGr+<LSGT>, // hence AltGr+<SPCE> produces now space, not nobreakspace. key <SPCE> { [ space, space, space, nobreakspace ] }; ok, for compatibility sake... returned on 4th level I wrote a commentary on the issue when the change was made in October 2007. It is at http://kotoistus.tksoft.com/linux/space-en.html The problem is not unique to X11. The same problem occurs on Windows. Essentially the conflict is between normal users, and people who write code. Normal users of Finnish require the use of non-break space frequently. E.g. for writing numbers. People who write code, even if just CSS stylesheets, can be considered a special interest group, and also expert users, and thus more capable of selecting their own keyboard layout. This is why it is more reasonable to follow the Finnish standard, and provide customized layouts which cater to special groups such as people writing code. Personnally I prefer not to have the no-break space, and that is why I originally left it out of the layout, agreeing with the comments in the previous layout document. I changed my mind because I am not an average user, and the keyboard layout is supposed to be meant for the average user, not for people like myself. If you don't agree with the no-break space rule, you should complain to the workgroup working on the Finnish standard, at http://www.kotoistus.fi/. The comment phase of the standardization process is just starting. Ok, I see your pointed. nbsp returned to the 3rd level. I took freedom to use nbsp(level3) instead of explicit SPCE mapping Ok, but using nbsp(level3) changed the behaviour so that altgr+shift+space no longer produces anything, while it used to produce NBSP. I think altgr+shift+space should continue to produce NBSP as well. It could be done by including both nbsp(level4) and nbsp(level3) or by restoring the explicit mapping. For now Mandriva Linux will keep nbsp as level4 only in Finnish layout by default (due to some reports from other users). > For now Mandriva Linux will keep nbsp as level4 only in Finnish layout by
> default (due to some reports from other users).
So, what's your opinion - should we use both nbsp(level3) and nbsp(level4) or only nbsp(level3) or only nbsp(level4)?
Well, my opinion is still "nbsp(level4) only" by default because of the high risk of invisible typos, but I do recognize Troy's reasoning as somewhat sound as well. I'd rather like to hear the opinions of more people on this one. I'll ask it on some localization/LUG lists. In any case, "nbsp(level4) + nbsp(level3)" is better than "nbsp(level3) only". I'd say that both 3 and 4 is the way to go. 1) It's The Standard (TM). 2) NBSP is underutilized anyway, even when it should be (which is relatively often in Finnish at least), thus inputting it should be easy and standard across platforms. 3) Those bitten by it most often are those who can map it away most easily (though perhaps an easy way to do it could be introduced) Finally (to get a bit off-topic for this bug), the accidental NBSPs seem to be to a great degree an UI problem. I'd posit that it'd be good for applications such as editors and IDEs to somehow indicate an NBSP (background color?). For viewers, of course, this wouldn't be advisable as it'd be intrusive. Terminals would be a more difficult problem to tackle as they should be able to nonintrusively display NBSPs output; however, perhaps some options would be nice: 1) Option to highlight NBSP:s: a) When appearing after typing an NBSP from the keyboard b) Always c) Never 2) Remove said highlight after [n] seconds (after the user has presumably noticed it, and reacted appropriately), 0 for never. Feel free to make such suggestions for relevant applications ;) I did some work on a programmer's keyboard for Finnish, which solves the nbsp issue. I have been waiting for more feedback before posting it (I wrote them approx. six months ago). I would appreciate your feedback on the solution posted here: http://kotoistus.tksoft.com/programmer-kbd/fi/index.html The links are "koodari" and "ascii koodari." The pages are only in Finnish. There is another solution by Yucca Korpela as well (for MS Windows). The link can be found at the bottom of the page. Please don't ignore it, as it has a different set of characters defined. I am particularly interested in hearing whether a third solution with even fewer changes would be called for. Maybe even only nbsp? The issue of displaying nbsp with a different background, or as a special symbol is a serious TODO item. The issue affects X11 systems as well as Windows. NBSP can wreak havoc in unexpected places, e.g. in CSS stylesheets. All editors on all platforms should therefore address its handling. Unfortunately i18n is a little like security. Everyone complains when it doesn't work, but programmers pay it no heed. *** Bug 24864 has been marked as a duplicate of this bug. *** Reopening for the addition of nbsp(level4) in addition to the current nbsp(level3) as per comment #19, comment #20, comment #21. Fair enough, committed |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.