Virtual OS/2 International Consumer Education
VOICE Homepage: http://de.os2voice.org 		Dezember 2001

[Inhaltsverzeichnis]
[Vorherige Seite] [Nächste Seite]
[Artikelverzeichnis]

editor@os2voice.org

Mehrsprachige Webseiten mit dem Apache Webserver

Von Christian Langanke © Dezember 2001

Inhaltsverzeichnis:



Einleitung
Nachdem ich bereits seit 1990 OS/2 benutze und verschiedene freie OS/2 Programme entwickelt habe, meinte ich vor ein paar Jahren, es wäre nett, eine eigene Heimseite einzurichten, auf der ich sowohl meine Programme als auch etwas Dokumentation anbieten würde. So wie einige meiner größeren Programme sollte auch die Webseiten mindestens zwei Sprachen unterstützen, und zwar natürlich deutsch als meine Muttersprache als auch englisch, um die meisten OS/2 Benutzer zu erreichen, die nicht deutsch sprechen. Bis vor einigen Wochen verwendeten meine Webseiten HTML-Verweise (hyperlinks), um zwischen den beiden Sprachen zu unterscheiden, was nichts anderes bedeutet, als dass ich die Information zur Auswahl der Sprachen in den Dateinamen und Verzeichnisnamen der HTML-Verweise hart kodierte.

Nach und nach kam ich immer öfter mit dem Apache Webserver in Berührung und lernte eine Technik namens MultiViews kennen, die es überflüssig macht, die Sprachinformationen im HTML-Quellkode zu kodieren. MultiViews sind eine Implementation der sogenannten content negotiation, wie sie in der HTTP/1.1 Spezification als auch in einigen RFCs definiert werden. Das bedeutet, dass der Server und der Browser jeweils aushandeln, welches die beste vom Server zurückzuliefernde Variante eines angeforderten Dokuments ist, wenn mehrere Varianten verfügbar sind.

MultiViews sind dafür ausgelegt, nicht nur zwischen Sprachen zu unterscheiden, sondern auch zwischen anderen Inhaltstypen (wie z.B. HTML, reiner Text und PostScript), aber die Unterstützung für die automatische Sprachauswahl ist wahrscheinlich die am meisten verwendete Anwendung dieser Funktion, und nur diese wird hier behandelt. Als ich herausfand, dass mein Provider ebenfalls den Apache verwendet, begann ich zu testen, wie MultiViews funktionieren, und stellte meine Webseite sehr schnell darauf um. Mit diesem Artikel möchte ich meine Erfahrungen mit Ihnen teilen.


Brauche ich wirklich Apache dafür?
Der Apache Webserver ist nicht der einzige Webserver, der MultiViews oder die sogenannte content negotiation beherrscht. Andere Server wiederum, die das noch nicht beherrschen, sind eventuell erweiterbar, um eine ähnliche Funktion zu unterstützen. So habe ich zum Beispiel kürzlich eine Filter-Erweiterung für den freien GoServe Webserver aus dem IBM Employee Written Software Program erstellt. Mit dieser Erweiterung unterstützt GoServe zumindest den Teil der content negotiation, der die Sprachauswahl betrifft.

Dieser Artikel behandelt allerdings ausschliesslich die Verwendung von Apache. Um Apache MultiViews auf Ihrer Webseite verwenden zu können, benötigen Sie entweder einen Provider, der Apache verwendet, oder eine eigene Maschine, auf der ein Apache läuft. Ausserdem beschäftigt sich dieser Artikel nur nit dem ersten dieser beiden Fälle, er erklärt im Detail, wie Sie MultiViews auf dem Server Ihres Providers benutzen, und was Sie Ihren Provider fragen müssen, wenn diese Funktion noch nicht auf seinem Webserver aktiviert ist. Mit dieser Information sollte es auch kein Problem für einen fortgeschrittenen Apache-Anwender sein, den eigenen Server zu konfigurieren.


Welchen Webserver benutzt Ihr Provider?
Zunächst mal ist es sehr wahrscheinlich, dass Ihr Provider heutzutage Apache Webserver verwendet, meistens auf BSD oder Linux. Wenn Sie nicht wissen, wie Sie feststellen können, welchen Webserver Ihr Provider benutzt, können Sie einen recht einfachen Trick verwenden: geben Sie eine ungültige URL von diesem Webserver ein (fügen Sie einfach irgendein ein Zeichen an eine gültige URL an). Der Webserver wird sich natürlich beschweren, dass die angegebene Datei nicht gefunden werden kann, und diese Meldung enthält meistens den Namen des verwendeten Webservers.

