Domino 9 und frühere Versionen > ND8: Entwicklung

Mehrsprachigkeit und Verständnisproblem !!Help!!

(1/3) > >>

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

Navigation

[0] Themen-Index

[#] Nächste Seite