Emails übersetzen bei eigenen Varianten nicht möglich?

Hallo Karsten,

ich dachte immer, die jeweilige Benutzersprache legt fest, in welcher Sprache er Benachrichtigungsmails vom System bekommt:

Einstellungen › Sprachen

Ich hab das allerdings noch nicht ausprobiert und mir ist auch nicht ganz klar, wo und wie Drupal die unterschiedlichen E-Mail-Übersetzungen verwaltet. Das ist wahrscheinlich genau dein Problem, oder?

Gruß
Frank

Nachtrag:
Hier ist das Problem auch noch ausgiebig diskutiert (inkl. Patches):

Email text posting in the user's language
http://drupal.org/node/82499

Jaein, wenn der Admin Benutzer anlegt, dann ist das so. Nicht schön, aber es ist halt so.

Wenn Jemand von Außen sich ein Konto anlegt, dann ist das immer in der Sprache die die Site gerade hat. Am anschaulichsten wäre das über die URL, also wenn die Seite unter "/de" oder "/en" läuft. Das funktioniert aber nur solange, bis du das Formular zu den Benutzereinstellungen einmal gespeichert hast. Dann hast du wie oben im Quellcode zu sehen Admin Variablen gesetzt und die werden nicht mehr übersetzt. Das passiert auch wenn du nur das Avatarbild änderst und nichts an den Emails. Selbst dann hast du die Emails nur noch in der Sprache des Admins. Das ist ganz schön krank auf den ersten Blick, denn die Textfelder werden immer in die Sprache des Admins übersetzt. Das heißt wenn du auf Englisch stellst, kommt da Englisch. Auf Deutsch Deutsch. Wenn du das aber überträgst, dann ist es nur noch das was du eingetragen hast, obwohl das erstmal nicht den Anschein hat. :(

Drupal hat ja die Policy, das nichts von außen in t() rein soll. Ich denke das ist auch gut. Aber das bedeutet das man i18n dafür nehmen muss, was bis D7 anscheinend noch nicht eingesetzt wird.

Die Patches muss ich mir mal ansehen und dann werde ich das ecard Modul mit i18n verheiraten. t() ist keine Lösung.

Ich muss sagen, das das nun das erste mal ist, das mir in Drupal etwas so richtig gar nicht gefällt. Ich muss jetzt auch mal Übercart darauf prüfen, wie das dort gelöst ist. Sonst hätte ich hier genau das Problem, das im Deutsch / Englisch Shop die Kunden immer nur eine Sprache bekommen.

---

Viele Grüße,

Kars-T

Ich hab mich auch noch mal in der Internationalization User Group umgesehen (http://groups.drupal.org/i18n), bin da aber leider auch nicht fündig geworden. Das ist ein spannendes Thema und ein echtes Manko.

Ansonsten könnte das Mail Editor-Modul vielleicht das Passende sein (http://drupalmodules.com/module/mail-editor):

Gruß
Frank

Das Mailedit Modul gibt mir aber eigentlich schon die Antwort. Der macht sich selbst eine Datenstruktur in D6 und speichert dann mit der aktiven Sprache die Daten weg. Gefunden werden die Daten für eine Mail dann wieder über die "mail_id" und die Sprach Id, wobei ich grad nicht weiß was die mail id in Drupal ist. Id des Mail Formulars?

Für Ecard heißt das, das ich die Datenstruktur ändern bzw. anlegen muss, diese Texte selbst führe und sehen muss wo ich eine Sprach ID her bekomme. Ich denke das sollte auch in D5 gehen. Irgendwie schade, das ich sowas nicht mit Drupal Bordmitteln machen kann, aber ich wüsste einfach nicht wie.

Aber es scheint mir da noch eine Menge anderer Probleme zu geben, mit der Mehrsprachigkeit. Erstelle ich D5 ein neues Konto hat das immer die Standard Sprache der Seite. Ich habe noch nichts gefunden, das man das auf die gerade aktive automatisch stellt oder der User das beim Anmelden wählen kann.

So sehr wie ich Drupal liebe, aber die Mehrsprachigkeit macht keinen Spaß...

---

Viele Grüße,

Kars-T

Hallo Karsten,

ich hatte vergessen/übersehen, dass du mit D5 arbeitest. (In D6 hat sich die Mehrsprachigkeit IMHO erheblich verbessert.)

Hast du dir schon mal das Modul #translatable angeschaut (http://drupal.org/project/translatable)? Das klinkt sich zwischen Forms API und Datenbank ein. Könnte also auch für E-Mails klappen.

Gruß
Frank

Ich glaube leider nicht, das das geht. Die Daten werden über variable_get gezogen und es ist ja auch kein direkter Form Submit, der beim versenden geschieht. Außer man kommt noch an die Variable ran, bevor sie ausgegeben wird, wird da nichts möglich sein. Und sowei ich die Funktion durchgesehen habe, geht da nichts mehr.

Auch in D6 habe ich zumindest über den Core nichts gefunden, das mir einzelne Strings mehrsprachig hält. Man müsste ja englisch als Übersetzung ansehen und den default String als Platzhalter. Es ist aber immer so, das englisch auch das Default ist. Mit i18n bin ich mir noch nicht sicher wie das geht. Es scheint aber wie man am legal Modul sehen kann zu gehen.

D7 hat auch anscheinend keine Verbesserung...

Wie ist denn die i18n Gruppe? Im Drupal Forum habe ich gar keine Antwort bekommen. Sind die gesprächiger? ;)

---

Viele Grüße,

Kars-T

Noch ein Versuch mit einem Modulvorschlag, der in diese Richtung geht:

Language Sections
http://drupalmodules.com/module/language-sections

Klappt aber womöglich auch nicht:

Ich denke schon. Da trifft sich alles, was in Sachen Internationalisierung bei Drupal Rang und Namen hat. Gruppenleiter Gábor Hojtsy arbeitet bei acquia und bringt es auf über 6000 commits...

Viel Erfolg!
Frank

Nachtrag:
Noch 'ne Idee. Die E-Mails abfangen und dann modifizieren:

Reroute Email
http://drupalmodules.com/module/reroute-email

Für das Ecard Modul werde ich es so halten, das ich D5 quasi aufgebe und die Features einfriere. Da sehe ich keinen Sinn drin bzw. deine Lösung wird soweit ich das sehe gut funktionieren, auch wenn es etwas komisch zu pflegen ist, da man zwischen verschiedenen Formularen hin und her muss.

Für D6 muss ich nochmal sehen, wie das genau geht, aber die Funktion tt() aus dem i18n Modul spielt hier die Musik. Damit scheine ich genau das zu erreichen, was ich will. Ich muss mal sehen, wie die die Daten für die Inhaltstypen übersetzen und was andere Module da machen. Aber damit sollte es leicht sein einen String gegen die Default Sprache, die dann nicht mehr Englisch sein muss zu übersetzen.

Was mir fehlt sind Dokumentationen und Erfahrungen mit tt(). Falls da einer was hat oder sagen könnte immer her damit :)

Und vielleicht sehen wir uns ja in Köln.

[edit]

Oh man, den Thread hatte ich mal gesehen, halb vergessen und nun ca. 1 Woche gesucht:

http://groups.drupal.org/node/15177

Das ist genau die Diskussion die ich meine. Nicht t() benutzen aber was dann? :)

