[Allegro] Unicode-Variante der Standardparameter i.Vb.

[Bernhard Eversberg]

Auf unserer Agenda2015 steht noch die Verbesserung der Unicode-
Parametrierung.
Schon ca. 2002/03 hatten wir die ersten Ansätze gemacht, dann hat
die Sache lange Zeit geruht - es war geringe Nachfrage. Spezialanwender
haben aber für ihre Zwecke durchaus schon viel im Alleingang erreicht.
Nun aber wollen wir's nochmal angehen, damit wenigstens für die
als "Referenz" intendierte V35.x dann auch eine weitgehend
praxistaugliche UTF-Parametrierung existiert. Perfektionisten werden
wir nicht bedienen können, das ist klar. Für die ist halt prinzipiell
"good enough" nicht gut genug. Das gilt ja schon sogar für unsere
altgediente Standardversion. Da können wir nur ein entschlossenes
Commitment zu neuen internationalen Standards empfehlen, um die
auf längere Sicht sowieso kein Weg vorbeiführen wird, nur jetzt
im Moment noch kein für jedermann gangbarer vorhanden ist. Ein wenig
ist das wie mit dem Matterhorn, wo ja auch anfangs kaum einer es da
rauf geschafft hat.

Mit a99 wird man zwar arbeiten können! Aber im Auswahlfenster, im
Schreibfeld und in den Formularen *kann* nun mal Unicode nicht
präsentiert werden. Da können wir nichts dafür, das liegt an internen
MicroSoft-Problematiken. Nachbohren zwecklos, es geht nicht.
Nur das externe Editieren ist dann auf Windows-Ebene komplett in
Unicode möglich, mit Notepad, WInVi o.a. Die Register blenden die
Diakritika aus, sind also unproblematisch, das Anzeigefeld wird in den
RTF-Unicode-Modus geschaltet und zeigt dann alles korrekt. Alle 
administrativen und organisatorischen Funktionen von a99 sind
uneingeschränkt nutzbar, weil unabhängig vom Zeichencode. Das gilt auch
weitestgehend für aLF, ORDER und ZAboM. Mit alcarta wird man demnach
auch den UTF-codierten Katalog problemlos als OPAC anbieten können,
das Publikum wird's gar nicht merken.

Einzig das browserbasierte a35 kann naht- und klaglos mit UTF-8
umgehen, also auch in Formularen.  Hier die schon länger vorhandene
Implementierung mit ein paar fremdschriftlichen Beispielen:

  http://www.allegro-c.de/db/demo/a35-pc.php

Versuchen Sie auch unter "Bearbeiten" das "Formular 0".
Diese Realisierung gilt es u.a. jetzt weiter auszubauen.

Und weil a35 hinsichtlich Funktionalität noch lange nicht ausgereizt
ist, kann dennoch mit einiger Zuversicht nach vorn geblickt werden,
zumal der bisherige Chefentwickler der C++-Kernprogramme für die Weiter-
Entwicklung von a35 gar nicht gebraucht wird. Obwohl der schon
noch da sein wird.

Und um jedweder Verunsicherung entgegenzuwirken:
Wem jetzt der Kopf schwirrt, kann auch, falls kein zwingender Bedarf
vorhanden ist für mehr fremde Zeichen als bisher, bei a99 mit der
jetzt üblichen OstWest-Codierung bleiben. Die Fremddaten von DNB und
GBV kommen zwar in Unicode an, werden aber nach OstWest gewandelt,
an dieser Stelle wird's weiterhin keine Probleme geben. Und V36 usw.
werden in dieser Hinsicht auch nicht anders funktionieren und mit
Ihren Daten im Jetztzustand unverändert funktionieren. Einen *Zwang*
zum Übergang auf Unicode intern wird's, anders gesagt, auch künftig
*nicht* geben. Und wenn Ihr Admin mal plötzlich eine exportierte
Tabelle oder sowas in Unicode will, naja, das geht ja schon lange. Oder
MARC-Output in UTF-8 für VuFind ...

Für den Moment sind wir empfänglich für und interessiert an
konstruktiven Anregungen und weiterführenden Fragen.
B.Eversberg