[Allegro] Sprachcodes deutsch, offizielle ISO-Codeliste

Mi Mai 20 16:18:19 CEST 2015

Am 19.05.2015 um 13:30 schrieb Bernhard Eversberg:
> 
> Also, wer's kaum abwarten kann:
> 
>    X getfile spra.vw    in a99 eingeben.
> 
> Datei landet in HELP.
> 
> Diese ViewListe beruht auf
> 
> 
> https://wiki.dnb.de/download/attachments/51283696/sprachencodesDeutsch.pdf?version=1&modificationDate=1366991960000
> 
> 
> Ungekürzt und unverfälscht ISO 639-2/B.

So ungefaehr...

Also, nach den Hinweisen hier ist der Stand wie folgt:

* http://www.loc.gov/standards/iso639-2/
* http://www.loc.gov/standards/iso639-2/ascii_8bits.html
* http://www.loc.gov/standards/iso639-2/php/code_changes.php

Die offizielle ISO-639-2 Registry, Downloads in Textform,
Sprachen Englisch und Franzoesisch.

* http://id.loc.gov/vocabulary/iso639-2.html

ISO 639-2: Codes for the Representation of Names of Languages - Part 2: Alpha-3
Code for the Names of Languages

Mit Benennungen in Englisch, Franzoesisch und Deutsch, leider enthalten
die Dateien sowohl die b- als auch die t-Codes ohne jegliche Kennzeichnung...

Der Stand ist recht aktuell, einzig fuer den zuletzt hinzugekommenen Code
(November 2012)

zgh Standard Moroccan Tamazight

fehlt die Deutsche Bezeichnung. Umfang ist 506 Codepunkte, da es 20 Stellen
gibt, an denen sich die /B und /T-Codes unterscheiden, sind es insgesamt
also 486 Sprachen).

Diese Liste enthaelt auch den pauschalen Platzhalter qaa-qtz
"Frei fuer lokale Verwendung" (que ist Quetchua)

* http://www.loc.gov/marc/languages/langhome.html
* http://id.loc.gov/vocabulary/languages.html
MARC List for Languages

Eine Liste mit 484 Codes (ohne "qaa-qtz" und tgz), Label sind nur Englisch und
Deutsch, manche Diakritika in der Deutschen Benennung sind durch "?" ersetzt,
einige fehlen ganz.

"The codes in this list are equivalent to those of ISO 639-2 (Bibliographic)
codes and some codes from ISO 639-5, although the language name labels may
differ. They are linked to the equivalent codes in ISO 639-2 and ISO 639-5 and
the corresponding two-character codes in ISO 639-1. "

Kann ich so nicht bestaetigen - alle Formen der Liste, die ich besichtigt
habe stehen in Konkordanz zu ISO 639-2, Querverweise zu anderen ISO-639-
Standards habe ich nicht gefunden.

* Die von Ihnen gefundene Liste von 2009, mit "qaa-qtz" und ebenfalls ohne tgz.

PDF-Dokument mit Tabelle, Anscheinend mit besseren Umlauten und hoffentlich
Copy-&-Paste-faehig...

Verbindlichkeit haben im Zweifelsfall nicht irgendwelche Internationalen
Standards, an die sich der Rest der Welt halten mag, sondern die Festlegungen
fuer MARC21, denn was da nicht erlaubt ist, kann nicht transportiert werden
und ist daher in einem gewissen Sinn gar nicht existent.

 %--

Eine XSLT-Transformation, die aus der RDF/XML-Version der Codes eine
Tabelle macht, ist schnell geschrieben, leider ermoeglichen a99
oder acon ja keinen Zugriff auf die enstprechenden Systemobjekte,
die so eine Transformation durchfuehren koennten.

Insofern dann der Standardweg, janas als "Interface" zu XSLT zu
benutzen, das ist dann schon etwas umstaendlicher, da janas ja
keine Tablle braucht sondern eine HTML-Seite mit einem Button,
mit dem man die Kontrolle an a99 zurueckgeben kann. Und einem
Textarea-Feld, in das die Tabelle kommt.

Dass Zeilenvorschuebe aus dem Textarea den Weg nach a99 nicht
ueberleben, kannte ich schon, man muss also durch Javascript beim
Absenden dafuer sorgen, dass "interessante" Zeilenumbrueche
hinterher noch erkannt werden koennen, etwa indem man sie durch
"^J" ersetzt, dann kann man sie in a99 per flex durch ins _^~J_^J_
zurueckwandeln. Dadurch wird der Inhalt des Textareas allerdings
zu einer langen Zeile und ich musste feststellen, dass das schon
bei deutlich weniger als 4000 Zeichen einen Absturz von Janas
bedeutet, wenn man auf "submit" klickt...