---

Viele Grüße,

Kars-T

Hallo Karsten,

nur zur Ergänzung. Etwas strukturierter als im Thread ist das Thema t() in der Localization API dokumentiert:

"Dynamic strings with placeholders"
http://drupal.org/node/322732

[Nachtrag für alle Interessierten:]
Hier die API-Dokumentation der diskutierten Funktion:
http://api.drupal.org/api/function/_user_mail_text

Gruß
Frank

PS:
Bin leider nicht in Köln.

Ja genau die. Wenn man rein guckt, dann hat sich bei 6 zu 7 nichts verändert. Leider!

Wie ist denn das mit eigentlich dem Core? http://api.drupal.org/api/function/hook_locale/6 ist ja core. Nur kann man wenig damit machen, wenn ich das richtig sehe. Interessant wird das doch erst mit tt(), aber das kommt aus dem i18n Modul. Ich darf ja wohl kaum im Core eine Weiche einbauen, um wenn es aktiv ist tt() zu benutzen oder? Das ist aber genau der Hack, den ich wohl dafür einbauen werde.

Da tt() nicht core ist, wird das in der 7 auch nicht möglich sein. Ich rauf mir wirklich die Haare. Wo ist eigentlich die "richtige" stelle um mit den Core Entwicklern darüber zu reden? Forum? i18n Gruppe? IRC? Mailingliste? Ich bin leider in den englischen Sachen noch nicht so drin.

Schade!

---

Viele Grüße,

Kars-T

Ich finde die Lösung sollte aus dem Core kommen, zumindest in D7, aber D6 kann man so dazu bringen:

Man erstelle ein Modul:

Damit wird dem User die gerade aktive Sprache zugeteilt, wenn er angelegt wird. Von der Performance her, wäre ein eigenes Update besser, aber ich wollte das so klein wie möglich halten. Also ein User, der die Seite gerade auf englisch sieht, wird nun auch englisch als Standardeinstellung haben. Sonst wäre das immer die Standard-Sprache, bei mir dann meist deutsch.

Damit löst man aber nicht das Problem mit den Emails. Dazu brauch man, das oben erwähnte
http://drupal.org/project/mail_edit

