Sprachvariablen des Auftrags nutzen in eMail-Vorlagen

[intrinsicforce]

Hallo,

in den neuen Vorlagen mit Bausteinen wird bei beliebigen Variablen für die HTML-/Text-eMails (hier getestet z.B. mit Report.PaymentMethodName) immer der Text der deutschsprachigen Variable ausgegeben.

Das trifft aber auch dann zu, wenn im Auftrag eine andere Sprache gesetzt wurde und die Vorlage für genau diese Sprache konfiguriert ist. Sinnvollerweise sollte in so einem Fall natürlich automatisch die richtige Übersetzung in der Ausgabe landen - keine Frage.

Kann hier momentan mit DotLiquid die Variable noch angepasst werden, oder muss der JTL-Nutzer hier tatsächlich auf SQL-Queries zurückgreifen? Dieser Guide hier ist ja mittlerweile veraltet.

Viele Grüße!

 

[frankell]

Hallo @intrinsicforce,

manche Variablen werden korrekt je nach Sprache ausgegeben (Position.Unit), andere gleich in allen Sprachen (Specification.TextsIGL) und der große Rest nur auf Deutsch. Während man bei den Dezimalzahlen zumindest mit Report.CultureInfo arbeiten kann, geht das bei den Texten nicht. Und schaut man sich die Fehlermeldung bei Verwendung des Filters SelectLanguage an, sind diese Variablen noch nicht einmal zweisprachig angelegt.

Da "hilft" nur, anhand If-Clauses mit der Report.LanguageISO alle Texte mit einzubauen oder pro Sprache eine Vorlage anzulegen und/oder halt: Happy SQL!

 

[intrinsicforce]

Puhhh.. Das ist ja noch chaotischer als ich dachte.

Happy SQL!

Mmmmh jaa, wird dann wohl das Motto bleiben 😵

 

[intrinsicforce]

Übersetzungen scheinen tatsächlich gewürfelt:
Report.PaymentMethodName gibt die englischsprachige Bezeichnung raus, und payment.Name in der folgenden Schleife die deutsche Bezeichnung der Zahlungsart:

{% for payment in Report.InvoicePayments -%}
{% assign payments = true -%}
{% capture desc %}Payment ({{ payment.Name }}) from {{ payment.PaymentDate | Datum: 'd' }}:{% endcapture -%}
{% capture price %}{{ payment.Value | Nummer: 'C', Report.CultureInfo }}{% endcapture -%}
{{ desc }} {{ price }}
{% endfor -%}