Übrigens ist Apache in seltenen Fällen so konfiguriert, daß er eine veränderte Fehlermeldung anzeigt, meistens, um Fehlermeldungen in verschiedenen Sprachen anzuzeigen - dann verwendet der Administrator Ihres Servers exakt die Technik, die in diesem Artikel besprochen wird. Wenn diese Meldung nicht den verwendeten Webserver erwähnt, müssen Sie dem Administrator Ihres Providers eine E-Mail schicken, um einfach nachzufragen.

Als alternative Methode bietet sich an, die Website http://uptime.netcraft.com/up/graph/ zu besuchen und dort die zu untersuchende URL einzugeben. Anschließend werden der Server und das Betriebssystem angezeigt.

Sollte Ihr Provider den Apache Server nicht verwenden, und Sie möchten dennoch keine konventionellen HTML-Verweise verwenden, um zwischen mehreren Sprachen zu unterscheiden, können Sie noch andere Methoden zur automatischen Sprachauswahl von der Serverseite aus verwenden. Sie basieren auf verschiedenen Mechanismen wie z.B. CGI und PHP, die hier aber nicht weiter angesprochen werden.


Was Apache MultiViews für Sie tun können - aus der Sicht eines Benutzers
Kennen Sie mehrsprachige Webseiten, auf denen Sie zunächst auf einer Einstiegsseite landen, wo Sie auf eine Flagge klicken müssen, um Ihre bevorzugte Sprache angezeigt zu bekommen? Nun, wenn ich das immer tun muss, wenn ich diese Seiten besuche, ärgert mich das jedesmal, und ich denke immer für mich "hey, kann diese Seite sich nicht merken, welche Sprache ich bevorzuge?".

Mit Webseiten, die auf einem Apache laufen und MultiViews benuzten, ist das nicht länger ein Thema. Alles, was Sie als Benutzer tun müssen, um die Vorteile von MultiViews nutzen zu können, ist meistens - einfach einen Webbrowser in Ihrer Muttersprache zu installieren. Aber wie funktioniert das?

Haben Sie schonmal den Auswahldialog für Sprachen in den Einstellungen Ihres Webbrowsers bemerkt und vielleicht gedacht "na, für was wird das wohl gut sein?" Sie haben es vielleicht bereits erraten, genau, dies dient dazu, Ihrem Webbrowser mitzuteilen, welche Sprache bzw. welche Liste von Sprachen Sie bevorzugt von Webservern erhalten möchten. Normalerweise brauchen Sie diese Liste noch nicht einmal zu verändern, denn der Webbrowser trägt in der Regel seine Sprache bereits bei der Installation mit ein. Wenn Sie also einen Webbrowser in Ihrer Muttersprache installieren, so ist das für den Browser automatisch auch Ihre bevorzugte Sprache.

Ihre Liste von bevorzugten Sprachen wird nun mit jeder Anforderung an einen Webserver geschickt. Die schlechte Nachricht ist: die meisten Server und/oder die darauf implementierten Webseiten ignorieren diese Liste. Die gute Nachricht ist: Webseiten, die die MultiViews-Funktion von Apache nutzen, werten Ihre Liste aus und reagieren entsprechend: ist die angeforderte Seite in einer Ihrer bevorzugten Sprachen vorhanden, wird die Seite in der ersten bevorzugten Sprache geliefert. Wenn nicht, wird die Seite in der Standardsprache zurückgeliefert (meistens englisch).

Im Ergebnis werden Sie vielleicht noch nicht einmal bemerken, dass eine bestimmte Webseite mehrere Sprachen unterstützt, stattdessen wird Ihnen genau die Sprache angezeigt, die Ihren Bedürfnissen am besten entspricht. Kein Klicken auf Flaggen mehr, keine Suche mehr nach Verweisen, um Ihre bevorzugte Sprache anzeigen zu lassen, einfach auf die Webseite gehen und mit Lesen beginnen ...

Der Rest dieses Artikels beschäftigt sich mit der Implementation dieser netten Funktion auf der Seite des Servers. Wenn Sie nur ein Benutzer sind und/oder sich nicht mit der Erstellung von mehrsprachigen Webseiten beschäftigen möchten, sind Sie soweit fertig und werden sich vielleicht einfach nur über jede Webseite freuen, die Sie mit MultiViews gut unterstützt. Wenn Sie mehrsprachige Webseiten haben oder weiter interessiert sind, folgt nun die ganze Geschichte.