Dieses Modul geht über hook_mail_alter und ersetzt die Emails. Woher die Tokens kommen weiß ich ehrlich grad nicht, aber es geht. Die Email wird korrekt gefüllt mit den gerade aktiven Daten.

Dieses Modul führt eine eigene Tabelle mit den Emails in der entsprechenden Sprache. Simpel und nett. Die Mails kommen glücklicherweise immer mit der beim User aktiven Sprachvariable beim Modul an, auch wenn der Text falsch wäre. Das Modul such dann den richtigen raus, ersetzt nochmal die Token und schon haben wir was wir wollen. Nur die Einstellungen in "Benutzereinstellungen" sind dann egal.

Das ist aber nur die Spitze des Eisbergs. Insgesamt bedeutet das Formulare über hook_form zu übersetzen und alle anderen Strings über das Template. Eigentlich erstellt man die Übersetzung also nochmal Barfuß dazu, da der Core es einfach nicht leistet das über eine Standardschnittstelle bereit zu stellen.

Ich sehe das mit einem lachendem und einem weinendem Auge. Drupal kann es eigentlich nicht, aber komme dank des guten Systems an die Daten ran!

[edit]

Sollte man sowas als Modul ins CVS bringen? Mir erscheint das als zuwenig für ein Modul? Ich kann mir aber vorstellen, das viele das brauchen könnten und das nicht mal eben selbst schreiben können.

---

Viele Grüße,

Kars-T

Hallo. Habe den Links gefolgt aus dem englischen Thread (http://drupal.org/node/163165).

Eine Frage über die hier vorgeschlagene Lösung. Wahrscheinlich werde ich dies selber bald rausfinden, aber: was passiert in der folgenden Situation?

Benutzer B spricht nur Finnisch und besucht die Website auf Finnisch. Registriert sich und bekommt ein Konto, bei dem die Einstellung "Sprache" nun doch richtig auf Finnisch gesetzt wird. Er wartet aber noch auf Zulassung des Kontos.

Admin A spricht kein Finnisch und eigentlich nur Deutsch. Daher sollte sie die Mail auf Deutsch bekommen, die ihr sagt, dass Benutzer B auf Zulassung wartet. Nicht auf Spanisch, der Default-Sprache der Website, und nicht auf Finnisch, was die gerade aktive Sprache vom Benutzer B war, in dem Moment wo die Mail an Admin A geschickt wurde. Die Benuztereinstellungen von Admin A sagen "Deutsch" - was sagt mail_edit?

Ebenso wird Admin A die Seite auf Deutsch eingestellt haben, wenn sie die Zulassung für Benutzer B bestätigt. Aber Benutzer B sollte die Bestätigungsmail (wie eigentlich von ihm eingestellt) auf Finnisch bekommen, egal in welcher Sprache die Admin A die Zulassung macht. Schließlich hat er ja dazu die Einstellung in seinem Konto.

Ich befürchte, dass die gewünschte Funktionalität durch mail_edit nicht angeboten wird.

Zu der Frage, ob das Ganze, einschließlich Formular-modifiziertung etwas für ein Modul ist, würde ich sagen: Ja. Und ich wäre auch evtl bereit, zu versuchen so was zu programmieren.

Eine Frage dazu: wie wäre es, wenn ein Formular für eine Mailinhalt die Inhalt für die gerade aktive Sprache beeinflusst? So, zB zeigt mir admin/user/settings die Maininhalte auf meiner Default-Sprache, und speichert meine Änderungen auch nur für diese Sprache, währenddessen ich bei de/admin/user/settings die Mailinhalte auf Deutsch einsehen und speichern kann. Ich kann mich nicht entscheiden, ob diese Lösung elegant oder ein Hack ist. Oder beides.

Grüße aus Manchester,

Martin

Oh je, oh je, du hast wohl recht mit allen deinen Problemen. Es kann sein, aber das habe ich nicht geprüft, das Drupal die Mails an den User immer in dessen Sprache schickt, bzw. das dort mail_edit dadurch greift. Aber ein Admin, wird glaube ich immer nur Mails in der Defaultsprache erhalten.

Man kann dann wohl nur empfehlen, das die Default Sprache dann immer englisch ist, das hoffentlich die Admins verstehen. Sonst wird das wirklich schwer.

Und Drupal geht wirklich immer davon aus, bzw. die Entwickler gehen wohl immer davon aus, das die Administrativen Eingaben immer in der default Sprache der Seite erfolgen. Schon allein die Funktion tt() die User given Strings übersetzen soll, geht davon aus, das aus Drupal immer Daten in der Default Sprache kommen, die nur bei bedarf übersetzt werden.

Ich würde mich freuen, wenn du am Codesprint nächste Woche teilnimmst und sonst diese Fragen mal der i18n Gruppe stellt. Wobei die auf mich nicht reagiert haben und sich so wie ich es empfinde auf D7 konzentrieren. So wie es jetzt aussieht, wird in D7 alles besser. Es wird wohl einiges über die Fields Translation API laufen. Aber wer weiß wann D7 Sinn macht, denn selbst wenn es erscheint, wird es mit den Modulen dauern...

http://groups.drupal.org/i18n

---

Viele Grüße,

Kars-T

Dass die Admins die Defaultsprache der Webseite verstehen sollten ist eine zwar nachvollziehbare Annahme, aber nicht immer wahr. Da Admins auch User sind und diese Einstellung für bevorzugte Sprache haben, wäre doch sinnvoll, danach auch zu schauen.

Naja, auf jeden Fall muss eine Mail an ein User doch in deren bevorzugten Sprache geschickt werden und nicht in der Sprache derjenigen, der die Mail schickt oder provoziert...

CodeSprint klingt interessant - sowas kannte ich doch nicht. War aber anscheinend letzte Woche. Und wirklich für D7. Das ist noch lange nichts für mich - ich brauche diese Funktionalität in D6.

Ich werde also doch an einer Lösung basteln und mich melden, wenn es soweit ist. Wie das zusammen mit den neuen D7-Entwicklungen passen wird, müssen wir dann wohl schauen...

Gruß,

Martin

Hi

wenn du was machst, kann ich dir nur raten, das du dich mit den i18n Leuten und vielleicht Gabor in Verbindung setzt. Nedjo oder Reyero anschreiben sag ich mal.

http://groups.drupal.org/user/426
http://groups.drupal.org/user/1293

Am Codesprint konnte ich beruflich nicht wirklich teilnehmen. Ärgert mich ist aber so. ABER die machen wirklich viel und das größte Problem ist zu begreifen wer genau was macht. Es ist wohl ein harter Kern und mit denen muss man besprechen, was läuft, sonst wirst du zum einen kaum einen Core Maintainer dazu bekommen das zu implementieren, was du willst und zum anderen könnte es schon eine andere Lösung geben und dann wird nicht unbedingt deine genommen. Die beissen nicht, leben aber in ihrer eigenen Welt ;)

