Übersetzung von Modulen

[siegparr]

Hallo zusammen,

zunächst vielen Dank an HerrB (und Dodger77) für Ihre Unterstützung.

Ich fasse nun das Ergebnis zusammen:

Contenido-Modul-Übersetzung

1. Mehrsprachige Module sollten in Englisch als Originalsprache entwickelt werden, weil eine Verwendung von Umlauten oder anderen Sonderzeichen für die Originalsprache bisher (Version 4.6.8 bzw. 4.6.15) nicht vorgesehen ist.

2. Der Übersetzungsexport erfolgt in der Originalsprache (Einstellung rechts oben in der Drop-Down-Box) im Reiter Übersetzung. Der Export wird unten links im Import/Export-Bereich durchgeführt. Das erzeugt eine XML-Datei im folgenden Format (Beispiel):

Code: Alles auswählen

<?xml version="1.0" encoding="ISO-8859-1"?>
<module>
  <translation origin-language-id="1" origin-language-name="englisch">
    <string>
      <original>Could not connect to database %s.</original>
      <translation/>
    </string>
    <string>
      <original>This is a test.</original>
      <translation/>
    </string>
    <string>
      <original>Undefined error.</original>
      <translation/>
    </string>
    <string>
      <original>An error occurred. error number: %s, error text: %s</original>
      <translation/>
    </string>
  </translation>
</module>

[/color]
Nach dem Übersetzungsexport dürfen an den Originaltexten keine Änderungen mehr im PHP-Code oder in der XML-Datei erfolgen. Grund: Beim Übersetzungsimport wird nach dem genauen Wortlaut des Originals gesucht, und nur bei 100 % Übereinstimmung erfolgt der Import des übersetzten Textes.

3. Der Inhalt der XML-Datei in den <original>-Tags wird in die Zielsprache übersetzt und in die <translation>-Tags eingetragen. Das sieht dann ungefähr so aus:

Code: Alles auswählen

<?xml version="1.0" encoding="ISO-8859-1"?>
<module>
  <translation origin-language-id="1" origin-language-name="deutsch">
    <string>
      <original>Could not connect to database %s.</original>
      <translation>Konnte keine Verbindung aufbauen zur Datenbank %s.</translation>
    </string>
    <string>
      <original>This is a test.</original>
      <translation>Dies ist ein Test.</translation>
    </string>
    <string>
      <original>Undefined error.</original>
      <translation>Undefinierter Fehler.</translation>
    </string>
    <string>
      <original>An error occurred. error number: %s, error text: %s</original>
      <translation>Ein Fehler ist aufgetreten. Fehlernummer: %s, Fehlertext: %s</translation>
    </string>
  </translation>
</module>

4. Zur Kontrolle wird die so entstandene XML-Datei validiert. Dies kann z. B. einfach dadurch geschehen, daß man die Datei in einen XML-fähigen Browser lädt. Die XML-Datei muß korrigiert werden bis keine Fehler mehr angezeigt werden.

5. Der Übersetzungsimport erfolgt in der Zielsprache (im Beispiel Deutsch) ebenfalls im Reiter Übersetzung. Im Import/Export-Bereich über den Browse-Button die gewünschte XML-Datei auswählen und den grünen Haken anklicken. Als Ergebnis sollte die rechte Spalte die übersetzten Texte in der Zielsprache enthalten. Nicht vergessen zu speichern.

Hoffentlich habe ich nichts wichtiges vergessen und es hilft einigen.

[siegparr]

Hallo,

Ihr habt ein tolles Tool entwickelt. Vielen Dank!

Einige Bemerkungen möchte ich aber noch loswerden, die aber nur meine eigene Meinung widergeben:

1. zum XML
Ich finde es etwas verwirrend an zwei verschiedenen Stellen und für zwei verschiedene Zwecke ein Tag <translation> zu verwenden. Einmal wird es als Träger für die Attribute origin-language-id und origin-language-name verwendet. Der andere Zweck besteht darin die Übersetzung des Originaltextes in der Zielsprache aufzunehmen. Schwierig wird es, wenn man eine DTD oder ein Schema zur Validierung schreiben möchte, falls das überhaupt geht; für Übersetzungen in einem Übersetzungsbüro eigentlich eine unverzichtbare Notwendigkeit.

Beim Übersetzungsexport würde ich den <translation>-Tag innerhalb von string auch nicht <translation/> schreiben, sondern <translation></translation>. Vorteil: So kann die Übersetzung auch leicht mit einem normalen Editor eingefügt werden, ohne daß man die Tags selbst ändern muß; man braucht keinen XML-Editor, z. B. für kleinere Projekte und Module.

2. zur Originalsprache
Es stimmt, Englisch ist für ein Fallback, wenn also ein Text in einer Sprache nicht existiert, sicherlich die geeignete Sprache.

Andererseits wäre es mit durchgängiger utf-8-Unterstützung beim Übersetzungsexport und -import sicherlich auch nicht all zu schwierig jede Originalsprache zuzulassen.

Nicht immer weiß man zu Projektbeginn, daß eine Website irgendwann einmal mehrsprachig werden soll. Man entwickelt also in der entsprechenden Landessprache des Kunden. Erst vielleicht Monate oder Jahre später kommt dann der Wunsch nach Mehrsprachigkeit für die Website auf. Eine nachträgliche Änderung ist so, wie es momentan programmiert ist, nur mit hohem Entwicklungs- und Kostenaufwand möglich. Das ist schade, weil Contenido für solche Projekte möglicherweise ungeeignet ist.

Vielleicht könnt Ihr meine hoffentlich konstruktiven Anregungen in einem späteren Release berücksichtigen.

Das Forum ist übrigens ganz große Klasse. So schnelle und immer freundliche Hilfe kann man leider nicht überall antreffen. Herzlichen Dank.

[HerrB]

Deine wunderbare Ausführung werde ich mal nach Tips & Tricks übernehmen.

Man entwickelt also in der entsprechenden Landessprache des Kunden.

Wie formuliere ich das jetzt liebevoll... Man sollte von vornherein die Mehrsprachigkeit vorzusehen. Immer. Weil man nie weiß, was kommt und die Nacharbeit enorm ist.

Für die V4.4.x galt das noch nicht so sehr, da es dort mit echtem Aufwand verbunden war, mehrere Sprachen im Modul vorzusehen.

Da die Übersetzung in V4.6.x aber so wunderbar funktioniert, sollte man ab jetzt immer englische Meldungen bzw. Texte mit mi18n("Hi") verwenden (genauso, wie man bitte keine deutschen Variablenbezeichnungen verwendet... spätestens der spanische Entwickler, der spontan beim Projekt mitmacht, hat mit $sHauWechDieKacke doch so seine Probleme - er kann zwar auch kein englisch, aber lässt sich googeln oder leonen...).

Natürlich könnte man auch jede andere Sprache nehmen - aber in englisch kommt halt nur ASCII vor (so ein Zufall... ).

Noch eine Anmerkung zu:

Nach dem Übersetzungsexport dürfen an den Originaltexten keine Änderungen mehr im PHP-Code oder in der XML-Datei erfolgen. Grund: Beim Übersetzungsimport wird nach dem genauen Wortlaut des Originals gesucht, und nur bei 100 % Übereinstimmung erfolgt der Import des übersetzten Textes.

Die Texte dürfen geändert und der Code gespeichert werden. Natürlich wird dann der Übersetzungsstring nicht mehr gefunden und es muss ein neuer erstellt werden - man kann es aber auch schnell wieder zurückändern (wenn es einem auffällt).

Erst mit Aufruf des Reiters Übersetzung geht die - für den alten Code - hinterlegte Übersetzung verloren...

Gruß
HerrB

[siegparr]

Hallo,

möchte zu HerrBs Anmerkungen etwas bemerken:

Man sollte von vornherein die Mehrsprachigkeit vorsehen. Immer. Weil man nie weiß, was kommt und die Nacharbeit enorm ist.

Durchaus richtig. Aber das tut man ja mit der Verwendung von mi18n bereits.

... sollte man ab jetzt immer englische Meldungen bzw. Texte ... verwenden

Das heißt, wenn ich es recht verstehe, daß sich die Betriebsorganisation an das Tool anpassen muß. Sollte sich nicht vielmehr das Tool an die im Unternehmen sicherlich nicht ganz zu Unrecht eingespielten Prozesse anpassen lassen?

Es ist übrigens gar nicht so unüblich in Deutschland Deutsch als Originalsprache vorzusehen, schließlich spricht man in Deutschland Deutsch. Außerdem soll es Gegenden auf unserer Erde geben, in denen man mit Englisch wenig oder gar nichts anfangen kann; ein Fallback auf Englisch nutzt einem dort leider nichts, hm.

Erst mit Aufruf des Reiters Übersetzung geht die - für den alten Code - hinterlegte Übersetzung verloren...

... was wohl regelmäßig beim Import der XML-Datei der Fall sein dürfte. Oder habe ich das jetzt falsch verstanden?

Nichts für ungut ...

[HerrB]

Durchaus richtig. Aber das tut man ja mit der Verwendung von mi18n bereits.

Du möchtest mich nicht verstehen, oder? Code sollte nach Möglichkeit immer sprachneutral sein - man verwendet englisch, da es der kleinste gemeinsame Nenner ist und keine Sonderzeichen kennt.

