Texte auf der Basis des lateinischen Alphabets lassen sich mit einem Texteditor flink schreiben. Doch sobald andere Buchstaben ins Spiel kommen, ist der Umgang mit dem Rechner plötzlich gar nicht mehr so leicht. Das Answer Girl versucht, seine Russisch-Kenntnisse aufzufrischen.

Fremdsprachliche Korrespondenz im Internet-Zeitalter ist gar nicht so leicht: Früher griff man einfach zu Stift, Papier und Wörterbuch, um der Brieffreundin am anderen Ende der Welt ein paar gestammelte Zeilen in ihrer Muttersprache zu übermitteln. Heute soll dies per E-Mail gehen. Doch leider ist das Rechnerwesen durch und durch auf die Buchstaben des lateinischen Alphabets zugeschnitten: Anders als der Füllfederhalter gibt die Tastatur des durchschnittlichen westlichen Computers nur Zeichen des (7-Bit-)ASCII-Zeichensatzes aus.

Die deutsche Tastaturbelegung liefert als Bonus noch Umlaute und ß mit, und wer ein wenig herumspielt, findet heraus, dass [AltGr-a] die skandinavische æ-Ligatur, [AltGr+o] ein dänisch-norwegisches ø produziert. (Wer mag, darf gern auf eigene Faust ausprobieren, welche versteckten Zeichen-Perlen ein deutsches Keyboard noch bereit hält, wenn man [AltGr] mit anderen Tasten kombiniert.)

Spanisch: mangelhaft, Russisch: ungenügend

Lässt sich so noch ganz gut auf Französisch parlieren, muss ein polnisches, “durchgestrichenes” l einem “normalen” l weichen, und die umgedrehten Frage- und Ausrufezeichen am Anfang eines spanischen Fragesatzes oder Ausrufs bereiten erst recht Kopfschmerzen. Doch das sind alles Peanuts, verglichen mit dem Problem, vor dem diejenigen stehen, die mit ihrem gewohnten Texteditor “schnell mal” Texte in einer Sprache mit nicht-lateinischem Alphabet schreiben wollen.

Die pragmatische Lösung lässt sich im Netz (und lustigerweise oft auch auf Werbepostern in der Wirklichkeit) beobachten: Statt des Devanagari-Alphabets benutzt indische Werbung verstärkt das lateinische, um ihre Botschaften in Hindi, der verbreitetsten indo-arischen Sprache des Subkontinents, für Vorbeifahrende schneller lesbar zu machen. In russischen Foren und Newsgruppen finden sich russische Textaussagen vorzugsweise in lateinischer Transkription statt in kyrillischen Buchstaben.

Tatsächlich lassen sich Sprachen, deren Buchstaben sich nicht einfach von links nach rechts (oder umgekehrt) aneinanderreihen, sondern etwa (wie in Hindi) Vokal-Markierungen über, unter, rechts und links der Konsonanten kennen, nicht ohne weiteres auf einem “deutschen” Rechner schreiben. Doch wer aufmerksam seiner Linux-Installation gefolgt ist, hat unter Umständen bemerkt, dass kyrillische Fonts und Codepages installiert werden konnten (und ggf. sogar wurden). Wenn der Browser auf modernen Distributionen Web-Seiten wie http://www.linux.ru/ korrekt mit kyrillischen Fonts darstellt (Abbildung 1), besteht zumindest Hoffnung für Russisch-Lernende, Rechner wie Texteditor dazu zu überreden, einen echten kyrillischen Text zu erstellen.

Abbildung 1: Moderne Distributionen sprechen Russisch im Browser

Heute nicht für X

Wie bei allem, was mit Tastaturbelegung zu tun hat, müssen dazu unter Unix zwei Baustellen aufgerissen werden: Wer grafisch arbeiten will, kommt nicht umhin, X entsprechend konfigurieren. Da hier root-Rechte vonnöten sind und Änderungen der X-Server-Einstellungen nur dann sinnvoll erscheinen, wenn sie für den Langzeitgebrauch statt für ein kurzes Intermezzo gedacht sind, lassen wir diese Möglichkeit im Folgenden außen vor.

Weitaus schneller und unproblematischer stellen wir die Linux-Textkonsole so um, dass sie kyrillische (und weiterhin auch lateinische) Zeichen von sich gibt. Nötig sind dafür keine root-Rechte, nur drei Dinge:

• Die auf der Konsole verwendete Schrift muss die Zeichen des kyrillischen Alphabets enthalten.
• Die Tastaturbelegung muss so umgestellt werden, dass sie dem entspricht, was auf einem russischen Keyboard aufgedruckt wäre.
• Der Treiber für die Konsolenausgabe muss mit einer Zuordnungstabelle dazu überredet werden, auf passenden Tastendruck auch ein entsprechendes Zeichen auszugeben.

Mit diesem Schlachtplan im Gepäck schalten wir frohgemut auf eine der Textkonsolen um: Wer normalerweise grafisch arbeitet, benutzt dazu die Tastenkombination [Strg-Alt-Fx], wobei mit [Fx] eine Funktionstaste, auf den meisten Linux-Installationen aus dem Vorrat von [F1] bis [F6], gemeint ist. Mit [Strg-Alt-F1] landet man so auf der ersten Textkonsole; [Alt-F7], manchmal auch [Alt-F8] schaltet wieder auf die Grafikkonsole um.

Neu belegt

Am einfachsten sollte die Aufgabe sein, die Tastaturbelegung umzustellen: Distributoren aus amerikanischen Landen hatten noch bis vor kurzem die dumme Angewohnheit, auf der Textkonsole auch dann die amerikanische Belegung beizubehalten, wenn sich die Installateurin ein deutschsprachiges Linux-System wünschte. Rettung in der Not brachte der Befehl loadkeys de, auf dass die Tastaturbelegung der Beschriftung des deutschen Keyboards folgte.

Diesen Befehl loadkeys werden wir wieder brauchen, nur dass wir uns mit einem

loadkeys ru

in der Textkonsole natürlich die Übereinstimmung der Beschriftung mit der Belegung “zerschießen”. Zum Glück bezahlen wir diesen Mut nicht mit einem total verkorksten Keyboard: Da auch russische Computer weiterhin auf die üblichen Shell-Befehle reagieren sollen, bietet die russische Tastenbelegung im “Normalzustand” eine amerikanische. Anders ausgedrückt: Der ASCII-Zeichensatz ist eine Untermenge aller anderen Zeichensätze.

Hinter dem [z]-Key einer deutschen Tastatur verbirgt sich so nun ein y, [ß] gibt das Minuszeichen aus, [ö] das Semikolon, [ä] das Hochkomma ‘, [-] den Schrägstrich, [Umschalt-,] ein < und [Umschalt-.] das >. Ein loadkezs de beendet das Experiment, denn die weitere Recherche geht sicher mit der gewohnten deutschen Tastaturbelegung besser von der Hand.

Sollte der Befehl loadkeys ru mit einer Fehlermeldung wie syntax error in map file unausgeführt bleiben, hilft es (so geschehen bei Debian), dem loadkeys-Programm die Pfadangabe zur Belegungstabelle, der keymap, zu übergeben. Die im Dateisystem zu finden, überlassen wir locate: Wir suchen eine Datei, deren Name mit ru. beginnt. Da locate immer ganze Pfade ausgibt, können wir den Schrägstrich, also den Abtrenner für Verzeichnisse, mit ins Suchmuster aufnehmen, um Treffer auszuschließen, bei denen ru. innerhalb eines Worts steht:

pjung@debian:~$ locate '/ru.'
[…]
/usr/share/keymaps/i386/qwerty/ru.kmap.gz
/usr/share/language-env/ru.xbm
/usr/share/pixmaps/gkb/ru.png
pjung@debian:~$ loadkeys /usr/share/keymaps/i386/qwerty/ru.kmap.gz

Die an der Endung .gz erkennbare Komprimierung der Datei mit gzip macht neugierig: Sollte es sich bei den Keymaps um menschenlesbare Textdateien handeln? Ein

pjung@suse:~> zless /usr/share/kbd/keymaps/i386/qwerty/ru.map.gz
! Russian Cyrillic keyboard.map. "Cyrillic" mode is toggled by
! Right_Ctrl key and shifted by AltGr key.
[…]

liefert dann auch die lebenswichtige Information, wie wir von der amerikanischen Belegung eines russischen Keyboards zur kyrillischen kommen: Die rechte [Strg]-Taste schaltet um.

Schriften gesucht