Was Apache MultiViews für Sie tun können - aus der Sicht eines Webmasters
MultiViews helfen auch einem Webmaster sehr viel weiter. Die meisten Techniken, die bislang zur Mehrsprachenunterstützung verwendet werden, sind zum Beispiel: Alle diese Techniken benötigen in einer Weise Sprachenbezeichner, die in Ihrem HTML-Quellkode hart kodiert sind oder als zusätzliche Parameter an Scripts übergeben werden (obwohl eine dynamische Script-Methode weitaus besser ist als hart kodierte Sprachinformationen).

Wenn Sie stattdessen MultiViews verwenden, ist das Management von Inhalten in verschiedenen Sprachen komplett transparent für den HTML-Quellkode, da der Server die ganze notwendige Arbeit leistet, die zur Unterscheidung von Sprachinhalten notwendig ist. Und so funktioniert es...


MultiViews in Kürze
Wie mit jeder anderen Technik auch, müssen Inhalte verschiedener Sprachen in verschiedenen Dateien vorgehalten werden, eine Datei für jede Sprache. Der Trick ist nun, daß Sprachenbezeichner nicht in Dateinamen oder Verzeichnisnamen eingebettet werden, sondern stattdessen als zusätzliche Erweiterung an die Namen der Dateien angehängt werden, die die Webseiten enthalten.

Der große Unterschied zu den anderen Techniken ist, das nicht der Browser zwischen Dateien mit verschiedenen Sprachinhalten unterscheidet, indem er Verweise in Ihrem HTML-Quellkode auswertet. Stattdessen prüft der Server anhand der zusätzlichen Erweiterung des Dateinamens, um verschiedene Sprachen zu unterscheiden. Darüber hinaus ist diese Methode total transparent für den Webbrowser, da die Sprachenbezeichner gar nicht erst an den Browser gesendet werden. Dies resultiert in einem angenehmen Nebeneffekt: Sie können innerhalb Ihrer Webseiten Verweise erstellen, ohne in diesen Verweisen die Sprachenbezeichner nennen zu müssen. Damit sehen die Verweise für jede Sprache gleich aus, dies vermeidet natürlich Fehler bei der Übersetzung.

Das oben gennante hört sich zunächst an, als könne man einfach jede Erweiterung an Dateinamen anhängen, aber das stimmt nicht - Apache unterstützt ausschliesslich bekannte oder zusätzlich konfigurierte Mime-Typen oder Sprachenbezeichner.

Im nun folgenden Beispiel verwenden wir en als den Bezeichner für die englische Sprache und de als Bezeichner für die deutsche Sprache, wie sie im RFC 1766 definiert sind. Weitere Sprachenbezeichner können Sie im Auswahldialog für Sprachen in den Einstellungen Ihres Webbrowsers einsehen.

Um die Erklärung zu vereinfachen, gehen wir das Konzept anhand einer einzelnen Datei mit dem Namen index.html durch. Um die englische und deutsche Sprache zu unterstützen, würden Sie normalerweise Dateien wie die folgenden auf Ihrem Webspace haben:

oder Das bedeutet, dass Sie die Sprachenbezeichner in den Verweisen Ihrer Dateien hart kodiert müssen. Wenn Sie Ihre Webseite in eine weitere Sprache übersetzen, müssen Sie diese Verweise auf Ihre eigenen Seiten entsprechend an die neue Sprache anpassen, sonst erhalten Sie Verweise auf die falsche Sprache.

Stellen Sie nun mit den folgenden Dateien auf MultiLinks um, hierbei soll die englische Sprache die Standardsprache sein:

Hinweis:

Der Zweck der ersten beiden Dateien ist offensichtlich, wofür wird aber die dritte Datei benötigt? Diese wird von Apache zurückgeliefert, wenn der Benutzer weder die englische noch die deutsche Sprache als bevorzugt eingestellt hat, also keine der unterstützten Sprachen, aber mindestens eine andere Sprache - hier verweigert Apache leider eine sinnvolle Zusammenarbeit. Um nun eine Datei mit einer Standardvariante anbieten zu können, dürfen wir, wie bereits erwähnt, nicht den Namen index.html verwenden, aber aus offensichtlichen Gründen auch keinen anderen Sprachenbezeichner als zusätzliche Erweiterung des Dateinamens anhängen. Stattdessen dürfen wir hierfür nur eine gültige MIME-Typenerweiterungen verwenden, die den Dateiinhalt richtig beschreibt, und logischerweise kommt in diesem Beispiel nur erneut die Erweiterung .html  in Frage. Das gleiche Schema trifft zum Beispiel auch auf PHP-Dateien zu, in diesem Beispiel würde der Name der Standardvariante index.php.php lauten.

