Deutsche Übersetzung zeigt immer noch englische Begriffe

Wenn mich nicht alles täuscht ist seit Drupal5 die Bezeichnung der Content-Typen Sache des Benutzers/Admins. Gehe also in der admin-section auf Inhaltstypen und editiere diese dort!

Vielen Dank. Das war's!

Diese Lösung finde ich eigenartig!

Wieso sollen die Inhaltstypen editiert werden, damit sie in deutsch erscheinen? Die Übersetzung ist nach dem Import von de.po für Page und Story bereits vorhanden, wird aber nicht angezeigt. Wenn ich das YAML Drupal Paket installiere, wird mir ein deutsches System installiert und Story und Page erscheinen bereits in deutsch.

Wie kommt dieser Unterschied zu stande? Gibt es keine andere Möglichkeit Page und Story in deutsch erscheinen zu lassen?

wie kommt das? und wie kann ich den "create content"-Button übersetzen?

Peter

... und zwar würde das das noch experimentelle Modul "i18ncontent.module" aka "i18n - content types" ermöglichen. Es hat jedoch einen Fehler, den ich wie unter...

http://drupal.org/node/135387#comment-276895

... wohl lösen konnte.

Bin gespannt, was da geht, bei mir "läuft's" nun mal so.

Viel Glück,
Moritz

Danke, stand eben vor derselben Frage und konnte sie damit lösen.

Das Problem mit der Nicht-Anzeige uebersetzter Textstrings ist folgendes:

Viele Module verwenden leider die t() Funktion nicht restlos bzw. konsequent. Soll heissen es gibt immer wieder Strings denen diese Funktion einfach fehlt.

Bsp.

print 'Create';

print t('Create');

Leider ist dies auch noch an vielen Stellen in Core-Modulen der Fall. Die Beispiele mit Page und Story belegen dies exemplarisch.

Um dies nun zu loesen muss man im PHP-Code der in Frage kommenden Module die entsprechenden Textstrings suchen und die vergessenen t() Funktion definieren.
Wenn man Glueck hat befindet sich solch ein String in einer Funktion die gethemed werden kann. Sehr oft aber ist dies nicht der Fall und man muss den Code dae Module aendern.
Erschwerend beim Einfuegen der t() Funktion zu Textstrings ist oft, das die Textstrings dynamisch ausgegeben werden. Also man findet zwar den String, die t() Funktion muss aber an einer anderen Stelle eingefuegt werden. In dieser Situation muss man sehr genau das gesamte Modul und dessen Funktion analysieren um die betreffende Stelle zu finden - nicht Jedermans Sache.

Die Frage mit den Textstrings und den vergessenen t() Funktionen wird beiner mit i18n zu internationalisierenden Website bedeutungsvoll. Man kann da nicht wie bei Page und Story einfach den deutschen Textstring eintragen. In diesem Falle haette man bei allen anderen Sprachversionen der Website diese deutschen Textstring vor der Nase.

Es ist schon erstaunlich das bei Drupal 5.2 in Core-Modulen immer noch nicht mit t() definierte Textstrings existieren.
Ich habe in der Vergangenheit schon mehrfach entsprechende Patches gepostet. Die werden einfach nicht beachtet.

Ein schoenes Beispiel fuer die vergessene t() Funktion ist das Modul Node Relativity. Zum Glueck hat dieses Modul sehr viele theme Funktionen. Somit kann man ueber Templates fuer die meisten Textstrings die t() Funktionen einfuegen. Aber leider befinden sich viele t() Funktionen nicht in theme Funktionen.

Man muss sich bei Betrachtung dieser Problematik auch vor Augen halten das Drupal-Module mit englischer Sprache entwickelt werden und viele Entwickler ganz offensichtlich ihre Module nicht in einer Multilanguage-Installation testen.

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Danke für die ausführliche Erklärung. Das Problem mit Änderungen an Core-Dateien ist natürlich im Updatefall, dass die ganzen schönen Änderungen dann gerade noch einmal gemacht werden dürfen. Gut zu wissen, dass das Problem doch eher trivial gelagert ist. Dieses Problem konnte ich durch die beschriebene Datenbankänderung umschiffen.

Aus meiner Sicht ist dies nicht trivial. Denn es geht ja oft um Core-Strings bzw. Strings die sich nichtin theme Funktionen befinden.

Nicht trivial ist das besonders vor dem Hintergund der in Kuerze nutzbaren Drupal Translation Server.

Da koennen die Drupal Anwender uebersetzen und uebersetzen. Es bleiben aber Strings uebrig - sozusagen. An dieser Stelle muss sich Drupal mehr Konsequenz auf die Fahnen schreiben. Erst recht wenn Drupal seit Kurzem "... world domination ..." propagiert.

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Ich gehe absolut konform mit dir. Trivial bezog sich nicht darauf, dass die Konsequenzen trivial sind, sondern eher darauf, dass die Lösung dessen eigentlich relativ leicht umzusetzen ist. Voraussetzung ist natürlich die von dir angesprochene Disziplin. Für Delphi (ok, andere Baustelle) gibt es aber auch Lösungen, um ebenfalls mit der gettext-Funktion Programme multilingual zu machen. So konnte man allen Text aus diversen Objekten auslesen lassen und nachträglich die auf die Ignoreliste setzen, die nicht übersetzt werden sollten. Ist nicht eine ähnliche Lösung für Drupal vorstellbar, sodass nicht mit t() markierte Texte damit markiert werden?

Ich habe jetzt in der PO Datei von Webform mit dem PO-Editor alle Umlaute ersetzt. Nach einem erneutem Import werden jedoch immer noch die alten fehlerhaften Übersetzungen angezeigt. Auch der Automatikimport hat nix gebracht. (Drupal5.8) Ein weiteres Problem ist das Modul Captcha, hier wird überhaupnix importiert, obwohl die PO-Datei vorhanden und auch komplett übersetzt ist.
Ich habe auch die gesamte PO-Datei aus Drupal exportiert, auch hier sind die Übersetungen alle eingetragen.

Ich habe keine Ahung wo hier das Problem liegt.

--------
Active-Media-Production
Individual Web Development and Design