Mehrsprachige Notes Anwendung erstellen

[maxritti]

Hallo zusammen,

derzeit bin ich dabei eine erste mehrsprachige Anwendung im Lotus Notes Client zu implementieren.
Dabei habe ich eine bestehende Anwendung, die derzeit auf deutsch ist und nun ein englisches UI bekommen soll.
Da die Anwendung nicht so wirklich komplex ist, wollte ich mal folgende Lösung mit kopieren der Designelemente anfangen.

https://www-01.ibm.com/support/knowledgecenter/SSVRGU_9.0.1/com.ibm.designer.domino.main.doc/H_PLANNING_FOR_TRANSLATING_AN_APPLICATION_STEPS.html

Dabei bin ich jetzt aber am Anfang im Designer (Version 9.0.1FP4) schon auf ein kleines Problemchen gestossen.

Zunächst habe ich mir eine neue leere DB angelegt, dort angegeben daß diese mehrsprachig ist und Deutsch als Default Sprache hinterlegt.

Nun soll als Startseite ein Frameset genutzt werden.
Also zwei Framesets mit unterschiedlichem Namen aber gleichen Alias angelegt.
Bei einem Sprache Deutsch und bei dem anderen Sprache English ausgewählt.
Wenn ich nun aber bei der Startoption der DB einen Frameset anzeigen lassen möchte, so gibt er mit hier beide Namen der Framesets an.
Also muss ich hier explizit einen auswählen. Ich dachte, dass hier nur der Alias auswählbar sei und der Client anhand der Spracheinstellung im Client entscheidet, welchen Frameset er anzeigt.

Aber es geht noch weiter.
In einem Frame des Framesets möchte ich links eine Outline anzeigen lassen (einmal deutsch, einmal englisch).
Also zwei Pages gebaut, wieder mit unterschiedlichem Namen, aber gleichen Alias erstellt und die Sprache zugeordnet.

Wenn ich nun meinen Englischen Frameset öffne und die Page zuordnen möchte, sehe ich bei der Auswahl der Page aber nur den Namen der Deutschen Page.
Weder die englische, noch den Alias der Pages.

Das gleiche passiert auch mit Ansicht. Ich habe eine deutsche Ansicht und eine englische mit gleichem Alias.
Im englischen Frameset beim Ansichtsframe, kann ich aber wieder nur den Namen der deutschen Ansicht wählen.

Die Einstellungen der Sprachen bei den Designelementen habe ich nun schon mehrfach geprüft.
Und ein Kollege hat auch schon mal drüber geschaut. Somit kann ich da eine Fehlkonfiguration eigentlich ausschliessen.

Kann mir hier eventuell einer einen Tip geben, was hier falsch läuft?

[Peter Klett]

Ich habe noch nie eine mehrsprachige Notes-Datenbank gebaut, schreibe hier also nur Vermutungen.

Bei der Auswahl der Elemente bekommst Du den Namen angezeigt, aber intern wird doch sicherlich der Alias verwendet (das kenne ich aus Gliederungen, bei denen die erste Ansicht immer den gleichen Alias hat, kopiere ich die Datenbank und ändere den Namen der ersten Ansicht, steht dieser geänderte Name auch in der Gliederung, ohne dass ich die jemals angefasst hätte).

Ich würde also einfach die benötigten Elemente auswählen (egal, welche Sprache angezeigt wird) und dann in der Datenbank probieren, wie die sich bei unterschiedlichen Ländereinstellungen verhält.

Dass Du auch im englischen Designelement nur deutsche Elemente zur Auswahl angeboten bekommst, fände ich logisch, wenn Dein (Designer-)Client auf deutsch gestellt ist. Ich würde nicht erwarten, dass der Designer anhand der Sprache des aktuellen Elements die Auswahl berechnet, sondern anhand der Ländereinstellung des Rechners. Dass beide Framesets angezeigt werden, liegt vielleicht daran, dass dort diese Ländermimik nicht sauber umgesetzt ist.

Aber wie gesagt, reine Vermutung, die nicht mit Praxiswissen belegt ist ...

[Tode]