Auf Ihrem eigenen Unix-Server werden Sie wahrscheinlich einen symbolischen Verweis im Dateisystem verwenden, um über den Namen index.html.html auf die Datei index.html.en zugreifen zu lassen, damit man die englische Version nicht zweimal vorhalten muss. Auf einem OS/2-System, oder wenn Sie keinen telnet-Zugriff auf Ihren Unix-basierenden Server haben, nüssen Sie auf einfache Kopien für die Standardvariante zurückgreifen oder sererseitige includes verwenden, beides verschwendet leider mehr oder weniger Festplattenplatz.

Aber alles in allem: ist das nicht einfach?


Sind MultiViews bereits auf dem Server Ihres Providers verfügbar?
Der Apache Server wird meistens bereits mit Konfigurationsdateien ausgeliefert, in denen die Option MultiViews angegeben ist. Daher ist es sehr wahrscheinlich, dass auch der Server Ihres Providers für die Unterstützung von MultiViews konfiguriert ist und Sie sich gar nicht erst mit den Konfigurationseinstellungen des Apache befassen müssen.

Um herauszufinden, ob dies der Fall ist, laden Sie einfach Dateien entsprechend dem oben genannten Beispiel auf Ihren Webspace und fordern Sie index.html in Ihrem Webbrowser an (ohne Anhängen des Sprachenbezeichners an den Dateinamen!). Spielen Sie dann ein wenig mit der Sprachauswahl in den Einstellungen Ihres Browsers und laden Sie das Dokument nach jeder Änderung erneut:

Wenn MultiViews nun funktionieren, seien Sie zufrieden - Sie können nun die nächsten zwei Abschnitte überspringen, die beschreiben, was zu tun ist, wenn es nicht funktioniert hat.


Konfigurieren Sie Ihren Webspace für MultiViews
Also funktionierte das obige Beispiel nicht auf Ihrem Server? An dieser Stelle sieht es so aus, als würde der Aministrator Ihres Providers die Verwendung von MultiViews in der Hauptkonfiguration von Apache nicht erlauben. Da gängige Beispielkonfigurationen diese Option aber enthalten, hat er sie wahrscheinlich entfernt (die Frage ist, ob mehr aus Absicht oder mehr aus Versehen).

In dieser Situation bleibt Ihnen eine weitere Möglichkeit: Sie können Apaches Verhalten bezüglich der Dateien in Ihrem eigenen Webspace selbst beeinflussen, vorausgesetzt, der Aministrator hat dies in der Hauptkonfiguration von Apache erlaubt. Dies tun Sie, indem Sie eine zusätzliche Daten namens .htaccess  erstellen und in Ihren Webspace hochladen. Sie können diese Datei in jedem Verzeichnis haben, da aber Einstellungen auf Unterverzeichnisse vererbt werden, reicht in der Regel eine .htaccess  Datei im Hauptverzeichnis aus. Eine gängige Ausnahme von dieser Regel stellen .htaccess  Dateien dar, die den Zugriff auf ein bestimmtes Unterverzeichnis beschränken soll, diese Datei steht dann nur in diesem Unterverzeichnis. Beachten Sie, dass der Wert einer Direktive in der .htaccess  eines Unterverzeichnisses den Wert der .htaccess  Datei im übergeordneten Verzeichnis überschreibt, und so weiter.

Die .htaccess  Datei kann eine Menge verschiedener Direktiven enthalten. Um die wichtigsten Anwendungsfälle zu nennen, können Sie Apache zum Beispiel wie folgt konfigurieren:

Versuchen Sie nun, ob eine .htaccess   Datei die MultiViews für Sie aktivieren kann. Hierfür ist eine Zeile mit der Direktive Options und mindestens dem Parameter MultiViews erforderlich, etwa so: Options MultiViews Wenn Sie ausserdem weitere Optionen angeben möchten, müssen Sie diese alle in einer Zeile angeben, wie in den folgenden Beispielen: Options MultiViews <andere_option> <andere_option> Options <andere_option> MultiViews <andere_option> Laden Sie nun eine Datei mit dem Namen .htaccess  mit einer Optionszeile auf Ihren Server in das Verzeichnis, in dem die Dateien des obigen Beispiels liegen.

