i18n oder localizer?
Eingetragen von Anonymous (0)am 21.02.2007 - 15:53 Uhr in
Hallo zusammen,
ich habe mich nun endlich zusammengerissen und angefangen eine Drupalsite testweise aufzusetzen. Bisher bietet Drupal 5 alles, was ich so brauche.
Nun überlege ich aber, wie ich den zukünftigen Content unserer Page multilingual mache. Es gibt hier wohl 2 Ansätze: i18n und localizer. Ersteres ist wohl - aufgrund seines Alters - eine Art "Standard". Ich habe mir bei beidem einmal angesehen, wie es aussieht mit der Installation. Wenn ich die Foreneinträge, die ich so finde, richtig deute, gibt es wohl bei i18n Probleme mit Aliases - dafür muss man nicht patchen...
Ich fasse nun erst einmal kurz zusammen was es können soll:
- Wichtige Module: Organic Groups, Views, Pathauto
- User sollten eigene Einträge übersetzen können, aber nicht fremde.
- Es sollte kein Zwang bestehen, alles zu übersetzen.
- Wenn man einen Eintrag in einer Gruppe übersetzt sollte er in der entsprechenden anderssprachigen Gruppe erscheinen.
Welches der beiden Module bietet mir das am ehesten? Was ist vielleicht noch zu beachten?
Eine andere Frage wäre noch: wenn Drupal 6 oder höher irgendwann mal im Core Übersetzungen unterstützt, wie wahrscheinlich ist es dass ich vernünftig upgraden kann?
Vielleicht hat ja jemand Erfahrungen.
Gruß,
Lee
- Anmelden oder Registrieren um Kommentare zu schreiben
Ich kann Dir leider Deine
am 22.02.2007 - 11:01 Uhr
Ich kann Dir leider Deine Fragen nicht richtig beantworten, aber ich würde auf jeden Fall versuchen das i18n-Modul einzusetzen. Es gibt ernsthafte Bestrebungen i18n in den Core zu integrieren (wahrscheinlich berichte ich Dir damit nichts neues ;)), das wäre zumindest für mich ein sehr starkes Argument es damit auszuprobieren.
Siehe: http://groups.drupal.org/node/1967
--
bv - drupalcenter.de
localizer vs i18n
am 24.02.2007 - 01:21 Uhr
hallo drupalfreunde,
localizer erforder recht harte eingiffe in die core-files, was eigentlich vermieden werden sollte. mit i18n bin ich aber vom ansatz auch nicht sehr glücklich geworden, da man für jede sprache eine übersetzte node dupliziert und nicht nur den text ändert (struktur-redundanzen).
zzt. tendiere ich zu einer lösung, die i18n als grundlage nimmt, aber die node-übersetzung über "filter" realisiert. (bei interesse, dazu gerne mehr infos)
das klappt bis auf seitentitel, url-aliase und menü-einträge auch ganz gut. bei den erwähnten problemen kommt hinzu, dass ich das category-modul einsetze ( http://drupal.org/project/category und http://category.greenash.net.au/ ), was sich mit den strukturen von i18n etwas ins gehege kommt. hat jemand schon erfahrungen mit category-modul zusammen mit i18n gesammelt?
gruß,
uwe.
i18n mit Workflow
am 04.09.2007 - 14:23 Uhr
Ich bevorzuge i18n. Der Vorteil an diesem Modul ist, dass es einen einfachen Workflow für die Übersetzung enthält, was localizer nicht hat.
i18n - ganz klar
am 04.09.2007 - 14:33 Uhr
Wenn Du mal ne Stunde Zeit hast, schau Dir mal den Vortrag Human language support von Gábor Hojtsy auf der FrOSCon an. Sehr interessant, vor allem auch was Drupal 6 und den Übersetzungsserver angeht.
Nodes vs. Filter
am 04.09.2007 - 18:16 Uhr
@heimstein: Die Übersetzung von Nodes ist Kern-Bestandteil in Drupal 6 in Form des 'Content translation' Moduls. Es gab verschiedene Diskussion, wie die Übersetzung am besten/effektivsten/... zu implementieren wäre. Im Ergebnis wird auch beim diesem Modul je ein Knoten pro Sprache angelegt. Insofern sei es jedem, der seine Seite irgendwann auf D6 aktualisieren will, empfohlen, diesen Ansatz auch für D5 zu wählen. Ansonsten bleibt man immer von einem Contrib-Modul abhängig.