Benjamin Niemann

locale in Python

Status Quo

Die locale beschreibt die sprach– und landesspezifische Formatierung von Datums–, Zahlen–, Währungsangaben und vieles mehr. Um softwaregenerierte Texte korrekt wiederzugeben, wird eine maschinenlesbare Beschreibung der verschiedenen locales benötigt, und eine API, die die verschiedenen Formatierungsfunktionen bereitstellt.

Das locale Modul der Python Standardbibliothek basiert auf der libc Implementierung mit all ihren Einschränkungen. Die Dokumentation spricht davon, daß man durch häufige Änderungen der locale Einstellungen auf manchen Plattformen sogar coredumps hervorrufen kann.

Das größte Manko ist jedoch die Tatsache, daß die locale Einstellungen prozessweit festgelegt werden. In multi–threaded Anwendungen, bei denen verschiedene Threads unterschiedliche locales verwenden wollen, kommen sich diese unweigerlich in die Quere. Für mehrsprachige Webseiten, die unter mod_python laufen, so wie diese hier, ist das ein ziemlich tödliches Argument gegen die Verwendung von locale.

Wenn man also Zahlen– und Datumsangabe sprachspezifisch formatieren will, muß man also andere Wege einschlagen. Bei meiner Recherche bin ich allerdings auf keine wirklich befriedigende Lösung gestoßen.

Common Locale Data Repository

Ein weitverbreiteter Standard scheint das Common Locale Data Repository (CLDR) Projekt des Unicode Consortium zu sein. Dabei handelt es sich um eine Sammlung von XML Dateien, die die verschiedenen locales beschreiben — die aktuelle Version 1.4 umfasst 121 Sprachen und 142 Regionen, die kombiniert 360 locales beschreiben.

Viele bekannte Projekt verwenden die CLDR Dateien als Basis für ihre Lokalisierung, so zum Beispiel auch Open Office.

Es wäre also schön, wenn es eine Unterstützung für CLDR in Python gäbe.

International Components for Unicode

Eine bekannte Bibliothek, die — basierend auf den CLDR Daten – eine API zur Lokalisierung zur Verfügung stellt, ist das IBM Projekt International Components for Unicode (ICU). ICU ist für C, C++ und Java verfügbar.

Für ICU gibt es inzwischen Python-Bindungs: das PyICU Projekt der OSA Foundation.

Da es sich hierbei um einen Wrapper um die C++–Bibliothek handelt, muß sowohl ICU 3.4 und PyICU kompiliert werden — zumindest für letzteres ist es eher unwahrscheinlich, daß dieses als fertiges Paket für das eigene Betriebssystem vorhanden ist, und auch ICU gibt es für mein Debian (SID) nur in der Version 2.1. Der damit verbundenen Administrationsaufwand schreckt mich eher ab. Außerdem beabsichtige ich Verwendung in einem Web-Framework, daß (falls ich es mal unter die Massen werfen sollte) auch auf Shared Hosts laufen sollte, auf denen man eben nicht eben mal etwas kompilieren kann.

zope.i18n.locales

Eine Alternative ist das zope.i18n.locales Paket. Dabei handelt es sich um eine reine Python Implementierung, die allerdings schon etwas in die Jahre gekommen ist — die Daten basieren noch auf ICU V1.8.1.

Das Paket hat als Komponente des Zope Frameworks außerdem auch einige Abhängigkeiten auf andere Zope Pakete.

Utopie

Ideal wäre für mich eine reine Python Implementierung, die die aktuellen CLDR Daten verwendet und ohne Abhängigkeiten auf weitere Pakete auskommt.

Es käme auf einen Versuch darauf an, ob man zope.i18n.locales von seinen Abhängigkeiten befreien kann, um so eine halbwegs kompakte standalone Variante zu bekommen. Anschließend wäre es zu testen, ob es auch noch die aktuellen CLDR Daten verarbeiten kann, oder ob es gegebenenfalls erweitert werden muß.

Wenn ich nichts besseres zu tun hätte, würde mich so ein Projekt durchaus reizen.