Domino 9 und frühere Versionen > ND8: Entwicklung
beste Konzept für mehrsprachige Datenbanken
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:
--- Zitat von: Günther Rupitz am 17.10.12 - 13:04:41 ---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.
--- Ende Zitat ---
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.
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln