But Solaris also runs (reasonably well I should say) on "general" x86 (64-bit) systems and by "general" I mean unqualified / unsupported hardware as well. In such cases, it's very well possible that the first difficulty configuring the system is exactly properly configuring the keyboard as an UI input device for system administration, a.k.a. the console keyboard, an otherwise dumb activity considering the other high-expectations on the overall noble system goals. The main reason for such hurdle in configuring the keyboard console lies on the fact that sometimes non-strictly-standard hardware fail to adhere to the proper / expected layout and behavior. But the blame is not entirely on manufactures, the standardizations staff have failed as well. In some cases, it's possible to perfectly fix things, but not always, as some manufactures perform some hard changes in firmware which are impossible to circumvent through software. I believe that in most cases this issue is driven by cost reduction in contrast to "innovation" or "rationalization" or whatever. The fact is that in the end one may face odd (why not say crazy!) situations. On a following post I hope to present just an example of it alongside to an strategy to fix or minimize the problem.
NOTE
It's true that one seldom revert to the system console as nowadays most can be done remotely from a web UI or a graphical X terminal. A web interface or an X terminal is highly resourceful and configurable, but, again, a system console is another story, specially with non-standard / non-qualified / unsupported hardware. But when disaster strikes and one is forced to run to the system console, a perfectly working keyboard is pure gold.In general, I prefer to adhere to the US-English standard everywhere and whenever possible. I justify my argument by saying that for computer systems, English is the mainstream and original language under which all R&D is performed. As such, chances are that everything is better tested and developed in English while all other languages are just translations, inherently prone to less testing and thus more error or bug prone. I recognize and acknowledge all the recent efforts on internationalization but knowing a little more than just the tiny surface I see internationalization just as an extra overhead surface wrapping the bulk of a system or application. And this problem just gets bigger and bigger with some exceptions for a few non-English western languages.
For instance, consider the Portuguese language. I'm not versed in linguistics or history, but, roughly speaking, Portuguese is a Latin language original from Portugal (on the Iberic peninsula at Europe). When Portugal and Spain ruled the seas by the 15th century they established several colonies worldwide in Africa, Asia and finally America. Brazil with its 8,511 millions of km² was by far the largest colony of Portugal. Because things happened that way, today we basically have two major flavors of keyboard layouts for the Portuguese language: the pt-PT and pt-BR, respectively target to Portugal and Brazil requirements.
😜 great! All this blah-blah-blah for the Portuguese keyboard layouts... The bottom-line is that this illustrates how difficulties arise and (as I shell describe) can get worse.
Solaris (or UNIX) engineers did a reasonable attempt which shall work perfectly with a strictly-compliant pt-BR keyboard, but the problem is:
What the hell is a strictly-compliant pt-BR keyboard?The Brazilian strictly-compliant keyboard has changed slightly over the last 4 decades and on top of that you should add up a bunch of Chinese products providing all sort of "crazy" variations of the standard layout. I don't know if or to what extent the English keyboards may suffer from manufacturer issues, but at least for the Brazilian keyboards variations you may now get the picture: it may be hell, believe me!
The short answer: It doesn't materially exist, only free-hell derivatives...
Let's take a visual look of the strictly-standard Brazilian layout in contrast to the English layout (omitting the crazy stuff from ISO which, in practice, for the broad community serves absolute nothing, zero, null in both layouts!):
The Brazilian standard keyboard and layout:
The nice English standard keyboard and layout:
As seen above the changes are few, but the choices were unfortunate. I imagine that (as usual) some stupid bureaucrats took this bad choice and I attempt to explain why I think so:
In coping with the requirements of adding a few missing characters (ç, ª and º , if the last two aren't underlined you can already see how troublesome internationalization may be) to the standard English keyboard layout they did a real mess. Even if you don't understand Portuguese, by looking at both images above, you can realize that to fulfill the required additions to the English keyboard they (the standardization staff) got away with two important keys (/ ? and \ |) in the English layout also need for the Brazilian layout. So they solved on thing but created another problem. In my opinion they didn't solve anything. Instead of doing that mess it would be better to just incorporate the behavior of the US-International keyboard in which you don't miss anything and just have to perform a single additional keypress for obtaining the ç by combining the (dead) ',' and the c keys. The additional overhead for a plain ',' would be minimum, because good practice dictates adding a space after punctuation anyway and to obtain a plain ',' one would combine the (dead) ',' followed by a space or would press the (dead) ',' twice (which is a negligible effort anyway). But yet another alternative idea would be to adopt AltGr + c as a way to produce the ç.
If I still didn't convince you, I would try to put it yet another way:
i) For the Brazilian Portguese, in order to get the needed diacricts á, à , ã, â, é, ê, Ã, ó, õ, ú, ü two keystrokes (not considering some shift presses) are necessary both on the Brazilian or English keyboards, hence no additional cost would be necessary in layout rearrangements or manufacturing.
ii) For the ª and º two keystrokes are required in the Brazilian keyboard. On an English keyboard that could be AltGr + a and AltGr + o respectively, simple as that and just two keystrokes as well (no additional cost necessary in layout rearrangements or manufacturing), not to mention that their occurrency is low enough.
iii) For the ç, I can't negate that it's gorgeous to get it on an single keystroke and that its ocurrency is high enough. But doing so caused a lot more trouble than benefits. Furthermore, it wasn't considered that (AFAIK) no usual Portuguese word begins by a capital Ç, hence it should have been left for only when Caps is on. What they did wasted one position which is at a premium.
iv) Finally the ¨ was kept but by that time it was already optional and nowadays became obsolete. That is, one more position at a premium was wasted again.
As said above the mess delivered by the standardization staff resulted in important keys (/ ? and \ |) missing from the keyboard and not covered by any standard. This, of course, was an open door to manufacturer hell which started to invent variations to try to supply what became missing. And the mess grew and grew until today when we suffer the consequences.
Fortunately, Solaris does provide some flexibility for coping with this madness, although it cannot fix what is bugged into hardware by some negligent manufacturer on the other side of the world! On a following post I will address a real example of the problem and a close to the ideal solution, depicting the technique to deal with the problem for any other odd keyboard you may encounter on your way 😜
