Umlaute bei OTRS_CUSTOMER_DATA_UserLastname falsch

[mkarg]

Wenn ich in einer Antwort

Code: Select all

<OTRS_CUSTOMER_REALNAME>

verwende, werden deutsche Umlaut korrekt dargestellt. Wenn ich statt dessen jedoch

Code: Select all

<OTRS_CUSTOMER_DATA_UserLastname>

verwende, erscheinen seltsame Hyieropglypgen (z. B. "Röck" statt "Röck"). Offenbar beherrscht also erstere Variable UNICODE, letztere jedoch nicht.

Wie kann ich das korrigieren?

(OTRS 3.3.x git)

[NancyL]

Zeichensatz in der Konsole Es kann passieren,Sonderzeichen und Umlaute falsch dargestellt werden. In diesem Fall ist es wahrscheinlich, dass der falsche Zeichensatz eingestellt ist. Dies kann man überprüfen, indem man an der Kommandozeile eingibt:
grep CODESET /etc/default/console-setup

Den richtigen Zeichensatz kann man mit folgendem Befehl einstellen

sudo dpkg-reconfigure console-setup

was steht bei dir unter Admini -> ServiceCenter für NLS_Lang?
/otrs/index.pl?Action=AdminServiceCenter

im zweifel hilft dir das hier weiter (ich gehe jetzt mal von Ubuntu aus, du hast leider nicht geschrieben welche OS du einsetzt):
https://help.ubuntu.com/community/Locale

[mkarg]

Den Eintrag "NLS_Lang" gibt es bei mir im Service-Zentrum nicht.

Ich verstehe auch nicht, wieso eine falsche Konsoleneinstellung bewirken soll, dass die eine Variable korrekt funktioniert, die andere jedoch nicht?

[schulmann]

Wie kann ich das korrigieren?

Vor der Korrektur würde ich versuchen, die Ursache zu klären.

Du bist sicher, dass beide Einträge in der DB mit dem gleichen Zeichensatz eingetragen sind?

[mkarg]

Wie kann ich das korrigieren?

Vor der Korrektur würde ich versuchen, die Ursache zu klären.
Du bist sicher, dass beide Einträge in der DB mit dem gleichen Zeichensatz eingetragen sind?

In Kernel/Config.pm ist eingetragen:

Code: Select all

Params => {
   ...
   SourceCharset => 'iso-8859-1',
   DestCharset => 'utf-8'
   ...
}
...
Map => [
   ...
   [ 'UserLastname' ... ]
   ...
]

weshalb ich davon ausgehe, dass die Variable OTRS_CUSTOMER_DATA_UserLastname deutsche Umlaute beherrschen müsste (sowohl iso-8859-1 als auch utf-8 können deutsche Umlaute, und die Liste in der Kundenbenutzerverwaltung, welche meines Wissen auf diesem Mapping basisert, zeigt beispielsweise den Herrn Röck auch tatsächlich völlig korrekt mit einem deutschen Umlaut an).

Auf welchem Weg jedoch die Variable OTRS_CUSTOMER_REALNAME zu ihrem Inhalt kommt, erschließt sich mir nicht (ich nehme an, dass selbige im Quellcode von OTRS vordefiniert ist), was umso seltsamer ist, da ja jene Variable durchaus einwandfrei funktioniert.

[tto]

weshalb ich davon ausgehe, dass die Variable OTRS_CUSTOMER_DATA_UserLastname deutsche Umlaute beherrschen müsste (sowohl iso-8859-1 als auch utf-8 können deutsche Umlaute, und die Liste in der Kundenbenutzerverwaltung, welche meines Wissen auf diesem Mapping basisert, zeigt beispielsweise den Herrn Röck auch tatsächlich völlig korrekt mit einem deutschen Umlaut an).

...ist das nur in der Übersicht der Fall oder auch wenn Du den Datensatz von Herrn Röck im Detail anschaust?

Ich vermute dass dein Datenbackend nicht sauber angebunden ist. Sind die Daten darin _tatsächlich_ iso8859 codiert oder nicht doch schon utf8?

Und nach dem Verändern der Konfiguration nicht das Löschen des Caches vergessen...

vG, T.

[mkarg]

weshalb ich davon ausgehe, dass die Variable OTRS_CUSTOMER_DATA_UserLastname deutsche Umlaute beherrschen müsste (sowohl iso-8859-1 als auch utf-8 können deutsche Umlaute, und die Liste in der Kundenbenutzerverwaltung, welche meines Wissen auf diesem Mapping basisert, zeigt beispielsweise den Herrn Röck auch tatsächlich völlig korrekt mit einem deutschen Umlaut an).

...ist das nur in der Übersicht der Fall oder auch wenn Du den Datensatz von Herrn Röck im Detail anschaust?