WICHTIG: Erstellen oder verändern Sie die .htaccess  Datei auf Ihrem lokalen System nicht mit einem Editor, der ein Dateiendekennzeichen (Ascii Kode 26) an die Datei anhängt, wie das zum Beispiel der Tiny Editor (TEDIT.EXE) und der Systemeditor (E.EXE) machen. Apache wird eine solche Datei ignorieren, auch wenn sie im Textmodus (ASCII) hochgeladen wurde!

Testen Sie nun MultiViews, indem Sie wieder auf index.html aus dem obigen Beispiel zugreifen. Das folgende kann nun passieren:

  1. Apache lädt die Sprachenvarianten korrekt
    Bingo! Sie haben es geschafft!

  2. Apache beschwert sich über einen Konfigurationsfehler
    Dies bedeutet, dass der Administrator Ihnen nicht die Verwendung eigener .htaccess  Dateien gestattet. Löschen Sie die .htaccess  wieder aus Ihrem Webspace heraus und lesen Sie im nächsten Abschnitt weiter.

  3. Apache lädt die Sprachenvarianten nicht, sondern meldet lediglich, dass die Datei index.html nicht gefunden werden konnte
    Dies bedeutet, dass der Administrator den Standardnamen .htaccess  auf einen anderen Wert geändert hat. In diesem Fall müssen Sie Ihn nach dem neuen Namen fragen.


Der Provider erlaubt keine MultiViews, was kann ich tun?
Wenn Sie herausfinden, dass der Administrator Ihres Providers den Apache so konfiguriert hat, dass er weder generell MutliViews erlaubt noch Ihnen erlaubt, eigene .htaccess  Konfigurationsdateien zu verwenden, möchten Sie ihm vielleicht ein E-Mail senden, in dem Sie ihm Ihre Absicht erläutern und ihn nett bitten, eine der genannten Methoden zu erlauben.

Wenn er einwilligt, prima! Wenn nicht, kann ich mir nur zwei Gründe vorstellen, warum er dies erst einmal ablehnt:

  1. er ist sich nicht sicher, ob dies nicht ein Sicherheitsrisiko ist, weil er diese Funktion vielleicht nicht kennt. Sie können ihm ruhigen Gewissens versichern, dass dies nicht der Fall ist. Verweisen Sie ihn hierzu auf die Apache Dokumentation über content negotiation, welche die MultiViews Funktion im Detail beschreibt.

  2. er könnte denken, dass dies die Performance auf dem Server beeinflusst, wie dies in der Apache Dokumentation über content negotiation angedeutet wird. Versichern Sie ihm, dass Sie nur wenige Dateien in einem Unterverzeichnis haben werden, sodass der Webserver nicht viel Zeit benötigen wird, um nach Sprachvarianten zu suchen - nur eine sehr grosse Anzahl von Dateien in einem Verzeichnis würde Apache deutlich verlangsamen, und zwar nur beim Zugriff über MultiViews auf dieses Verzeichnis. Dieser Punkt wird vielleicht klarer, wenn Sie in der Dokumentation über die Funktionsweise der MultiViews lesen.

Hinweis:


Mehrsprachige Webseiten auf MultiViews umstellen
Nun da MultiViews auf Ihrem Server funktionieren, haben Sie vielleicht bereits mehrsprachige Webseiten, die HTML-Verweise mit hart kodierten Sprachinformationen enthalten. Wenn dies der Fall ist, bedeutet die Unstellung auf MultiViews zunächst mal nur zusätzlichen Aufwand, bevor Sie bei zukünftigen Umstellungen und Erweiterungen davon profitieren können und Ihre Benutzer besser unterstützt werden.

Die Methode der Umstellung hängt nun davon ab, wie Sie die Sprachinformationen bislang in Datei- und Verzeichnisnamen eingebettet haben:

Eine Möglichkeit steht Ihnen ausserdem noch offen, wenn Sie bereits mehrsprachige Webseiten haben und schnell auf MultiViews umstellen möchten: Sie ersetzen nur die Hauptindexdatei mit einer MultiViews-Version, verlinken aber von dort wie gehabt auf Ihre nicht umgestellten Webseiten.

Vorteile sind:

Nachteile sind:


Einsprachige Webseiten auf MultiViews umstellen
Wenn Ihre Webseiten gegenwärtig nur eine Sprache unterstützen, und Sie nun eine weitere hinzufügen möchten, so ist dies mit MultiViews einfach zu organisieren und ausserdem erlaubt diese Methode eine sehr sanfte Umstellung. Da Sie noch keine Sprachenbezeichner in Datenamen oder Verzeichnisnamen eingebettet haben:

Sie werden wahrscheinlich immer komplette Verzeichnisse umstellen, aber das folgende Beispiel enthält umgestellte und nicht umgestellte Dateien in einem Verzeichnis, um klar zu machen, dass wirklich Datei für Datei umgestellt werden kann. Hier sind zwei Dateien bereits in zwei Sprachvarianten und in der Standardvariante verfügbar, während die beiden letzten Seiten nur in einer Sprache verfügbar sind. Das erlaubt wirklich eine sanfte Umstellung:

Noch einmal ist die Tatsache hervorzuheben, dass alle Verweise auf diese Dateien nicht geändert zu werden brauchen, da die MultiViews-Methode total transparent für den Webbrowser ist! Alle Verweise enden auf .html ohne den Sprachenbezeichner.


Fazit
Ich war wirklich gespannt darauf, die MultiViews-Funktion für meine eigenen Webseiten zu implementieren, seitdem ich davon gelesen hatte. Und ich war sehr froh, als ich herausfand, dass mein Provider mir zwar die Verwendung eigener .htaccess  Dateien nicht erlaubt, aber sein Server sowieso für die Unterstützung von MultiViews konfiguriert ist.

Aus der Sicht eines Webmasters: wenn immer ich zukünftig mehrsprachige Webseiten unterstützen muss, werde ich versuchen, alle anderen Methoden unbedingt zu vermeiden, denn MultiViews sind flexibel, intuitiv zu verwenden und weitaus weniger fehleranfällig als jede andere Methode, die ich kenne. Sie kann sehr einfach auch mit anderen Techniken wie PHP-Scripts kombiniert werden, in diesem Fall kann man dann auch auf einen Sprachenparameter verzichten.

Aus der Sicht eines Benutzers: ich schätze es sehr, dass MultiViews meine Spracheinstellungen verwenden, und dass es so einfach für Benutzer ist, in den Einstellungen des Browsers die Liste der bevorzugten Sprachen einzustellen (wenn das in seltenen Fällen überhaupt notwendig ist).

Nun da ich MultiViews kenne, die nahtlos und automatisch mehrere Sprachen in Webseiten integrieren können, würde ich Flaggensymbole und ähnliche Links nur noch verwenden, wenn ich keinen Apache Server zur Verfügung hätte. Ich glaube, dass die meisten Benutzer gar nicht daran interessiert sind, wieviele Sprachen ein Webauftritt unterstützt, solange automatisch die bevorzugte Sprache des Benutzers oder die beste Alternative dazu unterstützt wird. Meiner Meinung nach ist die beste Integration von mehreren Sprachen in Webseiten die, die man möglichst wenig oder überhaupt nicht bemerkt.

Quellenverzeichnis:

Christian Langankes Homepage: http://www.clanganke.de/
Filter für GoServe: http://www.clanganke.de/os2/archive/gosmv100.zip
Apache Dokumentation (content negotiation): http://httpd.apache.org/docs/content-negotiation.html
Apache Webserver Homepage: http://httpd.apache.org/
IBM GoServe Webserver Homepage: http://www2.hursley.ibm.com/goserve/

Christian Langanke benutzt OS/2 seit 10 Jahren OS/2 und beschäftigt sich mit Themen von Installation und Softwareverteilung über Netzwerkintegration von OS/2-Systemen und Anwendungen bis zu Intra- und Internet- sowie Hostverbindungen.
Auf seiner Heimseite stellt er verschiedene selbsterstellte OS/2-Programme frei zur Verfügung und ist Autor des neuen Team OS/2 Internet Assistent für OS/2 und eComStation. Er unterstützt OS/2 Netlabs bei der Realisierung von CVS-Diensten für OS/2-Internetprojekte wie z.B. Odin und Everblue durch die Netlabs Open Source Archive Client- und Administrator-Pakete.

[Artikelverzeichnis]
editor@os2voice.org
[Vorherige Seite] [Inhaltsverzeichnis] [Nächste Seite]
VOICE Homepage: http://de.os2voice.org