Mehrsprachigkeit und Verständnisproblem !!Help!!

[LordKiri]

Hallo zusammen,

auch ich darf mich seit neuestem mit mehrssprachigen Datenbanken auseinandersetzten und habe erstmal fleißig hier gesucht und wie soll es auch anders sein die !!Help!!-Datenbank angeschaut.

Die Umsetzung gefällt mir sehr gut, nur habe ich ein kleines Problem mit dem Verständnis.

Ich versteh das Prinzip so:
- Es gibt systemweite Profildokumente, die alle möglichen Sprachwerte in Feldern beinhalten, die nach Wertgruppen aufgeteilt sind (Actions, Labels, ...)
- damit die richtige Sprache angezeigt wird, wird die Sprache über einen Environment_Wert festgelegt bzw. abgefragt (Prefix aller Sprachfelder)

=> ich kann über den Environment-Wert die Sprache umschalten...

Nun zu meinem Problem:
Wann bzw. wie werden die Profildokumente aktualisiert, wenn sich zum Beispiel Werte in den Sprachdokumenten ändern oder gar neue Sprachen hinzukommen?

Gruß

Andreas

[Tim Pistor]

Hallo Andreas,

im Tool unter Aktionen -> Cache Config Views

Ist ein Agent der aus Konfigurations- und Sprachdokumente Profildokumente erzeugt.

Gruß Tim

[koehlerbv]

Profildokumente werden beim erneuten Öffnen einer Datenbank erneut ausgelesen.
Das gilt logischerweise nicht für Maschinen wie den Domino, aber die spielen bei der Frontend-Funktionalität "Sprache" ja auch nicht mit.

Vulgo: Die Übersetzungen stehen in normalen Dokumenten. Entsprechende Lookup-Parameter vorausgesetzt, werden diese auch nach dem Öffnen der DB und der dann erstmaligen Verwendung der Elemente im Cache gehalten. Es gibt keine signifikanten (spürbaren) Unterschiede zu Profildokumenten.

Ich habe für derartige Übersetzungsroutinen noch ein etwas einfacheres und performanteres Verfahren im Einsatz. Ich beschreibe das in Kurzform mal so:
- Sprachfestlegung in einem persönlichen Profildokument (ich saue de facto nie die NOTES.INI zu und bin an dieses lokale Element nicht gebunden. Geht das Profildokument über den Jordan, dann gilt als Standard wieder Englisch).
- Normale Dokumente beinhalten jeweils Sprache, Designelement und Übersetzungselement (String).
- Zwei cfd fields lesen maskenglobal die Sprache, das Übersetzungselement und alle Übersetzungen beim Öffnen der Maske aus und werden damit umgesetzt (wie !!HELP!!)
- ScriptLibraries greifen nach dem gleichen Procedere auf die Übersetzungsdokumente zu - LotusScript-spezifisch natürlich.
- In Ansichten, Outlines etc. (also wieder Formelsprache) ist das etwas anders zu handhaben (hier ist !!HELP!! wieder eine gute Anschauungsquelle, viel anders mache ich das auch nicht): Eine kopierbare Aktion, in der nur Übersetzungsdokument und Übersetzungswert angepasst werden müssen.

Du kannst !!HELP!! als ein erstklassiges Beispiel für das Procedere hernehmen, über das Gesamtprinzip für alle unterschiedlichen zu übersetzenden Designelemente musst Du Dir aber auf jeden Fall vorab Gedanken machen. Hierzu zählen letztendlich solch scheinbare Kleinigkeiten wie die Vereinfachung der Übersetzungsmöglichkeiten / Übersetzungsüberwachungen. Beispiele:
- Sortierung der Elemente pro Dokument nach Element-Name
- Anzeige nach Sprache, Objektname, Übersetzungsdatum, Anzahl der enthaltenen Übersetzungsstrings
etc. pp.

Ein gutes Konzept und performante Routinen sind also das A & O.

HTH,
Bernhard

[LordKiri]

Danke für die Antworten...

@Bernhard: ich bin gerade schwer beschäftigt ein Konzept zu erstellen... Dein Weg hört sich auch interessant an, aber zu den Profildokumenten, du musst dann quasi für jede Datenbank die Sprache explizit abändern, oder?
Wie ist es wenn sehr viele User mit der Datenbank arbeiten und jeder hat sein eigenes Profil, leidet dann nicht auch die Performance? (Ich muss ganz ehrlich zugeben, ich habe noch nicht wirklich mit persönlichen Profildokumenten gearbeitet...)

