Internationalisierung der Datenbank [Django]

[klaus]

Beim Aufbau meiner Seite, die später mindestens zweisprachig werden soll (wenn ich freiwillige Übersetzer finde gerne auch mehr Sprachen), bin ich natürlich auf den Internationalization(I18N)-Mechanismus von Django gestoßen. Sieht alles soweit ganz nett und einfach aus, meine große Frage wäre nur, ob ich auch Inhalte einer Datenbank auf diese Weise übersetzen kann.

Ich habe also Models, die einen Namen und weitere Informationen (hauptsächlich Zahlen) sowie eine Beschreibung enthalten. Wenn jetzt nach den Namen gesucht wird, dann erhält man eine Liste aller gefundenen Einträge, in der ich nun die Beschreibung übersetzt haben möchte. Allerdings habe ich in der Dokumentation gelesen, dass beim Erstellen der Sprach-Datei die komplette Seite nach der Funktion _() abgesucht wird und alle gefundenen Strings dann gespeichert werden. Nun sind aber die Dantenbank-Einträge nur über die Suchfunktion erreichbar. Findet Django die Strings trotzdem, oder muss ich dann zum Schluss alles von Hand eingeben?

Wäre nett, wenn mir jemand den I18N-Mechanismus im Bezug auf Datenbanken etwas genauer erklären könnte, weil in der Dokumentation stand das nicht so genau drin.

[apollo13]

http://code.google.com/p/django-multilingual/

mfg apollo13

[Leonidas]

Wäre nett, wenn mir jemand den I18N-Mechanismus im Bezug auf Datenbanken etwas genauer erklären könnte, weil in der Dokumentation stand das nicht so genau drin.

Gibts nicht, das ist gettext-basiert.

Und weil mir das nicht so gefallen hat, habe ich erst ein bestehendes Projekt benutzt (TranslationService, von Nesh geschrieben) und habs dann noch mal selbst implementiert. django-multilingual wäre inzwischen auch eine Option. apollo13, hast du Erfahrung mit dem Ding? Ich habe ja eine Minimallösung, d.h. es werden bestimmte Tokens im Template zur Laufzeit übersetzt, die nur wenig mit meinem Datenbankmodellen zu tun haben. Vielleicht wäre es Wert, zu migrieren?

[apollo13]

@Leonidas:
Erfahrung habe ich keine damit, es schaut aber halbwegs vernünftig aus. Zumindest werden nicht wie im anderen Projekt (name grad entfallen), die Daten in die Db gepickelt

[Leonidas]

Erfahrung habe ich keine damit, es schaut aber halbwegs vernünftig aus. Zumindest werden nicht wie im anderen Projekt (name grad entfallen), die Daten in die Db gepickelt

Es scheint auch gut mainained zu sein. Aber vielleicht sollte ich wirklich erstmal auf den newforms-admin-Merge warten, der ja inzwischen (dem SVN-Commits und den Trac-Tags zu urteilen) in eine Phase gekommen ist, wo es nur noch eine Frage der Zeit ist, bis er da ist.

Hmm, das ist ja fast so wie die Situation bei magic-removal.

[apollo13]

Es scheint auch gut mainained zu sein. Aber vielleicht sollte ich wirklich erstmal auf den newforms-admin-Merge warten, der ja inzwischen (dem SVN-Commits und den Trac-Tags zu urteilen) in eine Phase gekommen ist, wo es nur noch eine Frage der Zeit ist, bis er da ist.

Auf den Merge warten? Ne dann wartest ewig *gg* Und warum auch, sie supporten eh den newforms-admin branch auch.

Und nein; ich glaube nicht, dass newforms-admin bald gemergt wird und qs-refactor muss ja auch noch in die 1.0er version rein...

[Leonidas]

Auf den Merge warten? Ne dann wartest ewig *gg* Und warum auch, sie supporten eh den newforms-admin branch auch.

Weil ich beim Wechsel auf nfa sowieso meine ganzen kruden Admin-Hacks neumachen muss, da kann ich dann auch noch die Translations angehen.

