[Allegro] Neue Zeichensatz-Tabelle

[Bernhard Eversberg]

Thomas Berger schrieb:

> |
> | http://www.biblio.tu-bs.de/db/unicode/grec.php?urN=5083
> 
> mit dem Originalzeichen U0639 hat das nichts zu tun, s.u.
> 
Sagte ich doch, und das war auch der Auslöser meines Mißmuts.
Die Araber haben ein anderes Ain als die Hebräer, deshalb war die
Zuordnung des U0639 grundfalsch.
Im Juli 2000 hat das der Kollege Balk mal bündig abgehandelt und den
bibliothekarischen Umgang mit den Zeichen abgekanzelt:

http://sun250.biblio.etc.tu-bs.de/pipermail/allegro/2000-June/009260.html

Er faßt zusammen:
"Nach meiner Ueberzeugung sollte man entweder Originalschriften oder
Umschriften ohne Sonderzeichen verwenden." Und dabei, anders als weithin
üblich, auch Vokalzeichen wiederzugeben. (Was den Job des
Transliterierers sehr erschwert: er muß dann eine exzellente Kenntnis
der Sprache besitzen, statt einfach Zeichen auszutauschen.)

Um das Arabische kann es uns beim Ain/Ajin/Ayn nicht gehen, sondern nur
ums Hebräische, wo es das einzige keinem Buchstaben zuzuordnende Zeichen
ist:
    http://www.hagalil.com/hebrew/alef-beth.htm
Oft wird anscheinend einfach ein Apostroph dafür gesetzt. Das ist dann
akzeptabel, wenn man nicht, wie in Katalogen, mit einer Vielzahl von
Sprachen umzugehen und sie transliteratorisch unter einen Hut zu bringen
hat. Ein Hamzah haben die Hebräer aber, soweit ich sehe nicht.
Und Windows-OstWest, anders als Berger anscheinend ohne Beleg meint,
auch nicht. (Die 158, die er in seiner Dokumentation anführt, ist
in Win-1252 unbelegt und schwer verwendbar - wie 127 und 141-143.)

LC-MARC (und daran angelehnt Pica) haben

Code 174 = AE für "Hamzah",
      176 = B0 für "Ain"

(Pica beteuerte 1999, DIN31628/2 umsetzen zu wollen, hat inzwischen aber
irgendwie teilweise auf Unicode umgestellt. Im IBW-Handbuch sind noch
die alten LC-Codes abgebildet. In der MARC-Doku findet man dieses:
http://www.loc.gov/marc/marbi/2005/2005-05.html
Die "Romanization table":
http://www.loc.gov/catdir/cpso/romanization/hebrew.pdf
sagt nichts zur Codierung, sondern zeigt nur, wie das Zeichen auf
Papier etc. "romanisiert" aussehen soll: wie ein umgedrehtes
Hochkomma oder unser typographisches einfaches Anführungszeichen
oben. Wie ein normales Apostroph sieht dagegen darin das Alif aus, wenn
man es nicht gleich ganz wegläßt. In der Tat ist das Zeichen eine Art
Platzhalter für irgendeinen vokalischen Laut, daher kann es nicht
mechanisch durch ein bestimmtes Zeichen wiedergegeben werden, wenn die
Transliteration halbwegs phonetisch sein soll. Eine unbestimmte
vokalische Qualität kommt auch dem arabischen Hamzah zu, das meist
als "glottal stop" umschrieben wird. (So bezeichnet wird auch der
Verschlußlaut, der im britischen Englisch weitgehend das t verdrängt hat
und das bestbekannte Kennzeichen des "Estuary English" ist, aber das nur 
nebenbei, es ist hier irrelevant.)

In PICA.AIM ordnen wir bisher der 176 ein Spatium (!) zu, die
174 bleibt ungeaendert (und wird also in OstWest Z mit Hacek :-( ).
Beides unkorrekt - aber Probleme fielen noch keine auf.
In _unseren_ Daten sind beide Zeichen also extrem selten. Wir
ändern PICA.AIM dahingehend, daß der 176 die 213 zugeordnet wird
(Win 146) und der 174 ein Apostroph (39).

Es scheint daher richtig, den Code für Ain im Angebot zu belassen, aber
mit dem Einverständnis, daß er nichts mit dem Arabischen zu tun hat und
dafür keine Verwendung findet. Apostroph für das Ain wäre auch fast
akzeptabel, wenn es beim Indexieren schadlos weggelassen werden kann
(anders als beim Arabischen). Deshalb hatte ich gefragt, wie es denn
indexiert wird. Im IxTheo fällt es weg, wie ich jetzt sehe. In unserer
i.apt ebenfalls. Ich kann nur vermuten, daß dies der Auffindbarkeit
von Wörtern weitaus weniger schadet als im Arabischen das Weglassen
der Akzente beim Indexieren und der Vokale beim Transliterieren.
Zu letzterem können wir ja nun datentechnisch wirklich nichts
beitragen.
Die gegenwärtige LC/ALA-Tabelle ordnet dem hebr. Ain den Unicode
02BF zu, und das machen wir jetzt auch.

Die von Balk angeprangerte Malaise können wir nicht beheben, es kann
uns nur um den ganz kleinen Nebenaspekt des Ain im der Transliteration
des Hebräischen gehen, um den Code und das zuzuordnende Zeichen in
Unicode endlich mal zu klären - mehr nicht.

B.E.