Gewisse Zeilenumbrueche ueberleben allerdings, naemlich solche
vor "$" oder "#", janas "weiss" dann, dass da neue Kategorien oder
Variablen anfangen und die Umbrueche wichtig sind. Durch andere
Umsetzungen habe ich daher versucht, Kommandos zu generieren,
die mit kuerzeren Zeilen auskommen und a99-seitig dann zum
Gesamtinhalt rekombinierbar sind. Leider musste ich an dieser
Stelle feststellen, dass das bei einem Inhalt des Textareas von
deutlich unter 10.000 Zeichen zum Crash von janas fuehrt, wenn
man auf "submit" klickt.

Gluecklicherweise ist Janas nichts anderes als eine Form des
Internet-Explorers, also sicherheitstechnisch unterbelichtet,
insofern ist erlaubt, was anderswo verboten ist: Per JavaScript
kann man die Zwischenablage mit den erzeugten Daten impfen, a99
liest die dann aus, wenn die Kontrolle zurueckgegeben wird.
Unschoen ist allerdings, dass Janas die Rueckgabe als UTF-8
veranstaltet, eingekapselt in Set U2 ... Set U0", d.h. was
im Flex ankommt, ist definitiv im internen Zeichensatz der
Datenbank und genau das wird fuer die Weiterverarbeitung
auch benoetigt. Via Zwischenablage kommen die Daten CP-1252-
codiert an, dafuer haben wir keine Konversion in den internen
Zeichensat, Das "ascii"-Kommando ist da nur eine Naeherung.

Jedenfalls, unter

http://www.gymel.com/downloads/codes/

liegen nun zwei Dateien zum Experimentieren,

fetch-languages.xml   (funktioniert aus CORS-Gruenden in keinem
  Browser, nur in janas) *muss* ins html-Unterverzeichnis des
  Programmverzeichnisses (und *muss* die Extension .xml haben)

mksprvw.flx   ist die Flexdatei, die das ganze steuert und
  kann an die ueblichen Orte fuer Flexdateien gelegt werden.

Aufruf dann als

X mksprvw.flx

im Schreibfeld, es wird dann geschaut und darauf hingewiesen, ob
spra.vw womoeglich schon existiert, dann janas gestartet und
arbeiten gelassen, anschliessend die janas-Daten in eine
temporaere view-Datei geschrieben, die (zur Kontrolle und
zur Autoreparatur der Zeilenlaengen) noch einmal angezeigt
und zum Schluss noch einmal nachgefragt, ob das als spra.vw
im help-Unterverzeichnis "installiert" werden soll.

Die kurze Schleife im Flex, die die Daten zeilenweise in die
.vw-Datei schreibt, liesse sich uebrigens einfach erweitern,
um "persistente Variable" irgendwohin zu setzen: D.h.
in ein geeignetes Register einer geeigneten Indexdatei mit
geeignetem Praefix (das aus $2 von MARC?). Schwieriger ist
allerdings die Aufgabe, diesen Registerbereich vorher zu
saeubern, damit kein Mix aus neueren und veralten Codes
dort steht...

Im Prinzip ist das leicht anpassbar fuer andere Codes, z.B.
Geocodes, Funktionsbezeichnungen etc., leider gibt es m.W.
aber absolut keine Moeglichkeit, janas irgendwelche Parameter
auf den Weg zu geben. Und eine Seite, die *alle* denkbaren
Viewlisten auf einmal vorbereitet, damit der Benutzer sich
eine fuer die Uebernahme aussuchen kann, waere irgendwie
Viecherei... *Auslagern* von Teilen per include oder import
(so dass eine individuelle Mini-Datei klaert, was zu tun ist
und ansonsten die allgemeine Maschine laedt) ist eigentlich eine
der vielen Staerken von XSLT, mit Janas/IE und lokalen Dateien
gibt es nach meiner Erinnerung haeufiger Irritationen bei
relativen Pfadangaben, selbst ganz simplen die eigentlich auf
"gleiches Verzeichnis" hinauslaufen sollten. Hat jemand
Erfahrung mit lokal geladenem jQuery in Janas?

viele Gruesse
Thomas Berger

> Man braucht halt dauernd wieder andere seltene Sprachen beim
> Katalogisieren, und das Gedächtnis macht nicht immer mehr so
> mit - es sind 485 Stück.
> 
> In ein Formular einzubinden mit folgender Zeile:
> 
> #37 "Sprachcode"|Vspra
> 
> oder, wenn's z.B. Unterfeld #9xy$s sein soll:
> 
> $s-#9xy"Sprache"|Vspra
> 
> Und dann eben im Formular  Alt+i drücken.
> 
> Übrigens können wir Formulare aus ViewListen auch unter a35
> für Erfassungsformulare verfügbar machen. Dafür wurde eigens
> ein Trick entwickelt, wie man so eine Liste nur beim Start einmal
> zu laden braucht, und dann ist sie verfügbar für jedes Formular,
> wo sie benötigt wird. Gehört zur neuen "freeform"-Technik.
> 
> B.E.