beste Konzept für mehrsprachige Datenbanken

[bikerboy]

Hallo zusammen,

unsere Firma ist zum Glück stark wachsend und expandiert von einem Land ins andere. Die Herausfoderung ist also recht einfach. Unsere Datenbanken müssen nun mehrsprachig ausgelegt werden.

Es gibt dazu schon ein Konzept, ich möchte aber sicherstellen, dass dieses alte Konzept noch zeitgemäß ist.

Die Datenbanken haben ein Sprachdokument pro Maske und Sprache. Die Labels sind alle berechnet über ein Feld, das sich beim öffnen berechnen. Die Auswahlfelder waren bis jetzt alle standard-mässig englisch sollen aber nun auch mehrsprachig ausgelegt werden. Nach meiner Überlegung komme ich dann nicht Aliase in den Listen umher. Nach weiterer Überlegung kam ich dann auf Profildokumente für die Umsetzung der Aliase in den Ansichten. Nun wurde mir mal gesagt Profildokumente sind im Grunde doof weil Sie immer mal wieder Ärger (Frühe Phase von 8.0, kein setzen mehr von Profildokumenten möglich)  machen. Aber Sie werden zum Glück arg von Lotus gecached und sind so super für ein @Replace in den Ansichten. Alternativ käme noch ein @DBLookup mit Cache in der Ansicht, aber beim Gedanken stellen sich schon die Nakenhaare hoch. Was ist denn aus Performancegründen die beste Wahl?

[Axel]

Schau dir mal !!HELP!! an.

http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=!!HELP!!

Hier im Forum gibt's auch ein entsprechendes Unterforum dazu.

In dieser Datenbank wurde eine mehrsprachige Benutzeroberfläche realisiert und das Ganze ist auch noch ziemlich performant.


Axel

[Mitch]

Lookups und Zugriffe auf Profildokumente sind AFAIR in Ansichten (Spalten, Auswahlformeln) nicht möglich.

Ansichten und Mehrsprachigkeit sind, insbesondere bei Auswahlfeldern mit Aliassen, Kategorien oder Spaltentiteln, ein fieses Thema. Oder waren es zumindest, habe mich unter 8.x noch nicht damit beschäftigt.

Ich glaube ich habe damals auf Spaltentitel verzichtet, Kategorien nur in der definierten "Basis-Sprache / Fallback-Sprache" angezeigt und mit über Environments versteckten Sprachspalten für die jeweiligen Sprachen gearbeitet (Sprachen habe ich für Auswahlfelder zusätzlich in einem versteckten Item gesichert). Das ist aber recht großer Pflegeaufwand und nicht dynamisch, da pro Sprache eine Spalte da sein muss. Und mit kategorisierten Spalten ging es gar nicht.

Würde mich aber interessieren wie du das umsetzt.

Gruß,

Mitch

[Axel]

Lookups und Zugriffe auf Profildokumente sind AFAIR in Ansichten (Spalten, Auswahlformeln) nicht möglich.

Ich glaube ich habe damals auf Spaltentitel verzichtet, ...

Richtig. In Spaltentiteln geht kein Lookup.

Ich habe damals bei der Umsetzung einer mehrsprachigen DB auch auf Spaltentitel verzichtet.

Axel

[bikerboy]

Gut auf die Titel hätte ich auch verzichtet, weil der Inhalt selbsterklärend sein sollte.

Aber wie löse ich die Aliase meiner Auswahllisten am geschicktesten auf?

[Axel]

Aber wie löse ich die Aliase meiner Auswahllisten am geschicktesten auf?

Hier mal ein Schuss ins Blaue:

Du erstellst für jede Sprache eine Auswahlliste. Ich würde die Auswahlliste in einem Dokument innerhalb der DB hinterlegen (siehe !!HELP!!). Die Aliase allerdings bleiben bei allen Sprachen die gleichen.

Bsp: 

für Englisch
Open | Alias1
Close | Alias2

für Deutsch:
Offen | Alias1
Geschlossen| Alias2

In der Maske in der die Auswahlliste vorhanden ist, erstellst du für die jeweilige Sprache ein Textfeld (versteckt). Dieses füllst du dann im QuerySave-Event der Maske über Frontend-Methoden. Somit hast du nach dem Speichern des Dokuments in den Feldern die "Klartext-Begriffe" zu dem ausgewählten Alias.

Diese Felder zeigst du dann in der/den entsprechenden Ansicht(en) an und zwar in Anhängigkeit der, vom User gewählten Sprache.

Ich hoffe ich habe es einigermaßen verständlich erklärt. 

Ist zwar von hinten durch die Brust ins Auge, aber was anderes fällt mir im Moment nicht ein.

Axel

[Mitch]

Axel,

so weit, so gut.

Aber: Wie würdest du das korrekte Feld entsprechend der Usersprache in der Ansicht anzeigen?

Konkret: Wie findest du die Usersprache heraus (Lookups, Environments und Profilzugriffe sind doch tabu) und wie machst du es, dass die Ansicht dafür nicht neu aufgebaut werden muss?