Ja: Du verwendest die von IBM vorgesehene aber nicht benutzbare Vorgehensweise für Multilinguale Datenbanken.
Ich weiss nicht, welche Tools IBM intern verwendet, aber der Domino- Designer kann es nicht sein, denn:

- Mit dem Designer kann man keine zwei Elemente mit dem selben Namen anlegen, selbst wenn diese verschiedene Sprachen haben
- Der Designer bietet KEINE Möglichkeit, mehr als ein Element für das Datenbank- Script anzulegen (bzw. dann die jeweiligen Sprach- Scripte zu bearbeiten, wenn man tatsächlich mehr als eines hat).

Der "offizielle" Weg wäre, den "Domino Global Workbench" zu verwenden, um Multilinguale Datenbanken zu erstellen, aber der Weg war schon vor 10 Jahren besch... und ich glaube nicht, dass an dem Werkzeug nochmal weitergearbeitet wurde.

Am Besten, Du gehst von dieser Art der "Multilingualität" weg und findest einen eigenen Weg... Alles andere ist -IMHO- ein Krampf.

[maxritti]

Am Besten, Du gehst von dieser Art der "Multilingualität" weg und findest einen eigenen Weg... Alles andere ist -IMHO- ein Krampf.

Schade eigentlich. Hätte ja relativ einfach funktionieren können.

Ach da fällt mir doch gerade bei OpenNTF das Help! ein.
Das ist doch Multilangual. Mal schauen, wie das dort realisiert wurde...

Danke auf jeden Fall für Eure Antworten.

[Peter Klett]

- Mit dem Designer kann man keine zwei Elemente mit dem selben Namen anlegen, selbst wenn diese verschiedene Sprachen haben

Laut der oben verlinkten Beschreibung soll man das ja auch nicht, sondern die Aliase sollen gleich sein, und das geht, getestet bei Masken und Ansichten

[maxritti]

Ich habe noch nie eine mehrsprachige Notes-Datenbank gebaut, schreibe hier also nur Vermutungen.

Bei der Auswahl der Elemente bekommst Du den Namen angezeigt, aber intern wird doch sicherlich der Alias verwendet (das kenne ich aus Gliederungen, bei denen die erste Ansicht immer den gleichen Alias hat, kopiere ich die Datenbank und ändere den Namen der ersten Ansicht, steht dieser geänderte Name auch in der Gliederung, ohne dass ich die jemals angefasst hätte).

Ich würde also einfach die benötigten Elemente auswählen (egal, welche Sprache angezeigt wird) und dann in der Datenbank probieren, wie die sich bei unterschiedlichen Ländereinstellungen verhält.

Dass Du auch im englischen Designelement nur deutsche Elemente zur Auswahl angeboten bekommst, fände ich logisch, wenn Dein (Designer-)Client auf deutsch gestellt ist. Ich würde nicht erwarten, dass der Designer anhand der Sprache des aktuellen Elements die Auswahl berechnet, sondern anhand der Ländereinstellung des Rechners. Dass beide Framesets angezeigt werden, liegt vielleicht daran, dass dort diese Ländermimik nicht sauber umgesetzt ist.

Aber wie gesagt, reine Vermutung, die nicht mit Praxiswissen belegt ist ...

Hallo Peter,

Du scheinst Recht zu haben.
Jetzt während der Mittagsruhe habe ich meine Test DB mal konsequent danach gebaut, wie Du gesagt hast.
Alle Designelemente mit einem Namen "WasAuchimmerGER" und "WasAuchImmerENG" erstellt und den gleichen Alias "WasAuchImmer" vergeben.
Jeweils die entsprechende Sprache im Designer zugeordnet. Im Frameset und den Pages die Elemente ausgewählt, welche ich dort brauche.
Egal, ob da "WasAuchUmmerGER" oder "WasAuchImmerENG" stand.

Und nun kann ich in der Tat im Client je nach Spracheinstellung die korrekten Designelemente anschauen.

Macht allerdings das entwickeln im Designer nicht wirklich schön, wenn da Namen stehen, die eigentlich nicht dahin sollten.

[Dr 84]

Hallo,