Der Herr Röck erscheint überall in der Benutzeroberfläche (dies beinhaltet sowohl die Übersicht als auch die Detailansicht, Tickets, Dashboard, usw.) mit deutschem Umlaut. Die einzige Stelle wo sein Name falsch erscheint ist die Variable OTRS_CUSTOMER_DATA_UserLastname, d. h. also wenn ich auf ein Ticket antworte in der Anrede.

Ich vermute dass dein Datenbackend nicht sauber angebunden ist. Sind die Daten darin _tatsächlich_ iso8859 codiert oder nicht doch schon utf8?

Die Datenbank sind tatsächlich iso-8859-1 codiert, das habe ich mehrfach in der MSSQL-Administration geprüft. Zudem wäre es ja unmöglich, dass überall die korrekten Umlaute auf dem Bildschirm im OTRS rscheinen, wenn dies nicht so wäre. Der Cache wurde schon mehrfach gelöscht, der Herr Röck (und auch alle anderen Personen mit Umlauten im Namen) wird aber weiterhin durch die Variable (und nur durch diese) falsch geschrieben.

[tto]

weshalb ich davon ausgehe, dass die Variable OTRS_CUSTOMER_DATA_UserLastname deutsche Umlaute beherrschen müsste (sowohl iso-8859-1 als auch utf-8 können deutsche Umlaute, und die Liste in der Kundenbenutzerverwaltung, welche meines Wissen auf diesem Mapping basisert, zeigt beispielsweise den Herrn Röck auch tatsächlich völlig korrekt mit einem deutschen Umlaut an).

...ist das nur in der Übersicht der Fall oder auch wenn Du den Datensatz von Herrn Röck im Detail anschaust?

Der Herr Röck erscheint überall in der Benutzeroberfläche (dies beinhaltet sowohl die Übersicht als auch die Detailansicht, Tickets, Dashboard, usw.) mit deutschem Umlaut. Die einzige Stelle wo sein Name falsch erscheint ist die Variable OTRS_CUSTOMER_DATA_UserLastname, d. h. also wenn ich auf ein Ticket antworte in der Anrede.

...siehst Du und genau das hatte ich in Deiner vorherigen Mail andersherum verstanden - ging aus meiner Sicht leider nicht so deutlich hervor...

vG, T.

[mkarg]

Der Herr Röck erscheint überall in der Benutzeroberfläche (dies beinhaltet sowohl die Übersicht als auch die Detailansicht, Tickets, Dashboard, usw.) mit deutschem Umlaut. Die einzige Stelle wo sein Name falsch erscheint ist die Variable OTRS_CUSTOMER_DATA_UserLastname, d. h. also wenn ich auf ein Ticket antworte in der Anrede.

...siehst Du und genau das hatte ich in Deiner vorherigen Mail andersherum verstanden - ging aus meiner Sicht leider nicht so deutlich hervor...

Ok nun da es klargestellt ist: Was kann ich tun?

[tto]

Ok nun da es klargestellt ist: Was kann ich tun?

...wenn alles sauber konfiguriert ist, bleibt nur zu schauen warum in Kernel::System::CustomerUser::DB::CustomerName anscheinend keine korrekte Umwandlung der Codierungen vorgenommen wird und mal den "Convert"-Aufruf zu verschieben oder zu deaktivieren - nur zum Test.

vG, T.

[mkarg]

Ok nun da es klargestellt ist: Was kann ich tun?

...wenn alles sauber konfiguriert ist, bleibt nur zu schauen warum in Kernel::System::CustomerUser::DB::CustomerName anscheinend keine korrekte Umwandlung der Codierungen vorgenommen wird und mal den "Convert"-Aufruf zu verschieben oder zu deaktivieren - nur zum Test.

Ich bin leider kein Perl-Programmierer und habe keinen blassen Schimmer von was Du sprichst... Gibt's eine Anleitung für Anfänger, wie man das macht?

[tto]

Ok nun da es klargestellt ist: Was kann ich tun?

...wenn alles sauber konfiguriert ist, bleibt nur zu schauen warum in Kernel::System::CustomerUser::DB::CustomerName anscheinend keine korrekte Umwandlung der Codierungen vorgenommen wird und mal den "Convert"-Aufruf zu verschieben oder zu deaktivieren - nur zum Test.

Ich bin leider kein Perl-Programmierer und habe keinen blassen Schimmer von was Du sprichst... Gibt's eine Anleitung für Anfänger, wie man das macht?

ok - das wäre zuviel zu beschreiben.

Warum nicht ein Workaround: verwende einfach andere Platzhalter in den Anreden/Vorlagen (z.B. <OTRS_CUSTOMER_REALNAME> => <OTRS_CUSTOMER_DATA_UserFirstname> <OTRS_CUSTOMER_DATA_UserLastname>). Da die anderen Platzhalter ja korrekt ersetzt werden, sollte es also passen

vG, T.

[mkarg]