Und bei den Admins: Man müsste mal an ein internationales Moderatoren Team denken. Ich würde mich ja freuen, wenn Leute etwas anderes als Deutsch und Englisch bei mir moderieren. Was mache ich dann wenn meine Seite im Default Deutsch ist? Gut auf englisch stellen, aber das zeigt deutlich das Problem.

---

Viele Grüße,

Kars-T

Zum Glück ist es nicht so schlimm wie ich befürchtet hatte.

Ich hatte deine Aussage

womöglich anders verstanden als gemeint. Ich dachte, das heißt, mail_edit schaut nicht danach, welche Sprache der Benutzer bevorzugt, sondern nur danach, in welcher Sprache die Seite gerade gelesen wird. Das wäre aber wirklich nicht sinnvoll. Was du wohl meintest war, dass die Einstellungen für Mailinhalte auf der Seite /admin/user/settings egal sind. Was ja irgendwie Schade ist, aber nicht dringend eine weitere Lösung braucht.

Insofern funktioniert deine Lösung eigentlich prima. Allerdings würde ich diese kleine Verbesserung des Moduls vorschlagen:

Dies ist notwendig, weil Admins auch Kontos erstellen können und dabei die Sprache ausdrücklich festlegen können. In dem Fall sollte die zufällig gerade aktive Sprache des Admins nicht die für den Benutzer gewählte Sprache überschreiben.

Zum Thema, was für eine Mail der Admin bekommt - in der Situation, in der sich jemand anmeldet und auf Zulassung wartet, bekommt die Site Email Address (keine Ahnung, genau wie das auf Deutsch genannt wird) die Mail, und keine anderen Admins. Jetzt ist die Annahme, der Inhaber von dieser Mailadresse versteht die Default-Sprache der Seite, noch nachvollziehbarer. Nur ist mir nicht ganz klar, wo der Inhalt der Mails an der Admin übersetzt werden kann.

Wenn das auch irgendwie konfigurierbar ist (schließlich müsste das doch sein, sonst wäre es sinnlos, dass im User-Modul nach der Default-Sprache der Seite geschaut wird), dann sollte man das wonötig einfach in einer Sprache schreiben, was dieser Person versteht.

Am Programmieren brauche ich also nichts zu machen.

Viele Grüße und danke für die Hinweise, die mir im Denken geholfen haben,

Martin

Ich hab ein Modul für D6 dafür gemacht:

http://drupal.org/project/reglang

Ich hatte irgendwie zwischen D5, D6 und D7 übersehen, das seit D6 der Admin die Sprache mitgeben kann. Danke für den Hinweis! :)

---

Viele Grüße,

Kars-T