... sollte man ab jetzt immer englische Meldungen bzw. Texte ... verwenden

Das heißt, wenn ich es recht verstehe, daß sich die Betriebsorganisation an das Tool anpassen muß. Sollte sich nicht vielmehr das Tool an die im Unternehmen sicherlich nicht ganz zu Unrecht eingespielten Prozesse anpassen lassen?

Und Du programmierst Module in ... deutschem PHP? Echt? str_replace heißt bei Dir text_ersetze? Weil Dein Unternehmen in Deutschland sitzt?

Aber mal im ernst, das eine hat mit dem anderen nichts zu tun. Du programmierst in englisch und nur für den Fall, dass eine Übersetzung nicht vorhanden ist, wird der englische Text angezeigt.

Es hat niemand behauptet, dass Du alle Meldungen in englisch ausgeben sollst, sondern ich habe Dir nur empfohlen, die Ausgangstexte englisch zu gestalten - damit Du eben in keine Probleme mit Sonderzeichen im Quellcode kommst.

Außerdem soll es Gegenden auf unserer Erde geben, in denen man mit Englisch wenig oder gar nichts anfangen kann; ein Fallback auf Englisch nutzt einem dort leider nichts, hm.

Das ist unsachlich, zumal das deutsche Fallback nur von Nutzern aus Deutschland, Österreich, Dänemark und einigen Regionen der Schweiz und Südafrikas verstanden wird - fast die gesamte Welt, oder?

Und man nimmt deswegen englisch, da es keine Sonderzeichen kennt und auf allen Computersystemen der Welt verarbeitet werden kann - for sure.

Erst mit Aufruf des Reiters Übersetzung geht die - für den alten Code - hinterlegte Übersetzung verloren...

... was wohl regelmäßig beim Import der XML-Datei der Fall sein dürfte. Oder habe ich das jetzt falsch verstanden?

Ja, es war auch mehr für andere Nutzer als Hinweis gedacht, die gerade am programmieren sind, sich vertippt haben und dies feststellen - solange man "Übersetzung" nicht aufruft, kann man es schnell wieder korrigieren.

Noch viel Erfolg.

Gruß
HerrB

[siegparr]

Hallo,

vielen Dank nochmals an das Forum, besonders an HerrB.

Und das hier wiederhole ich gerne:

Das Forum ist übrigens ganz große Klasse. So schnelle und immer freundliche Hilfe kann man leider nicht überall antreffen. Herzlichen Dank.

[siegparr]

Hallo zusammen,

habe noch einige Entdeckungen gemacht, die ich dem Forum nicht vorenthalten möchte:

Die Texte, die in einem Modul in die Funktion mi18n eingeschlossen sind - also übersetzt werden sollen - landen in der Contenido-Tabelle con_mod_translations, nachdem man das Modul ausgewählt und auf den Reiter Übersetzung geklickt hat. Die Texte in dieser Tabelle sind, wie es aussieht, url-encoded, um auch Sonderzeichen behandeln zu können.

Die Contenido-Tabelle con_mod_translations hat folgende Struktur (Felder):

Code: Alles auswählen

idmodtranslation  idmod  idlang  original  translation

wobei

idmodtranslation = Id des Datensatzes (Primärschlüssel)
idmod            = Id des Moduls (Fremdschlüssel aus Tabelle 'con_mod')
idlang           = Id der Sprache (Fremdschlüssel aus Tabelle 'con_lang')
original         = zu übersetzender Text in der Originalsprache
translation      = übersetzter Text in der Fremdsprache (siehe idlang)

Man könnte nun auf die Idee kommen, die Inhalte dieser Tabelle über eigene Export- und Importskripte auszulesen, zu decodieren, zu übersetzen (in die Spalte translation), wieder zu encodieren und in die Tabelle zurückzuschreiben (vorher Backup!). So könnte man die Einschränkung auf Englisch als einzige vorgesehene Originalsprache umgehen.

Dies ist aber nicht so einfach, weil Änderungen im Modul nicht richtig in der Tabelle con_mod_translation mitgeführt werden - auch wenn man wieder auf den Reiter Übersetzung klickt. Aus dem Modul entfernte Texte werden aus der Tabelle nicht gelöscht, zusätzliche Texte werden aber richtig hinzugefügt.

Es ist IMHO ein kleiner Bug, daß aus dem Modul entfernte Texte nicht aus der Tabelle con_mod_translation gelöscht werden, denn sie werden ja auch in der/den Fremdsprache(n) nicht mehr benötigt. Sie behindern die Implementierung eigener Übersetzungsmodule oder -plugins.

Oder habe ich da jetzt einen Denkfehler?

[HerrB]

nachdem man das Modul ausgewählt und auf den Reiter Übersetzung geklickt

...

