Domino 9 und frühere Versionen > ND8: Entwicklung - XPages

Localization - Sprachabhängige Berechnung von View- und Dokument-Inhalten

(1/2) > >>

Driri:
Hallo,

gerade das generelle Problem gelöst, habe ich im Umfeld Mehrsprachigkeit direkt das nächste.

In einer Anwendung werden Dokumente mit einer Kategorie gegliedert. Über diese Kategorie werden auch Berechtigungen vergeben, d.h. in Abhängigkeit zur gewählten Kategorie wird im Hintergrund ein Leserfeld berechnet.

Diese Dokument-Kategorie wird natürlich auch in Ansichten zur Kategorisierung genutzt.

Jetzt soll die XPage-basierte Webversion mehrsprachig aufgebaut werden. Intern wird mit einem deutschsprachigen Notes-Frontend gearbeitet.

Die Kategorien müssen also jetzt auch mehrsprachig werden. Die anderen Dokument-Inhalte bleiben in Originalsprache und werden nicht übersetzt.


In den XPages für die Dokumentanzeige habe ich das folgendermaßen umgesetzt bekommen :

1) Unter den Ressourcen je unterstützter Sprache eine Textdatei angelegt (categories.properties, categories_en.properties, etc.). Die Textdatei ist wie folgt aufgebaut :

<Kategorie>=<Übersetzung der Kategorie>

z.B. Preise=Prices

2) In der XPage sind die Dateien als Ressourcenbundle eingebunden (siehe Screenshot 1)

3) Im berechneten Feld ist als Wert folgender Code hinterlegt :


--- Code: ---var cat = document1.getItemValueString("Category")
var catStr = String(cat);
return categories[catStr];

--- Ende Code ---

Okay, die zweite Zeile kann ich mir vermutlich schenken, aber egal  ;)

Das funktioniert soweit wunderbar. Je nach Browsersprache werden die jeweiligen Werte aus den Textdateien korrekt angezogen.


Die Kategorien in den Views sollen natürlich auch übersetzt werden. Ich habe mir gedacht, mach ich das mal nach dem selben Schema und habe erstmal in einer nichtkategorisierten View getestet.


Punkte 1 und 2 von oben sind in der XPage für die View identisch eingebaut. In der Spalte im View Control ist dann folgender Code hinterlegt :


--- Code: ---var cat = @ReplaceSubstring(rowData.getColumnValue("Category")," ","");
var catStr = String(cat);
return categories[catStr];

--- Ende Code ---

Das ReplaceSubstring brauche ich an der Stelle, weil die Originalkategorien teilweise Spaces enthalten und das immer zu Fehlern geführt hat. In den Textdateien sind die Leerzeichen ebenfalls entfernt und damit funktioniert dann auch die Übersetzung wunderbar.


Wunderbar, also habe ich das so auch in kategorisierten Views umsetzen wollen. Und da knallt es dann, ohne daß ich das irgendwie nachvollziehen kann. Der Aufbau ist wie oben beschrieben umgesetzt, der einzige Unterschied ist, daß die Spalte in der Ansicht halt kategorisiert und nicht nur sortiert ist.

Fehlermeldung im Browser :


--- Zitat ---Error while executing JavaScript computed expression
Script-Interpreterfehler, Zeile=1, Spalte=5: Unbekanntes Element '' in Java-Klasse 'java.util.PropertyResourceBundle'

--- Ende Zitat ---

Das ist diese Code-Zeile :


--- Code: ---var cat = @ReplaceSubstring(rowData.getColumnValue("Category")," ","");

--- Ende Code ---


Hat da jemand ne Idee ?


Oder gibt es eine bessere Alternative, um an der Stelle die Mehrsprachigkeit zu erreichen ?

Driri:
Ich habe die Frage auch mal bei Stackoverflow gepostet :

http://stackoverflow.com/questions/10140087/translating-column-values-in-a-view-control

eknori (retired):
Die Einbindung der Mehrsprachigkeit ist schon richtig; allerdings sagt die Fehlermeldung eindeutig, daß der KEY nicht in der .properties vorhanden ist.


--- Zitat ---Error while executing JavaScript computed expression
Script-Interpreterfehler, Zeile=1, Spalte=5: Unbekanntes Element '' in Java-Klasse 'java.util.PropertyResourceBundle'
--- Ende Zitat ---

hast du mal getestet, was in var catStr = String(cat); steht?

Driri:
Nein, habe ich noch nicht geprüft. Mache ich gleich mal.

Mich hat irritiert, daß ich einer sortierten View die Werte korrekt übersetzt bekomme, sobald ich das in einer kategorisierten View mache, es zu der Fehlermeldung kommt.

Die Views sind ansonsten absolut identisch.

Driri:
catStr enthält die korrekten Werte, Leerzeichen sind rausgetrimmt.

Genau mit diesen Werten müßte eigentlich in den Textdateien die Auflösung funktionieren.

Navigation

[0] Themen-Index

[#] Nächste Seite