An der Stelle hing ich ja auch fest und habe eben mehrere Spalten gemacht und die versteckt/angezeigt. In der Hide-When-Formeln hat man nämlich mehr Möglichkeiten.

Ist aber eben sehr undynamisch. Und nicht für Kategorien geeignet.

Gruß,

Mitch

[bikerboy]

Konkret: Wie findest du die Usersprache heraus (Lookups, Environments und Profilzugriffe sind doch tabu) und wie machst du es, dass die Ansicht dafür nicht neu aufgebaut werden mus

Eben um das mit dem Profildokument streiten wir ja gerade. Dort könnte ich auf das entsprechende Sprachdokument zugreifen. Und dann das Feld entsprechend berechnen.

Alternativ, könnte man eine die Auswahlliste mit allen Sprachen im Dokument speichern und entsprechend der gewählten Sprache anzeigen.

ger~Auswahl1##eng~Choice1##esp~Para1

Das Kürzel welche Sprache man aber wünscht müsste man dann über Profil, oder Enviroment abfragen.

[Axel]

Ist aber eben sehr undynamisch. Und nicht für Kategorien geeignet.

Da kann ich dir nur recht geben.

Ich habe gerade noch mal geschaut. Damals habe ich für jede Sprache eine entsprechende Ansicht gebaut. War hier kein Problem weil es nur zwei Sprachen gegeben hat.

Axel

[bikerboy]

naja wir haben jetzt schon 3 und chefs anfoderung ist, wenn wir morgen in china was machen, soll das auch gehen.

doppellte ansichten, ist aber schon sehr nervig, haben immer rund 50 Ansichten pro db das potenziert mit den sprachen wird ein Moloch, dass ich selbst mit ytria nicht lösen möchte.

[Thomas Schulte]

Ich hab mich zu den Fallstricken der Mehrsprachigkeit ab 2006 in meinem Blog ausgiebig ausgelassen. Einfach mal nachlesen.

Und wenn du dir die Funktionsweise von !!HELP!! anschaust, da ist das mit der Mehrsprachigkeit soweit es eben geht eingebaut.

Wenn du Zeit, Lust und Budget hast, würde ich im Domino Umfeld, soweit das machbar ist, auf XPages setzen. Die haben mit der Mehrsprachigkeit nämlich nicht solche Probleme wenn man sie richtig aufbaut.

[Günther Rupitz]

Das Thema Mehrsprachigkeit habe ich schon mit vielen Consultants besprochen und die für uns beste Lösung sieht folgendermaßen aus:

Wir haben eine zentrale Sprach-Datenbank in der in für jedes Sprachschnipsel ein Dokument mit mit einer eindeutigen ID angelegt werden kann. Die Textbausteine in dieser Datenbank können von allen Datenbanken nach bedarf verwendet werden.

Die gleiche Textbaustein-Maske haben wir in jeder Datenbank für Textbausteine die nur in dieser Datenbank vorkommen.

In jeder mehrsprachigen Datenbank haben wir einen Agent der einmal in der Nacht die Daten aus diesen Dokumenten in ein Profildokument hinein verdichtet.
Der Umweg über die Einzeldokumente ist sinnvoll da ich dann das Profildokument im Design nicht warten muss, für einen neuen Textbaustein muss man einfach nur ein Dokument anlegen.

In den Masken gibt es dann für jeden angezeigten Textbaustein einen berechneten Text in dem mit der ID aus dem Profildokument der Text geholt wird.

Das cachen der Profildokumente am Client ist meines erachtens kein Problem, Änderungen an den Datenbanken werden ja nicht stündlich eingespielt sondern eher ausserhalb der normalen Bürozeiten.

Das Problem mit den Auswahlfeldern hab ich folgendermaßen gelöst: Anstatt des Wertes der ausgewählt werden soll wird die Textbaustein-ID hinterlegt. In der Maske mache ich dann ein für jede Auswahlmöglichkeit ein Lookup auf das Profildokument. Performanceprobleme gibt es hierbei keine, selbst bei vielen Werten.

Das einzige Problem das man auf diese weise natürlich nicht lösen kann ist die Spaltenüberschrift, hier gibt es wohl keinen besseren Weg als eine Ansicht pro Sprache. Damit bläst man halt leider die Ansichtsindizes auf.

[Mitch]

Das einzige Problem das man auf diese weise natürlich nicht lösen kann ist die Spaltenüberschrift, hier gibt es wohl keinen besseren Weg als eine Ansicht pro Sprache.

Wie hast du es denn gelöst, dass in Ansichtsspalten der korrekte Spracheintrag für Items aus Auswahlfeldern angezeigt wird? Z.B. für ein Status-Feld, das intern nur eine Alias-Nummer speichert, in einer Ansichtspalte aber als Text stehen soll, z.B. "Offen"?

[bikerboy]