wir haben es so gelöst. Eine Language-DB angelegt und dort alle Texte in DE und EN angelegt, mit dem eindeutigen Schlüssel.
Danach alle Texte(Berechneter Text) und Elemente, in der mehrsprachiger Datenbank mit Formel hinterlegt, je nach Sprachauswahl werden die Texte in Deutsch oder Englisch aus Language-DB ausgelesen und angezeigt.

[maxritti]

Klappt das denn auch bei den Überschriften für Ansichten?
Ich meine da würde u.a. @DbLookup nicht funktionieren.

[Tim Pistor]

Bei !!HELP!! hatte Anfangs die Performance gelitten, da bei jedem einzelnen Label ein DBLookup ausgelöst wurde. Später wurde das Ganze dann in einem Profildokument gecached. Damit wurde es dann flotter...

[koehlerbv]

Überschriften gehen nicht. Hier muss man andere Lösungen finden (durchaus auch: Darauf verzichten können, oder embedded views "mit was drumrum" oder ...). Dafür hat man im Gegensatz zur angeblichen eingebauten Mehrsprachenunterstützung andere Vorteile wie "macht Euch doch Eure eigenen Sprachen, wir beschränken Euch ja nicht, können nur kein klingonisch.".

Wegen Performance: Daran kann man feilen und die Übersetzungszeit selbst bei einer langsamen Datenübertragung auf Unmerklichkeit schrumpfen lassen. Dazu braucht man nicht mal Profile Documents, 75 Lookups für 75 Übersetzungen auf einem Designelement kann man auf ein Lookup eindampfen.

Bernhard

[maxritti]

So richtig ungünstig wird es bei Schlüsselwörtern, wie ich es gerade feststelle. 
Das müsste man dann auch Konfigurationsdokumente haben und am besten Aliaswerte  verwenden.
Und von Messageboxen in Scriptlibraries mal ganz abgesehen.

Naja. Es gibt noch genug zu tun...

[koehlerbv]

Naja. Es gibt noch genug zu tun...

Sei Dir aber sicher: Das geht alles 

Bernhard

[Tode]

Und: Wenn Du es RICHTIG machst, dann machst Du die Arbeit nur einmal. Wir haben bei uns ein "Framework" auf dem wir aufsetzen: Damit ist automatisch jede Maske Multilingual (wenn man die entsprechenden Felder / Berechneten Texte einfügt), jede Script- Bibliothek kann auf übersetzte Texte zurückgreifen und auch für Ansichten haben wir eine gewisse Logik. Auswahllisten bestehen bei uns z.B. aus 2 - x Feldern ( wenn man performante Ansichten will, dann rechnen wir für die Ansichtswerte für jede gewünschte Sprache ein eigenes Feld). Diese Felder muss man nur kopieren, und die Feldnamen anpassen: Alle Formeln beziehen sich auf den Feldnamen und müssen somit nicht angepasst werden...

Es ist EINMALIG ne richtig grosse Arbeit, und man muss sich schon ne Menge Gedanken machen, aber wenn es dann mal fertig ist, dann ist es für jede Datenbank nur noch der Aufwand, die Übersetzungsdokumente anzulegen. Und wenn eine neue Sprache dazukommt, müssen wir im Design kaum was machen (ggf. die Ansichten für diese Sprache erstellen, darum kommt man häufig nicht drumrum): Der Benutzer kopiert die bestehenden Übersetzungsdokumente, ändert die Sprache und lässt jemanden die Texte einfahc übersetzen -> fertig...

[Tim Pistor]

Du kannst es Dir auch leicht machen und einfach !!HELP!! nehmen, alles rauswerfen was Helpdesk / Ticketsystem ist. Damit hast Du dann die !!BASE!! - die "Mutter" von !!HELP!!, !!SYSTEM!! und !!DRIVER!!. Ist OpenSource. Kann man & darf man.

[Tode]

Ja, das kann man natürlich auch machen...

[maxritti]

Ich denke, ich werde mal beide Wege anschauen.

!!HELP!! nehme ich mal auseinander und versuche das zu verstehen, was dort gebaut wurde.

Und auch selber ein paar Gedanken machen um so etwas zu erstellen, wie Tode es schreibt ist bestimmt auch nicht schlecht.

Danke auf jeden Fall an Alle, die sich hier so rege beteiligt haben.
Diese Forum ist einfach nur klasse.