Jacob hat mir die Berechtigungen für Branch-Commits und einen Branch für i18n-Sachen eingerichtet. Daher habe ich heute an den Ideen im Patch von Ticket 65 von nesh gearbeitet. Ich habe die meisten Sachen von Grund auf neu geschrieben, weil ich einige Dinge etwas anders haben wollte, und jetzt ist es zum Testen verfügbar.
Zuerst, wie Sie die i18n-Sachen mit Ihrem Django-Checkout verwenden können. Sie benötigen einen aktuellen svn trunk Checkout und gehen Sie zum Root Ihres Checkouts und führen Sie den folgenden Befehl aus:
svn switch http://code.djangoproject.com/svn/django/branches/i18n/
Danach sollten Sie einen Baum mit meinen Patches angewendet haben. Ich habe bisher nur sehr wenig übersetzt, um den Patch und die Änderungen so klein wie möglich zu halten, aber ich habe bereits eine deutsche Übersetzungsdatei mit Sachen für den Admin-Index und den isAlphaNumeric-Validator hinzugefügt. Ich denke, ich werde bald noch mehr Sachen zu den Übersetzungen hinzufügen.
Der Patch behandelt nur den Übersetzungsanteil - andere Dinge wie Datumsformatierung, Zahlenformatierung, Zeitzonenbehandlung sollten in verschiedene Patches gehen, um jeden von ihnen so klein wie möglich zu halten. Das Übersetzungsobjekt (das ist das Biest, das für die Umwandlung von Zeichenfolgen in ihre neue Form verantwortlich ist) wird auf Anfrage erstellt. Dies gibt uns die Möglichkeit, verschiedene Stellen zu betrachten, die bei der Entscheidung helfen können, welche Sprache dem Benutzer präsentiert werden soll. Der Code beginnt damit, in der Sitzung nach einer django_language-Variablen zu suchen. Wenn diese nicht gefunden wird, sucht er in den Cookies nach einem django_language-Cookie. Wenn auch das nicht gefunden wird, gräbt er in den HTTP-Headern. Es sucht nach dem Http-accept-language-Header und teilt diesen nach Sprachen auf und sortiert sie nach Vorliebe. Es wird die erste Sprache (sortiert nach Vorliebe, höchste Vorlieben zuerst) verwenden, die in dem django-Nachrichtenfile-Repository gefunden wird. Wenn keine dieser Sprachen gefunden werden kann, wird es letztlich auf das Standardübersetzungsobjekt zurückgreifen, das durch die LANGUAGE_CODE-Einstellung in Ihrer Einstellungsdatei definiert ist. Nachrichten-Dateien können an drei verschiedenen Stellen gespeichert werden: Die django-Projekt-Nachrichten-Dateien werden im django.conf-Paket in einem Unterverzeichnis namens locale gespeichert. Dies ist ähnlich wie die admin_media- und admin-Vorlagenverzeichnisse. Das locale-Unterverzeichnis ist wie typisch bei der Speicherung von lokalen Daten strukturiert: ein Unterverzeichnis pro Sprache und ein LC_MESSAGES-Verzeichnis darin. Der Sprachbereich für django-Nachrichten-Dateien ist immer django. Der nächste Ort, an dem django nach Nachrichten-Dateien sucht, ist das Projekt - wenn Sie ein locale-Verzeichnis in Ihrem Projekt haben, können Sie dort zusätzliche Nachrichten-Dateien speichern. Der dritte Ort ist die Anwendung - Sie können ein locale-Verzeichnis neben Ihrem Anwendungs-Views-Verzeichnis haben. Alle locale-Verzeichnisse sind gleich strukturiert.
Ein Übersetzungsobjekt für eine bestimmte Sprache ist tatsächlich eine Verkettung von vier Übersetzungsobjekten: zuerst das Anwendungsübersetzungsobjekt. Dies wird auf das Projektübersetzungsobjekt zurückgreifen. Dieses wiederum wird auf das globale Übersetzungsobjekt zurückgreifen, das auf das Übersetzungsobjekt für die Standardsprache zurückgreifen wird. Auf diese Weise können höhere Ebenen Übersetzungen von niedrigeren Ebenen überschreiben und Anwendungen können ihre eigenen Übersetzungen bereitstellen.
Die Anwendung für die Übersetzungen wird tatsächlich durch Modulintrospektion entdeckt - es verwendet die View-Funktion, um auf eine URL zuzugreifen, um herauszufinden, welche Anwendung diese View-Funktion trägt, und verwendet diese, um nach lokalen Übersetzungen zu suchen. Es gibt zwei Tools, die zur Verwaltung von Übersetzungen bereitgestellt werden: make-messages.py und compile-messages.py. Beide Tools können entweder im Root des django svn-Baums oder im Projektverzeichnis oder im Anwendungsverzeichnis aufgerufen werden. make-messages.py wird das aktuelle Verzeichnis und alles darunter nach zu übersetzenden Zeichenfolgen durchsuchen und wird eine django.po-Datei im locale-Verzeichnis für die gegebene Sprache erstellen. compile-messages.py wird einfach alle .po-Dateien in .mo-Dateien umwandeln. Das Hinzufügen von Übersetzungen ist einfach. In Python-Code umgeben Sie einfach Zeichenfolgen (nur Zeichenfolgenkonstanten!) mit ('...') oder ("..."). Dadurch werden diese Zeichenfolgen für die Übersetzung markiert, sodass make-messages.py sie herausziehen und in die .po-Dateien schreiben kann. Und es wird die Zeichenfolge zur Laufzeit übersetzen, unter Verwendung des aktuellen Übersetzungsobjekts, das aus der Anfrage ermittelt wurde. In Vorlagen gibt es das Vorlagentag {% i18n ('....') %} - dieselbe Syntax wie mit Python-Code, nur müssen Sie es als Vorlagentag umschließen. Diese Zeichenfolgen werden ebenfalls aus den .html-Dateien in die .po-Datei gezogen. Das i18n-Tag unterstützt die Zeichenfolgeninterpolation aus dem Kontext: {% i18n ('blah %(blubb)s blubber') %} würde zunächst die Zeichenfolge übersetzen und dann die Kontextvariable blubb in das übersetzte Ergebnis interpolieren.
Ein Tipp: Wenn Sie Zeichenfolgen zum Übersetzen schreiben, verwenden Sie keine positional parameters für die Interpolation (die %s-Sachen), sondern verwenden Sie stattdessen benannte Parameter (%(blah)s). Auf diese Weise können Personen, die Übersetzungen erstellen, die Zeichenfolge neu anordnen, ohne Ihren Code zu brechen - einige Sprachen haben eine andere Reihenfolge als Englisch.
Die Verwendung der Übersetzungen ist ebenfalls einfach: Sie müssen nur Ihre Standardsprache in der LANGUAGE_CODE-Einstellung festlegen und django.middleware.locale.LocaleMiddleware zu Ihrer Middleware-Einstellung hinzufügen. Sie müssen es an die Spitze setzen - besonders im Admin sollte es vor dem AdminUserRequired Middleware kommen - aber es muss nach dem SessionMiddleware sein, wenn Sie dieses verwenden.
Das ist erst der Anfang, spielen Sie damit und sagen Sie mir, wenn etwas schief geht. Der beste Ort, um es zu sagen, ist im Ticket im django trac.