So könnte man die Einschränkung auf Englisch als einzige vorgesehene Originalsprache umgehen.

*Seufz* Vielleicht ist in der kommenden Version dieses Problem auch behoben...

Dies ist aber nicht so einfach, weil Änderungen im Modul nicht richtig in der Tabelle con_mod_translation mitgeführt werden - auch wenn man wieder auf den Reiter Übersetzung klickt. Aus dem Modul entfernte Texte werden aus der Tabelle nicht gelöscht, zusätzliche Texte werden aber richtig hinzugefügt.

Es ist IMHO ein kleiner Bug, daß aus dem Modul entfernte Texte nicht aus der Tabelle con_mod_translation gelöscht werden, denn sie werden ja auch in der/den Fremdsprache(n) nicht mehr benötigt. Sie behindern die Implementierung eigener Übersetzungsmodule oder -plugins.

Oder habe ich da jetzt einen Denkfehler?

Kann ich nicht bestätigen - ändert man den Text in mi18n und klickt auf Übersetzung und ändert danach den Text in mi18n wieder zurück, kommt die alte Übersetzung nicht wieder. Ob das auch bei mehreren Sprachen so ist, habe ich nicht getestet.

Gruß
HerrB

[siegparr]

Hallo HerrB,

danke für den Test und die schnelle Antwort.

Wir reden, denke ich, wieder einmal aneinander vorbei:

... ändert man den Text in mi18n und klickt auf Übersetzung und ändert danach den Text in mi18n wieder zurück, kommt die alte Übersetzung nicht wieder.

Wohl ein Mißverständnis. Ich meinte, daß man im Modul aus irgendwelchen Gründen die Logik ändert, und daß dabei zu übersetzende Texte aus dem Modul entfernt (gelöscht) werden - jeweils zusammen mit der einschließenden Funktion mi18n. Andere Texte - mit neuen mi18n-Funktionen kommen hinzu. Die gelöschten Texte tauchen auch weiterhin in der Tabelle con_mod_translations auf, zusammen mit den neuen Texten.

Ich meinte keine Textersetzung, sondern komplett gelöschte und komplett neue Texte im Modul.

Hoffentlich habe ich das jetzt verständlicher ausgedrückt.

[Dodger77]

Wohl ein Mißverständnis. Ich meinte, daß man im Modul aus irgendwelchen Gründen die Logik ändert, und daß dabei zu übersetzende Texte aus dem Modul entfernt (gelöscht) werden - jeweils zusammen mit der einschließenden Funktion mi18n. Andere Texte - mit neuen mi18n-Funktionen kommen hinzu. Die gelöschten Texte tauchen auch weiterhin in der Tabelle con_mod_translations auf, zusammen mit den neuen Texten.

Ich meinte keine Textersetzung, sondern komplett gelöschte und komplett neue Texte im Modul.

Das kann ich definitiv nicht nachstellen. Wenn ich Übersetzungen ändere oder lösche, stehen mir diese unter Übersetzungen auch nicht mehr (bzw. geändert) zur Verfügung.

[siegparr]

Hallo Dodger77,

danke für die schnelle Antwort!

Wenn ich Übersetzungen ändere oder lösche, stehen mir diese unter Übersetzungen auch nicht mehr (bzw. geändert) zur Verfügung.

Mag sein, aber ich meinte die Tabelle selbst (die würde ich ja gerne direkt auslesen bzw. manipulieren [das ist bisher aber nur angedacht], deshalb auch der Hinweis auf das Backup ). Dort stehen die alten Informationen immer noch drin - bei mir in Contenido Version 4.6.8 (ein Update ist leider momentan nicht vorgesehen ).

Bei mir tauchen die alten Texte im Reiter Übersetzung aber leider sehr wohl auf.

Handelt es sich vielleicht um ein Versionsproblem? (Möglicherweise kann ich ja jemanden zu einem Update überreden )

[Dodger77]

Bei mir tauchen die alten Texte im Reiter Übersetzung aber leider sehr wohl auf.

Bei meiner 4.6.15 Version sind die Übersetzungen aus der Tabelle verschwunden und tauchen demnach unter "Style->Module->Übersetzungen" auch nicht mehr auf. Es ist müßig sich darüber zu unterhalten, dass dies bei einer 4.6.8 (die man auch wegen fast 100 anderer Gründe updaten sollte) nicht funktioniert.

[siegparr]

Es ist müßig sich darüber zu unterhalten, dass dies bei einer 4.6.8 ... nicht funktioniert.

Da hast Du wohl Recht.

Vielleicht lassen sich meine Vorgesetzten überreden Contenido auf den neuesten Stand zu bringen.

Ich werde schon irgendwie weiterkommen.

Danke für Eure Hilfe

Frohe Weihnachten und einen guten Rutsch ...