Das Notes Forum

Domino 9 und frühere Versionen => ND8: Entwicklung => Thema gestartet von: bikerboy am 17.10.12 - 10:27:58

Titel: beste Konzept für mehrsprachige Datenbanken
Beitrag von: bikerboy am 17.10.12 - 10:27:58
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?

Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Axel am 17.10.12 - 10:48:09
Schau dir mal !!HELP!! an.

http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=!!HELP!! (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
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Mitch am 17.10.12 - 10:59:34
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
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Axel am 17.10.12 - 11:27:18
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
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: bikerboy am 17.10.12 - 11:46:54
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?
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Axel am 17.10.12 - 12:23:04
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
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Mitch am 17.10.12 - 12:31:41
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
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: bikerboy am 17.10.12 - 12:39:05
Zitat
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.
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Axel am 17.10.12 - 12:39:35
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
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: bikerboy am 17.10.12 - 12:55:42
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.
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Thomas Schulte am 17.10.12 - 13:03:28
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.
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Günther Rupitz am 17.10.12 - 13:04:41
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.
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Mitch am 17.10.12 - 13:41:00
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"?
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: bikerboy am 17.10.12 - 14:11:51
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.
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Jens Winkelmann am 17.10.12 - 15:10:27
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.
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Günther Rupitz am 17.10.12 - 16:14:40
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 ;)
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Axel am 17.10.12 - 16:18:30
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
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Mitch am 17.10.12 - 16:18:56
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
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Günther Rupitz am 17.10.12 - 16:32:39
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.
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Mitch am 17.10.12 - 16:37:32
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
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Günther Rupitz am 17.10.12 - 16:55:48
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...

Aber wieso, oder steh ich jetzt auf der Leitung.
Wenn du sowieso eine Spalte pro Sprache hast dann weisst du ja auch wieder was in dieser Spalte stehen soll (und die anderen versteckst).

Was du unter dynamsich verstehst funktioniert in Lotus Notes so oder so nicht weil eine Ansicht nie dynamisch bei der Anzeige erstellt werden kann sondern schon vorher feststehen muss.
Eine Berechnung "on the fly" kann im Notes tw. schon funktionieren, nur kann dir niemand garantieren dass dies immer der Fall ist.
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: Mitch am 17.10.12 - 17:25:54
Aber wieso, oder steh ich jetzt auf der Leitung.
Wenn du sowieso eine Spalte pro Sprache hast dann weisst du ja auch wieder was in dieser Spalte stehen soll (und die anderen versteckst).

Ja, aber ich habe nur in ein paar ausgewählten Ansichten eine handvoll Spalten "zu viel". Und nicht gleich die ganze Ansicht doppelt.

Aber eben mit den Einschränkungen, dass es keine (oder nur einsprachige) Spaltenüberschriften gibt und Kategorien ebenfalls nur einsprachig funktionieren.

Ersteres war in meinem Fall kein Problem, auf zweitere konnte ich verzichten indem ich EmbeddedViews mit SingleCategory verwendet habe. Ist sicherlich nicht in jedem Anwendungsfall eine Option, bei mir hat es aber gepasst.

Konkret habe ich es so angelegt:


So hatten die User in den Masken ihre jeweiligen Sprachen, und in den Ansichten habe ich zumindest die meisten Nutzer vernünftig bedienen können. In unserem Fall war das in Ordnung, da nur sehr wenige User eine "spezielle" Sprache hatten. Bei gleichmäßiger Sprachverteilung wäre das sicher nicht so toll.

Was du unter dynamsich verstehst funktioniert in Lotus Notes so oder so nicht weil eine Ansicht nie dynamisch bei der Anzeige erstellt werden kann sondern schon vorher feststehen muss.

Ja, das ist ja der Haken. Dynamisch geht nicht. Daher war ich ja auch so an deiner Variante interessiert, weil ich das so verstanden hatte, dass du es hinbekommen hättest. Vielleicht mit irgendwelchen, mir völlig entgangenen, 8er Funktionen, die Strings auch in Ansichten on the fly austauschen können. Oder so. Die Hoffnung stirbt eben zuletzt.  ;)

Gruß,

Mitch
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: bikerboy am 18.10.12 - 10:59:38
So ich möchte mich an der Stelle für die rege Beteiligung bedanken. Da wir unser CRM schon mal in Englisch haben, habe ich gestern meinem Chef gemeldet, dass wir das ganze auf Xpages machen sollten und mir deswegen viel Zeit gebucht. Konnte ihn besänftigen mit dem Aspekt der iPad-Umsetzung. Werde nun mich an das Xpage-Thema mit kleineren DBs rantasten
Titel: Re: beste Konzept für mehrsprachige Datenbanken
Beitrag von: bikerboy am 11.02.13 - 18:14:15
So ich muss leider doch noch was mit der "alten" Technik machen und bekomme gerade das blanke ----zen. Nachdem ich festellen musste, dass weder @GetProfileField, noch @Enviroment in der Ansicht funktioniert habe ich den Beitrag http://welovenotesbut.com/blog/?p=6 (http://welovenotesbut.com/blog/?p=6) gelesen und das untere "Skript" geschrieben. Bekomme aber immer nur den else-Wert. Finde aber in der Hilfe nicht den Hinweis, geht nicht in Spalten und laut dem Beitrag, unter der Vorraussetzung ich habe nicht was überlesen, geht es, aber leider nicht bei mir.

Code
_field := so_1;
_parameter := "so_1";
_data := @If(		@LanguagePreference([Region]) = "de" ; para_de ;
				@LanguagePreference([Region]) = "sp" ; para_es ;
				@LanguagePreference([Region]) = "en" ; para_en ;
				para);
_data

Ich wollte es erst elegant mit @GetField lösen, aber der Wert ist ja nicht "abgreifbar"

Wie einige sich schon denke speicher ich einfach alle Parameter redundant im Dokument. Lieber wäre mir Profile-Dokument gewesen, aber geht ja nicht.

Für das setzen der Parameter habe ich ein kleine @Function-Konstrukt gebaut, das hier quasi mal in die Qualitätsprüfung geben möchte.

Code
REM {Parameter ins Dokument schreiben) };
_parameterID := Parameter_ID;
_avLang := @GetProfileField("ProfileDB" ; "DB_Language");
_dbKey := @GetProfileField("ProfileDB" ; "DB_Key");
_view := "(LookupParameterByDatabase)";
_key  := (_avLang : "*") + dLim2 + _dbKey ;
_column := 2;
@Transform(_key ; "_pos" ; @Do(
	_Data := @DbLookup("":"NoCache";_parameterID;_view;_pos;_column; [FailSilent]);
	@If(_Data != "";
		@If(@Left(_pos ; dLim2) = "*" ;	@SetField("para" ; _Data) ;
								@SetField("para" + "_" + @Left(_pos; dLim2) ; _Data)
		)
		;""
	)
)) ;
1