Wenn die Tastenbelegung für die Eingabe zuständig ist, sorgt erst eine passende Schrift dafür, dass man von den kyrillischen Zeichen in der Bildschirmausgabe auch etwas zu sehen bekommt. Manche erinnern sich vielleicht noch, dass die Installationsroutinen der Distributionen in vergangenen, textbasierten Zeiten meist sogar ein Auswahlmenü boten, aus dem man sich den passenden Konsolenfont heraussuchen konnte. Dabei kam das selbsterklärende Kommando setfont zum Einsatz, wie ein schneller Blick in die Manpage mit man setfont bestätigt – und netterweise verweist diese im Abschnitt SEE ALSO gleich auf den Befehl mapscrn, den wir noch brauchen werden, um die Zuordnungstabelle für die Bildschirmausgabe (die “screen output mapping table”) zu laden.

Als Argument benötigt setfont den Basisnamen eines Konsolenfonts, der das kyrillische wie das lateinische Alphabet umfasst. Tatsächlich reicht ein locate consolefontless, um alle installierten Schriften für die Textkonsole im Verzeichnis /usr/share/kbd/consolefonts (manchmal auch /usr/share/consolefonts oder /usr/lib/kbd/consolefonts) zu finden. (Benutzerinnen neuerer SuSE-Distributionen müssen locate eventuell nachinstallieren, da dieses nützliche Werkzeug nicht mehr standardmäßig eingespielt wird.)