Okay okay.... bin noch gespannt auf die Antwort von Mitch wegen der Ansichten.


Interessant finde ich die Sache von Thomas. Da wir uns dem XPage Thema mehr widmen wollen (Schulung bereits durch 2Consultants erhalten) Jetzt die Frage, wie schnell bekomme ich wohl ein bestehendes "CRM"-System in Xpage umgewandelt und dann noch die Mehrsprachigkeit rein gebaut? Vorsichtige Schätzungen meinerseits gingen in die 6 Monate. Es macht in meinen Augen aber nun keinen Sinn ein völlig neues Konzept auf alter Technik zu bauen.

[Jens Winkelmann]

Also ich würde an deiner Stelle dafür werben, sich auf eine Sprache, also Englisch, zu einigen.

Den Aufwand, den man in Mehrsprachigkeit rein steckt, kann man sicherlich besser an anderen Stellen ausgeben.

Der Inhalt wird ja sowieso immer nur in einer Sprache erstellt werden können.

Und wenn man international zusammenarbeiten möchte, dann ist es sowieso besser, dass man dieselben Begriffe verwendet.

Aber dieses ist sicherlich eine Frage welche Unternehmenskultur gepflegt wird.

Den Aufwand für eine Portierung nach XPage kann man so nicht schätzen. Die Frage ist:

- Wie Umfangreich ist deine CRM?

- Welche XPage Erfahrung haben deine Entwickler?

Jedenfalls sollte man auch hier den Aufwand nicht unterschätzen.

Wenn man keine Erfahrung mit XPage hat, so sollte man besser mit kleineren XPage Projekten anfangen. Dabei gehe ich davon aus, dass deine CRM recht umfangreich ist.

[Günther Rupitz]

Wie hast du es denn gelöst, dass in Ansichtsspalten der korrekte Spracheintrag für Items aus Auswahlfeldern angezeigt wird? Z.B. für ein Status-Feld, das intern nur eine Alias-Nummer speichert, in einer Ansichtspalte aber als Text stehen soll, z.B. "Offen"?

Ich habe im Dokument zusätzlich für jede Sprache ein "berechnetes Feld" mit Originalfeldname_Sprachcode in dem der sprachspezifische Text drinnen steht das für die Spaltenanzeige herangezogen wird.
Ich bin mir schon im klaren dass ich hier Daten doppelt speichere.
Die Aktualisierung wenn sich der Sprachtext ändert erledigt mir ein Agent. Dies ist aber über eine Klassenstruktur weitestgehend automatisiert.

Manchmal ist es halt lästig dass Notes keine relationale Datenbank ist

[Axel]

Wie hast du es denn gelöst, dass in Ansichtsspalten der korrekte Spracheintrag für Items aus Auswahlfeldern angezeigt wird? Z.B. für ein Status-Feld, das intern nur eine Alias-Nummer speichert, in einer Ansichtspalte aber als Text stehen soll, z.B. "Offen"?

Ich habe im Dokument zusätzlich für jede Sprache ein "berechnetes Feld" mit Originalfeldname_Sprachcode in dem der sprachspezifische Text drinnen steht das für die Spaltenanzeige herangezogen wird.

Das ist ja schön und gut, aber....

Wie ermittelst du in der Spalte welches Feld gerade angezeigt werden soll?

Axel

[Mitch]

Ich habe im Dokument zusätzlich für jede Sprache ein "berechnetes Feld" mit Originalfeldname_Sprachcode in dem der sprachspezifische Text drinnen steht das für die Spaltenanzeige herangezogen wird.

Okay, vielleicht habe ich auch einfach nur ein Brett vor dem Kopf: Aber wie zeigst du den richtigen Wert abhängig von der Usersprache in der Spalte an? Die Formel der Spalte ist es, die mir fehlt...  

Gruß,

Mitch

[Günther Rupitz]

Okay, vielleicht habe ich auch einfach nur ein Brett vor dem Kopf: Aber wie zeigst du den richtigen Wert abhängig von der Usersprache in der Spalte an? Die Formel der Spalte ist es, die mir fehlt...  

Das ist ja gar nicht notwendig (also bei mir zumindest).
Da man wegen der Spaltenüberschrift um eine Ansicht pro Sprache nicht herumkommt ist auch klar welches Feld man verwenden muss.

Wenn man sehr viele solche Felder in einem Dokument hat wird kann es halt schnell mal unübersichtlich werden wenn man sich bei der Benennung der Felder keine klare Richtlinie zurechtlegt.

[Mitch]

Alles klar, schade.

Denn auf Spaltenüberschriften hätte ich mit Freude verzichtet, wenn es denn eine Möglichkeit gegeben hätte, die Inhalte sprachdynamisch anzuzeigen. 

Mit mehreren Ansichten ist man auch wieder nicht dynamisch, da würde ich dann weiterhin meine Variante mit versteckten Spalten vorziehen. Auch nicht dynamisch, aber vielleicht performanter da weniger Ansichten...

Gruß,

Mitch