Das Notes Forum
Domino 9 und frühere Versionen => ND6: Entwicklung => Thema gestartet von: pippo am 03.10.05 - 12:26:54
-
Hallo,
wie schaut es denn damit aus?
Was muß man machen um eine Notesdatenbank, welche in deutsch entwickelt wurde in einer anderen Sprache zu nutzen?
Wer hat damit Erfahrung?
Grüße, Pippo
-
Wenn Du den Quellcode der Datenbank nicht anpassen willst/kannst/darfst, ist die Domino Global Workbench (DGW) die beste Wahl. Ich habe damit von sehr kleinen (wenige Sprachen und Versionen) bis sehr grossen Projekten (viele Sprachen und häufige Versionswechsel) alles übersetzt.
Falls du interesse hast, kann ich dir einige Tipps zum Einsatz des Tools geben.
Andreas
-
Schönen guten Morgen,
ja ich bitte Dich um einige Tipps
Grüße, Pippo
-
Na dann versuch ich mal in wenigen Worten eine hilfreiche Kurzanleitung:
1. Tool installieren (du findest die Software irgendwo auf den Lotus-CDs, oder auch im Internet) und Doku lesen, weil da stehen wichtige Hinweise zum lokalisieren von Datenbanken drin
2. eine lokale Kopie der zu übersetzenden DB machen (ich erstelle mir dazu aus dem Template eine neue, leere Datenbank)
3. in der DGW diese DB als zu übersetzende DB auswählen (die DGW funktioniert etwas Lotus-untypisch mit Drag&Drop und "komisch" beschriftetet Aktionsbuttons in den Auswahldialogen ... dazu am besten die Hilfe zum Anlegen eines neuen Projektes Schritt für Schritt befolgen)
4. Datenbank übersetzen (Das sind eigentlich viele kleine Schritte, die ich jetzt mal noch nicht erkläre, nur so viel dazu: die DGW erstellt aus deiner zu übersetzenden DB eine sogenannte Tagged DB, in der aller Terme (wirklich alles was zwischen Hochkomma steht, oder in irgendeiner Art als Beschriftung identifiziert wird (also Spaltenüberschriften, Buttonbeschriftungen, ...), durch Platzhalter ersetzt werden. Die Terme finden sich dann in einer von der DGW erstellten Glossary-DB wieder, wo sie von dir in beliebig viele Sprachen übersetzt werden können. Am Ende erstellt die DGW daraus eine neue Datenbank, in der alle deutschen Terme durch die übersetzten ausgetauscht wurden.)
5. mittels der übersetzten DB ein neues Template erstellen und an die Kunden ausliefern (Templatenamen entsprechend anpassen)
Soweit erstmal dazu. Um alles ausführlich darzustellen braucht man eine ganze Weile. Wäre eher was für den Tipps-und-Tricks-Bereich. Wenn es irgendjemand haben will, wäre ich gern bereit eine ausführliche Anleitung zu schreiben.
Andreas
-
Hallo Andreas,
Um alles ausführlich darzustellen braucht man eine ganze Weile. Wäre eher was für den Tipps-und-Tricks-Bereich. Wenn es irgendjemand haben will, wäre ich gern bereit eine ausführliche Anleitung zu schreiben.
ich würde sogar sagen, daß das durchaus ein Thema für den Best Practices Bereich ist. Wenn Du Dir die Arbeit machst, das einmal ausführlich zu beschreiben, sind daran sicher einige Leute sehr interessiert.
Viele Grüße
Andreas
-
Die Arbeit mach ich mir gern.
Andreas
-
Mal eine Verständnisfrage: Im Betreff des Threads ist von Mehrsprachigkeit die Rede. Bisher geht es aber nach wie vor um "Einsprachigkeit" - eben nur in einer anderen Sprache. Das ist also "Übersetzung", aber nicht "Mehrsprachigkeit".
Bernhard
-
Je nachdem was du einstellst, kann man mit der DGW sowohl einfache Übersetzungen aber auch mehrsprachige Datenbanken erstellen. Die Sprachumschaltung geschieht dann über die Datenbankeigenschaften - Mulitlingual Options.
Andreas
-
In Help wurde das ja anders gelöst. Vielleicht wären da auch ein paar Vor- und Nachteile dieser Lösung gegenüber DWS von den Entwicklern interessant.
Ich weiss von meinem alten Arbeitgeber, dass es offenbar einfacher ist, zuerst eine tagged Version zu erstellen, wo alle zu übersetzende Begriffe innerhalb von Spezialzeichen stehen.
Wir hatten dort auch die Konvention, dass zu übersetzende Fehlermeldungen oben in den Funktionen der Skripte einer Variable zugewiesen wurden.
Ausserdem gab es dort in den DWS-Datenbanken noch ein paar extra Ansichten.
Ich fand dieses ganze DWS-Verfahren immer unnötig aufwendig. In .NET und in Java gibt es viel besser zu managende Wege der Internationalisierung.
-
Vorteil der !!HELP!! Lösung:
Designelement sind nur 1 x vorhanden
Änderungen an bestehenden Labels und Texten können ohne grossen Aufwand vorgenommen werden
Neue Sprachen sind einfach zu implementieren
NACHTEIL:
In einigen Designelementen ( SpaltenHeader, TabbedTabels ) funktioniert die Methode nicht. Bei den TabbedTables haben wir das über Tabellen und Zellengrafiken gelöst.
Bei gemeinsamen Aktionen ist ein grosser Overhead an Code erforderlich.
-
Hallo,
ich möchte auch noch ein paar Worte dazu sagen.
Meine Datenbanken haben einen ähnlichen Mechanismus wie die "eknori"-Lösung. Ein paar der Nachteile kann man aber umgehen.
So habe ich zum Beispiel jede Ansicht für jede Sprache einmal (ähnlich wie in der DGW). Allerdings werden die Ansichten immer über einen kleinen Agenten geöffnet, der dann anhand der aktuellen Sprache immer genau die richtige Ansicht auswählt. Mit ein paar Tools kann man die Ansichten autmoatisch erstellen lassen (siehe anderen Thread von mir, wo ich mich gerade über die Maskenformel aufgeregt habe... :-[). Bei den TabLabels has Du ja bereits eine Lösung in Deiner HELP-Anwendung.
Ich denke ein entscheidender Vorteil dieser Lösung gegenüber der DGW-Lösung, ist, dass der Benutzer jederzeit zwischen den verschiedenen Sprachen umschalten kann und nicht auf den Spracheintrag in der ID festgelegt ist. Allerdings ist es Entwicklungstechnisch ein bisschen mehr Aufwand, der sich aber dann relativiert, wenn weitere Sprachen dazu kommen. Das passiert dann einfach nur durch ein zusätzliches Konfigurationsdokument.
Ich habe auch schon ein paar Datenbanken mit der DGW bearbeitet und man muss da auch genau aufpassen was man übersetzt und was nicht. Andreas wird das in seinem BestPractice-Artikel sicher genau darauf eingehen - das Ausklammer der nicht zu übersetzenden Terme hat ihn auch schon einige Stunden gekostet. Und da ich kein Freund der _ Notation bin und lieber sText anstatt s_Text schreibe, können nicht zu übersetzende Terme nur schwer erkannt werden, so dass der Aufwand hier auch nicht wesentlich höher ist, als bei der obigen Lösung.
Und als letzter Punkt (das sollte man nicht unterschätzen) kommt noch dazu, dass ich bei einer selbst entwickelten Lösung ziemlich genau weiß, was das System macht, während ich da bei einer Übersetzung mit dem DGW nicht immer ganz sicher bin... ;)
So, wollte nur mal meine Meinung dazu kundtun.
Gruß,
Joachim