Gruß

Andreas

[koehlerbv]

Du müsstest schon sehr viele Benutzer haben, wenn Du wegen persönlicher Profildokumente performancemässig etwas merken willst.

Wegen der Spracheinstellung und vieler Datenbanken: Das ist im Bezug auf die NOTES.INI tatsächlich eine gesonderte Überlegung wert. Wenn Du eine zentrale Datenbank hast, bist Du fein raus (und kannst die Spracheinstellung zwischen den Profilen in den einzelnen DBs auch austauschen), ansonsten ist die NOTES.INI sicherlich das kleinere Übel.

Bernhard

[LordKiri]

Das mit der zentralen Datenbank hört sich gut an, macht ja auch Sinn alles nur einfach zu pflegen sonst läuft es auseinander...

Wie würdest du die Profildokumente zwischen den DBs austauschen?
Meine Idee ist gerade, beim Anlegen eines neuen Profils dieses in die zentrale Datenbank schieben und von dort aus an alle anderen weitergeben.
Oder beim Öffnen einer Datenbank in der zentralen Datenbank nachfragen ob es ein Profildokument für den User gibt.

Gibt es eine Möglichkeit alle Profildokumente in einer Datenbank auszulesen?

Auf jeden Fall habe ich gerade mein Konzept doch etwas überarbeitet...

[koehlerbv]

Du brauchst einen sinnvollen Austausch der Informationen zwischen den einzelnen DBs und der zentralen DB. Weiters sollte man sich überlegen, ob man dem User die Möglichkeit lässt, für eine Datenbank auch eine divergierende Spracheinstellung zuzulassen.
Ähnliches gilt für Übersetzungsdokumente. Es ist überlegenswert, immer wiederkehrende Begriffe (Speichern, Schliessen, Editieren ...) zentral zu pflegen. Dieses Verfahren hat aber auch Nachteile.

Und ja: Es gibt die Möglichkeit, alle ProfilDocuments einer DB auszulesen - siehe DesignerHelp in der Klasse NotesDatabase 

Bernhard

[LordKiri]

Ok, jetzt habe ich ein konkrete Richtung die ich auf jeden Fall weiterverfolgen werde.

Vielen Dank für die Antworten und Anregungen.

Gruß

Andreas

[LordKiri]

Hallo nochmal...

Zwei Fragen habe ich jetzt doch noch, !!Help!! umgeht eigentlich mehrsprachige Ansichten, in dem einfach keine Spaltennamen angegeben werden, weil sich diese Werte nicht berechnen lassen.

Was macht mehr Sinn, auch keine Spaltennamen angeben oder für die verschiedenen Sprachen verschiedene Ansichten anzulegen?

Und ganz wichtig, vorgegebene Kategorien in Ansichten, die müssen dann quasi in jedem Dokument für alle verfügbaren Sprachen vorliegen => für jede Sprache eine Ansicht, oder gibt es einen anderen (besseren) Weg?

Danke im Voraus

Gruß

Andreas

[koehlerbv]

Das sind jetzt aber zwei Fragen, die nur Du im Rahmen Eurer Anforderungen selbst beantworten kannst, Andreas.

Ad Ansichten: Mit sprachenspezifischen Ansichten legst Du Dir mindestens zwei Eier ins Nest
- Die Anwender können sich nicht selbst weitere Sprachen selbst dazukonfigurieren
- Bei Änderungen steigt Dein Aufwand um den Faktor n

Was die Kategorien angeht: Wie die Inhalte selbst, können auch Kategorien selbst sprachabhängig sein. Ebenso können Sie aber Dingen wie Status-Bezeichnungen entsprechen ("Erledigt", "Offen").
Alternativ kannst Du mit symbolischen Bezeichnern o.ä. arbeiten und hierzu wiederum eine Übersetzungshilfe anbieten (Schaltfläche öffnet Dokument, dass unter den Begriffen die zusammengesammelten Übersetzungen listet).

Bernhard

[Thomas Schulte]

Und ganz wichtig, vorgegebene Kategorien in Ansichten, die müssen dann quasi in jedem Dokument für alle verfügbaren Sprachen vorliegen => für jede Sprache eine Ansicht, oder gibt es einen anderen (besseren) Weg?

Schön wärs, wenn es einen einfacheren Weg (in der klassischen Notes Entwicklung) geben würde. Viel Spaß beim lesen.