[klaus]

Danke für die Antworten. Dann werde ich wohl mal multilingual ausprobieren oder nach einer anderen Lösung suchen.

[jens]

Auch PyLucid soll mal mehrere Sprachen für die CMS Seiten unterstützten... Hier mal unsere Notizen dazu: http://pylucid.net:8080/pylucid/wiki/MultiLanguagePages
Forums Thread: http://pylucid.org/phpBB2/viewtopic.php?t=202

Neben django-multilingual gibt es noch http://code.google.com/p/transdb/

Ich denke aber wir werden kein externes django Projekt nutzten. Ich denke das macht mehr Arbeit...

EDIT: Siehe auch http://www.python-forum.de/topic-13921.html

[apollo13]

Neben django-multilingual gibt es noch http://code.google.com/p/transdb/

Nicht verwenden, das ist böse Spaß beiseite aber django-multilingual ist der bessere Ansatz.

Ich denke aber wir werden kein externes django Projekt nutzten. Ich denke das macht mehr Arbeit...

Ne macht es nicht, warum das Rad neu erfinden, wenn es es schon gibt...

[Leonidas]

Apropos, bin heute über django-rosetta gestoßen. Der Name kommt sicherlich von Canonicals Rosetta, welches eine UI für gettext-Sachen darstellt. Wenns das schon früher gegeben hätte, wäre ich vielleicht echt bei Djangos I18N geblieben.

[jens]

Danke für den Link. Sieht ganz nett aus Das wäre eines der Addons die man wohl sehr gut verwenden kann, ohne großartige neue Abhängigkeiten herzustellen...
Muß ich mir auf jedenfall mal für PyLucid näher ansehen!

[mitsuhiko]

Apropos, bin heute über django-rosetta gestoßen. Der Name kommt sicherlich von Canonicals Rosetta, welches eine UI für gettext-Sachen darstellt. Wenns das schon früher gegeben hätte, wäre ich vielleicht echt bei Djangos I18N geblieben.

oder auch nicht

[klaus]

Rosetta werde ich mir auch nochmal anschauen, allerdings habe ich die Übersetzung meiner Datenbanken bis jetzt über ManyToOne-Beziehungen erledigt. Ich mache einfach ein "internationales" model (hier Common) in dem Sachen drinstehen, die man nicht übersetzen braucht (Zahlen / Bilder / Videos) und dann für jede Sprache ein weiteres Model, das mit dem internationalen verknüpft ist (hier Specific). In dem steht dann der ganze Text drin. Das ganze sieht dann bei mir ungefähr so aus (falls es mal jemand brauchen sollte):

Code: Alles auswählen

from django.db import models

LANGUAGES = (
('de', 'Deutsch'),
('en', 'English'),
('it', 'Italiano'),
('es', 'Espanol'),
('fr', 'Francais'),
)

class Common(models.Model):
    zahlen = models.CharField(max_length=11)
    video = models.FilePathField(path="...")
    zahlen2 = models.CharField(max_length=50)

class Specific(models.Model):
    cmref = models.ForeignKey(Common)
    shortcut = models.CharField(max_length=11)
    lang = models.CharField(max_length=1, choices=LANGUAGES, radio_admin=True)
    name = models.CharField(max_length=90)
    categ = models.CharField(max_length=40)
    text = models.TextField()

Natürlich kann man dann noch Admin/Meta/__str__ -Klassen einfügen. Funktionieren tut's bis jetzt auf jedenfall mal ganz gut.

Allerdings habe ich noch eine Frage bezüglich der I18N, und zwar, wie man die Sprache, die der Benutzer eingestellt hat, auslesen kann. Wäre nett, wenn mir das jemand erklären könnte.

[Leonidas]

oder auch nicht

Ist mir schon klar, dass das letztendlich alles von dem Stein stammt. Canonical hatte den Namen ja auch nicht von ungefähr und dass der Tool-Song "Rosetta Stoned" heißt ist auch nicht ohne Grund