...wenn alles sauber konfiguriert ist, bleibt nur zu schauen warum in Kernel::System::CustomerUser::DB::CustomerName anscheinend keine korrekte Umwandlung der Codierungen vorgenommen wird und mal den "Convert"-Aufruf zu verschieben oder zu deaktivieren - nur zum Test.

Ich bin leider kein Perl-Programmierer und habe keinen blassen Schimmer von was Du sprichst... Gibt's eine Anleitung für Anfänger, wie man das macht?

ok - das wäre zuviel zu beschreiben.

Warum nicht ein Workaround: verwende einfach andere Platzhalter in den Anreden/Vorlagen (z.B. <OTRS_CUSTOMER_REALNAME> => <OTRS_CUSTOMER_DATA_UserFirstname> <OTRS_CUSTOMER_DATA_UserLastname>). Da die anderen Platzhalter ja korrekt ersetzt werden, sollte es also passen

Ich verstehe nicht, wie das mein initial beschriebenes Problem löst (siehe allererstes Posting), welches da lautet: OTRS_CUSTOMER_REALNAME geht, OTRS_CUSTOMER_DATA_UserLastname aber NICHT?

[tto]

...sorry hatte es noch falsch in Erinnerung. Liest sich schlecht auf einem Handy. Natürlich löst das Dein Problem nicht. Vergiss auch den vorherigen Text da War ich noch auf der falschen Schiene.

Hast Du schon mit den Charset-Einstellungen der Backendkonfiguration "gespielt"? Was ist wenn Src und Dest auf utf-8 stehen? Wenn dein ms-sql über ODBC angebunden ist findet evtl. dort schon eine Konvertierung statt. Aus der Ferne geht leider nur noch raten.

vGT

[mkarg]

...sorry hatte es noch falsch in Erinnerung. Liest sich schlecht auf einem Handy. Natürlich löst das Dein Problem nicht. Vergiss auch den vorherigen Text da War ich noch auf der falschen Schiene.Hast Du schon mit den Charset-Einstellungen der Backendkonfiguration "gespielt"? Was ist wenn Src und Dest auf utf-8 stehen? Wenn dein ms-sql über ODBC angebunden ist findet evtl. dort schon eine Konvertierung statt. Aus der Ferne geht leider nur noch raten.

So nun bich ich an der Reihe mich zu entschuldigen: Das ganze Thema hat sich nämlich gerade erledigt!

Nachdem ich festgestellt hatte, dass nur bestimmte Datensätze betroffen sind, wurde ich mistrauisch und habe den Cache gelöscht -- was nichts gebracht hat. Danach habe ich in der Microsoft-Datenbank, aus welcher die Kundenbenutzer stammen, im Feld "Kommentar" eine Änderung gemacht, um eine Resynchronisation dieses Datensatzes mit OTRS zu erreichen -- was funktioniert hat: Und siehe da, der Herr Röck erscheint nun im OTRS überall korrekt (auch in der angesprochenen Variable OTRS_CUSTOMER_DATA_UserLastname), ebenso wie alle anderen Kollegen!
Insofern lag es also keineswegs an OTRS, sondern da ging wohl in der Anfangszeit der Anbindung Microsoft-an-OTRS mal irgendwann etwas schief, wodurch einige Datensätze nun "verbogen" waren, was seltsamer Weise nicht durch eine Cache-Löschung zu korrigieren ist, sondern nur durch eine "Zwangs-Resynchronisierung".

Wie auch immer, nun funktioniert alles, und ich danke Dir nochmals herzlich für Deine Hilfe!

[tto]

[...]
Nachdem ich festgestellt hatte, dass nur bestimmte Datensätze betroffen sind, wurde ich mistrauisch und habe den Cache gelöscht -- was nichts gebracht hat. Danach habe ich in der Microsoft-Datenbank, aus welcher die Kundenbenutzer stammen, im Feld "Kommentar" eine Änderung gemacht, um eine Resynchronisation dieses Datensatzes mit OTRS zu erreichen -- was funktioniert hat: Und siehe da, der Herr Röck erscheint nun im OTRS überall korrekt (auch in der angesprochenen Variable OTRS_CUSTOMER_DATA_UserLastname), ebenso wie alle anderen Kollegen!
Insofern lag es also keineswegs an OTRS, sondern da ging wohl in der Anfangszeit der Anbindung Microsoft-an-OTRS mal irgendwann etwas schief, wodurch einige Datensätze nun "verbogen" waren, was seltsamer Weise nicht durch eine Cache-Löschung zu korrigieren ist, sondern nur durch eine "Zwangs-Resynchronisierung".

Wie auch immer, nun funktioniert alles, und ich danke Dir nochmals herzlich für Deine Hilfe!

...damit ist ein großes Mysterium gelöst - Danke - konnte schon fast nicht schlafen deswegen.

vG,T.