webEdition - Forum

Hi,
Newsletter-System benutzt CSV Dateien, nicht das Kundenmodul.
Hierbei exisitiert bereits ein subscribe System in DE, funktioniert alles.
Dieses Newslettersystem soll nun um EN erweitert werden, also wurde das Template u.a. bei angepasst.
Nun erkennt aber das ganze nicht, jeder, der sich einträgt, ist weder female noch male, sondern "was anderes".
Ich gehe davon aus, dass nur Herr und Frau als Strings zugelassen sind.

Wie bekomme ich nun die englische Anrede ins Frontend auf die "subscribe" Seite?

stimmt nicht ganz:
in den Newsletter-Einstellungen gibt es wohl ein Feld das angibt wie "Frau" heißt; äquivalent für den "Mann" - allerdings kann man da wohl nur einen Wert angeben.

Wie ist denn die empfohlene Vorgehensweise, wenn ich das Newslettermodul einmal in DE und einmal in EN verwenden will?
Die Sprachen haben jeweils eigene CSV Dateien.

tja, Empfohlen ist ne gute Frage....
Du stößt da grad in eine Baustelle/Diskussion rein
http://qa.webedition.org/tracker/view.php?id=5460

Aktuell ist es ja so, das die Felder Vorname, Nachname und Anrede, HTML_NEWSLETTER (und noch eines) von WE (aus alten Zeiten) vorgegeben sind.
Schön und sauber ist das nicht - ich würde mir nämlich auch eine "leere" Kundenverwaltung wünschen.
Und genauso werden wohl dann auch externe CSV's verarbeitet.

Im Newsletter-Modul sollte es u.a. die Möglichkeit geben mehrere Werte anzugeben - aber ob das dann die Lösung ist (würde nur dein Problem lösen) - für die KV würde das ggfs. bedeuten das ich dann trotzdem ein Feld Salutation mit "Herr,Frau,Mrs,Mr, ...." machen würde, was vermutlich auch viele nicht toll fänden wenn das komplett immer angezeigt würde bei der Benutzeranlage weiß ich auch nicht.
Mich stört es als "Benutzer" auf englischen Webseiten auch, wenn ich da immer "Mr." angeben muß - bin noch überfragt, wie da der Königsweg aussieht.

Evtl. sollte es nicht nur eine Option für die "values" geben, sondern auch für die Texte zwischen den option-Tags.
Also sowas wie Dann würde es sowas ausgeben: Das Ergebnis wäre ein System, das webEdition derzeit versteht und gleichzeitig die Möglichkeit für den Entwickler, die Ausgabe zu lokalisieren, via. Zend_Translate sogar für viele Sprachen mit dem gleichen Code. SOwas würde ich brauchen!

... sinnvoller als einen neuen Parameter Show wäre vielleicht eine Vorgehensweise, wie bei der sprachabhängigen Datumsformatierung: http://www.webedition.org/de/aktuelles/ ... ffentlicht

Somit würden die Values "Mr., Mrs." je nach Sprache z.B. im Deutschen als Herr, Frau übersetzt werden.

Aktuell würde ich bei mehrsprachigen Webseiten für die Newsletter-Verwaltung die CSV-Variante empfehlen, sofern das Projekt nicht eine starke Intergration der KV bedingt.

Grüße, Andreas

ich denke man merkt hier deutlich das viele von den Sachen von living-e leider nie auf internationale Seiten ausgelegt waren.
Die meisten Änderungen kamen nachträglich rein.
Ein Problem an das wir hier immer wieder stoßen: wie kann man die Änderungen sauber machen, sodaß sie auch verständlich und logisch sind, aber gleichzeitig rückwärtskompatibel bleiben?!

Wir könnten hier wieder einen Workaround schaffen und die Anrede für Mann/Frau als CSV akzeptieren. Das wäre bspw. durchaus kompatibel.

Wenn du einen Show Parameter benutzt, gibst du den Leuten ja die Mglichkeit, die Ausgabe entweder sprachspezifisch übersetzt auszugeben (Stichwort Zend_Translate oder webedition eigene Tags) oder einen festen Wert einzubauen.
Mir geht es nur darum, dass ich _überhaupt_ die Möglichkeit habe, das ganze zu beeinflussen.
Ein Parameter Show gibt dir auch die Rückwärtskompatibilität, denn wenn der parameter fehlt wird alles so gemacht wie immer (alte Projekte laufen also nach wie vor genau so weiter wie bisher) und wenn der Parameter vorhanden ist, kann der entsprechend übergeben werden.
IMHO wäre es das flexiblebste und kompatibelste System, das mir so spontan einfallen würde.

Alles in allem würde ich das Geschlecht intern auch nicht als "Herr" bzw. "Frau" speichern, sondern als 1 oder 0, spart Speicher in der DB und in der Ausgabe und ist dann auch abstrakt genug, um übersetzungen möglich zu machen.

Bei der DB muß ich dir mit 0/1 vs. Herr/Frau unrecht geben - das wird (mittlerweile) auf ein enum-Feld abgebildet, hat also nach Anzahl Elemente zwischen 1-4 Byte Speicherverbrauch. Intern wird das auf eine Zahl abgebildet, und vor der Ausgabe transformiert.