Leider fällt die Auswahl hier nicht ganz so leicht, denn es gibt gleich mehrere kyrillische Font-Kategorien für die verschiedenen kyrillischen Codepages. Spätestens hier empfiehlt es sich, Google und Co. zu Rate zu ziehen, und sich den Punkt 3.1 des “Cyrillic Howto” (http://www.funet.fi/pub/culture/russian/html_pages/linux/Cyrillic-HOWTO-3.html) zu Gemüte zu führen.

Dieses empfiehlt die Nutzung eines sogenannten Alt-Fonts, dessen Name mit Cyr beginnt, etwa Cyr_a8x16. Auch hier reicht es meist, den Basisnamen der Schrift anzugeben – setfont sollte um die richtige Dateinamensendung und die Verzeichnisangabe wissen (wenn nicht, gibt man einfach den Pfad mit an).

Als klassisches Unix-Kommando sagt setfont nur dann etwas, wenn ein Fehler auftrat (etwa der gewünschte Font nicht installiert ist) …

pjung@suse:~> setfont Cyr_a8x12
Cannot open font file Cyr_a8x12

… nicht jedoch, wenn alles gut ging. Dass sich tatsächlich etwas tut, lässt sich demonstrieren, indem wir die Konsole nacheinander auf verschiedene Fontgrößen umstellen, zum Beispiel:

setfont Cyr_a8x16
setfont Cyr_a8x8
setfont Cyr_a8x14

Glücklicherweise kennen diese Fonts die Buchstaben des lateinischen Alphabets, doch wer jetzt bei deutscher Tastenbelegung versucht, Umlaute einzutippen, stellt fest, dass der Schrift solche Sonderzeichen (genaugenommen an der entsprechenden Stelle in der Font-Tabelle) unbekannt sind. Mit Hilfe der setfont-Manpage und einem Blick ins consolefonts-Verzeichnis kommen wir jedoch sehr schnell darauf, dass uns etwa

setfont default8x16

dieser Sorge enthebt, indem das Kommando die beim Booten des Rechners geladene und im Normalfall gebrauchte Konsolenschrift wieder lädt.

Ausgabe-Übersetzung

Wer jetzt nach der Eingabe

loadkeys ru
setfont Cyr_a8x16

(Achtung: Nach dem Laden der russischen Belegung liegt das y in Cyr_a8x16 auf [z] und das _ auf [Umschalt-ß]!) versucht, mit der rechten [Strg]-Taste vom lateinischen in den kyrillischen Modus zu schalten, bekommt immer noch keine kyrillischen Zeichen zu sehen. Da war doch noch was: achja, die Zuordnungstabelle! Netterweise entbindet das Kyrillisch-Howto die Leserin davon, sich großartige Gedanken machen zu müssen, welche sie dem mapscrn-Kommando im Falle der Nutzung kyrillischer Alt-Fonts übergeben muss:

mapscrn koi2alt

Auch hier sind die meisten Distributionen gutmütig, was das Weglassen des Pfads zur koi2alt-Datei im consoletrans-Verzeichnis (bei SuSE 8.1 etwa /usr/share/kbd/consoletrans/koi2alt) betrifft. Dass das Umschalten mit [Strg] immer noch nicht funktioniert, muss uns nicht verwundern – schließlich sagte schon die mapscrn-Manpage, dass der Konsolentreiber durch Eingabe einer bestimmten Escape-Sequenz unter Umständen erst noch dazu überredet werden will, die von der Benutzerin gewünschte Mapping-Tabelle auch zu benutzen. Diese Escape-Sequenz besteht, wie der Name sagt, aus dem Escape-Zeichen, einer öffnenden runden Klammer und einem großen K. Das Howto liefert (beinahe) den passenden Befehl

echo -ne '\033(K'

wobei die -e-Option dem echo-Kommando sagt, dass es den Backslash als Beginn eines vor der Ausgabe zu interpretierenden Sonderzeichens ansehen soll: Die Oktalzahl 033 repräsentiert das Escape-Zeichen im ASCII-Code. -n verhindert übrigens die Ausgabe eines Zeilenumbruchs am Ende des in Hochkommata eingeschlossenen Ausgabetexts. Um diesen Befehl mit der russischen Tastaturbelegung zu erhalten, tippt man auf der deutschen Tastatur echo ßne ä#033)Kä ein.

#!/bin/sh
# Diese Datei sollte nach dem Abspeichern mit chmod a+x name
# ausführbar gemacht werden und kann dann (ggf. mit
# Pfadangabe) auf einer Textkonsole (nicht unter X!)
# aufgerufen werden.
# Pfadangaben wie in der folgenden Zeile können bei
# allen drei folgenden Kommandos weggelassen werden
# Fügen Sie sie bei Problemen an Ihr System angepasst hinzu!
loadkeys /usr/share/keymaps/i386/qwerty/ru
setfont Cyr_a8x16
mapscrn koi2alt
echo -ne '\033(K'

#!/bin/sh
setfont default8x16
# Wenn Sie tote Tasten nicht mögen, laden Sie
# de-latin1 oder einfach de
loadkeys de-latin1-nodeadkeys

Muy goworim po-russki

Jetzt endlich lässt sich der Rechner dazu herab, mit der rechten [Strg]-Taste zwischen russischer und amerikanischer Belegung umzuschalten. Alles, was es nun noch braucht, ist ein internationalisierter Editor. Besitzerinnen einer SuSE 8.1 brauchen sich hier keine Sorgen machen: Ob vi, pico oder joe – die Kommandozeileneditoren machen keinerlei Zicken. Auf anderen Distributionen mag es zwar vorkommen, dass die Shell mangels (einkompilierter) Internationalisierung partout keine kyrillischen Buchstaben in der Konsole ausgibt, doch im vi oder im emacs ging es bei unseren Versuchen immer.

Abbildung 2: Die Tastaturbelegung nach “loadkeys ru” (türkis: ASCII-Modus, violett: russischer Modus)

Fast wären wir versucht zu sagen: “Einfach aufrufen und nach Herzenslust tippen!” Allerdings gilt es aufzupassen, dass man das Umschalten in den ASCII-Modus nicht vergisst, bevor man lateinische Zeichen eingibt: vi-User gehen nach dem Kommandozeilenaufruf vi datei im ASCII-Modus der Tastaturbelegung mit einem vi-Befehl wie [i] in den Editiermodus des Editors. Dort drücken sie die rechte [Strg]-Taste, um zur russischen Tastenbelegung zu kommen, und tippen den entsprechenden Text. Mit [Strg (rechts)] gehen sie in den ASCII-Modus der Keymap, tippen [Esc], um in den vi-Kommandomodus zu gelangen, und geben dann [Umschalt-ö][w][q] zum Speichern und Verlassen des Editors ein, denn hinter dem großen deutschen Ö verbirgt sich im amerikanischen Modus der Doppelpunkt :.

Wer meint, eine deutsche Tastatur mit transatlantischer Belegung zu bedienen, sei schwer, dürfte ein wenig an der russischen Belegung verzweifeln: Wie Abbildung 2 beweist, ist jene alles andere als phonetisch: Ein russisches r (p) liegt eben nicht auf der [r]-Taste westlicher Keyboards, sondern hinter dem deutschen [h], das russische o auf dem deutschen [j].

Eine Frage der Kodierung

Nichtsdestotrotz hat man irgendwann den Dreh raus, den Text verfasst – und möchte ihn sich nun anschauen. Das klappt in den Kommandozeileneditoren bei entsprechend gesetztem Screenfont weiterhin, aber schon wer die Datei unter X mit demselben Editor anschaut, sieht nur noch “komische Zeichen”. Ganz klar: Der durchschnittliche Texteditor geht davon aus, dass er ASCII-Text ohne Sonderzeichen serviert bekommt. (Wer schonmal einen deutschen ASCII-Text von einem nicht-kontinentalen Briten oder Amerikaner bearbeitet zurückbekommen hat, weiß spätestens jetzt, warum anschließend die Umlaute kaputt waren…)

Da der Datei schlicht nicht anzusehen ist, welche Kodierung verwendet wurde, stellen sich die meisten Programme reichlich dumm. Die schnellste und einfachste Variante, den Text abseits der Kommandozeile wieder korrekt zu Gesicht zu bekommen, geht über einen Web-Browser: Klar, wenn der http://www.linux.ru/ korrekt anzeigt, dann sollte er auch unseren Text fressen.

Zu diesem Zweck müssen wir allerdings wissen, welche Kodierung beim Schreiben des russischen Texts zum Einsatz kam: Windows-User werden meist Windows-1251 verwenden – in unserem Fall gibt das mapscrn-Kommando den entscheidenden Hinweis: Wir haben unseren Text in der koi8-Kodierung, und zwar ihrer russischen Form (koi8-r) (im Gegensatz zur ukrainischen koi8-u) geschrieben.

Bei Mozilla und Opera ist der Rest unproblematisch: Nach dem Laden der Textdatei zeigen die Browser erst einmal die falsche Kodierung (linke Seite in Abbildung 3 und 4). View / Character Coding / Auto-Detect / Russian (Mozilla) bzw. Ansicht / Kodierung / Kyrillisch / KOI8-R (Opera) sorgen jedoch dafür, dass der Text korrekt erscheint.

Abbildung 3: KOI8-R-kodierte Textdatei in Mozilla

Abbildung 4: … und in Opera

Beim Konqueror ist das nicht so einfach: Zwar bietet er für HTML-Seiten den Menüpunkt Ansicht / Kodierung festlegen / Kyrillisch (koi8-r), nicht jedoch im Dateibrowser-Modus oder wenn er eine Textdatei anzeigt. Glücklicherweise ist es nicht besonders schwer, aus der Textdatei ein HTML-File zu machen: Wir müssen den russischen Text einfach mit dem Gerüst aus Listing 3 umgeben, das in der Meta-Zeile die Kodierung, genauer den Zeichensatz (“character set“), festlegt.

<html>
<head>
<title>Hier steht der (lateinische) Titel
</title>
<meta http-equiv="content-type" content="text/html"; charset=koi8-r>
</head>
<body>Hier steht der KOI8-R-kodierte Text
</body>
</html>

Verschickt

Damit der anfangs intendierte Briefwechsel mit der russischen Brieffreundin überhaupt zustande kommt, gilt es, den KOI8-kodierten Text per Mail zu versenden. Am unproblematischsten geht das mit mutt, denn der erlaubt es, den Zeichensatz eines Mail-Parts von Hand zu ändern. Wir erstellen also wie gewohnt eine Mail, lesen die KOI8-kodierte Datei entweder in den Editor ein oder hängen sie einfach an.

In der Compose-Ansicht wählen wir mit den Cursortasten den Teil der Mail an, der die KOI8-Datei enthält. Mit [Strg-t] erlaubt es mutt nun, den Content-Type: (“Inhaltstyp”) zu ändern. Was auch immer mutt vorschlägt,

text/plain; charset=koi8-r

ist (für einfache Textdateien) richtig. Manche mutt-Versionen fragen jetzt noch, ob sie den Text beim Versenden nach KOI8-R konvertieren sollen. Die richtige Antwort lautet nein, denn er liegt bereits in dieser Kodierung vor (ein Ja führt zu Datenmüll).

Die Empfängerin speichert den entsprechenden Textteil wieder ab, wechselt auf die Konsole, schaltet mit dem Skript aus Listing 1 in den russischen Modus und lädt die Datei in den Kommandozeilentexteditor. Der Aufruf des Skripts aus Listing 2 schaltet die Konsole wieder in den deutschen Modus. Wer dies vor dem Ausloggen vergisst, kann sich an dieser Textkonsole nur noch mit russischer (alias amerikanischer) Tastenbelegung anmelden – auch ein Grund gegen Umlaute im Passwort.

Abbildung 5: Wenn mutt eine KOI8-kodierte Mail erhält, die er selbst nicht anzeigen kann, stellt er sie auf manchen Systemen in lateinischer Transkription dar