Post by Juergen IlseWenn LANG einen Einfluà hat, dan gibt es offensichtlich ein Problem in der
Konfiguration der Lokale.
LANG ist ein (maanchmal wichtiger) Bestandteil der Konfiguration der locaale.
Die (IMHO GNUR-spezifische) Variable LANGUAGE haalte ich fuer ueberfluessig
wie ein Kropf, LANG haalte ich dagegen fuer durchaus sinnvoll.
Das ist ein komplettes Mißvertändnis.
LANGUAGE hat absolut nichts mit der Lokale zu tun, sondern ist ausschließlich
für das automatische Übersetzungamanagement mittels gettext(3) oder gettext(1)
als Erweiterung der Einstellungen durch LC_MESSAGES zuständig.
Diese Variable wurde vor 20 Jahren in Absprache von Sun und den GNU Leuten
eingeführt um eine alternative Übersetzung zu selektieren. Wenn man z.B.
Italiener ist und weiß, daß es auf dem System häufig keine italienischen
Übersetzungen gibt, aber Deutsch besser verstanden wird als Englisch, dann
kann man LANGUAGE z.B. auf "it:de" stellen und man bekommt italienische Texte
wenn eine italienische Übersetzung für das aktuelle Programm vorliegt, sonst
wird (falls vorhanden) Deutsch verwendet.
Aus der gettext(1) Man Page:
LANGUAGE is a list of locale names separated by a
colon (':') character. If LANGUAGE is
defined, each locale name is tried in the
specified order and if a GNU-compatible
message catalogue is found, the message is
returned. If a GNU-compatible message
catalogue is found but failed to find a
corresponding msgid, the msgid string is
returned. If LANGUAGE is not defined or if
a Solaris message catalogue is found or no
GNU-compatible message catalogue is found
in processing LANGUAGE, the pathname used
to locate the message catalogue is
dirname/locale/category/domainname.mo,
where dirname is the directory specified by
TEXTDOMAINDIR, locale is a locale name, and
category is LC_MESSAGES.
Ein Solaris message Katalog ist dabei ein .mo File, das den 1986-1988
auf SunOS eingeführtem gettext System entspricht. Da braucht man pro
Zeichensatzkodierungs-Variante ein spezielles angepaßtes .mo File.
Ein GNU-compatible message Katalog ist dabei ein .mo File, das folgende
Erweiterungen enthält:
- Eine Mime Header "Übersetzung" für den String "" erlaubt die
automatische Transkodierung zwischen unterschiedlichen
Zeichensätzen (z.B. ISO8859-1 und UTF-8).
- Erweiterungen, die eine automatische Behandlung der Mehrzahl-
Varianten ermöglichen.
Hier wird nur ein .mo File pro Sprache benötigt, da der Zeichensatz im .mo
File automatisch mittels iconv(3) in den aktuell verwendeten Zeichensatz
konvertiert wird.
Das gettext System wird übrigens Bestandteil des nächsten POSIX Standard
werden und cas aktuell standardisierte catgetx(3) ablösen.
Es zeigt nebenbei symptomatisch daß im GNU/Linux Umfeld sich niemand an
Standards hält, selbst wenn diese Standards (wie im Falle von gettext) selbst
(in diesem Fall gemeinsam mit Sun) aufgeschrieben wurden. Von dem gemeinsamen
Sun/GNU Standard für gettext hat Sun nämlich einen sauberen Subset
implementiert aber GNU etwas Anderes und wir kämpfen gerade dafür, daß diese
GNU Fehlimplementierungen repariert werden. Achja, vor einem Jahr habe ich
(gemeinsam mit einem Studenten vom Hasso Platter Institut) das xgettext(1) von
Solaris so erweitert, daß es den vollen Funktionsumfang hat und man damit auf
Solaris auf gxgettext(1) verzichten kann.
--
EMail:***@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/