[Uwe]

Unter http://www.72arts.com/en/translating-and-author-it.html auf meiner Website finden Sie das komprimierte Archiv Tutorial for Workgroup Edition.zip. Das Archiv enthält ein Lernprogramm in MS-Hilfeformat (in Englisch) zur Übersetzung von Dokumenten, die mit Author-it publiziert wurden, aber ohne den Localization Manager übersetzt werden sollen.
Ich habe mich hierbei auf die technischen Verfahren konzentriert, die unter Verwendung von SDL Synergy ausgeführt werden müssen. Des Weiteren wurden eine Richtlinie zur Qualitätssicherung und ein Allgemeines Lernprogramm zur Lokalisierung eingeschlossen.

Ist villeicht von Nutzen.

Uwe

[Petra Mangold]

Hallo,
ich bin sehr an Übersetzungen ohne LM interessiert.
Habe den LM in V4 immer genutzt da dort in der Professional Version wohl eine test Lizenz für eine Sprache zur Verfügung stand, wobei mir nie klar war das es nur eine Test-Lizenz war, wie jetzt von AIT behauptet wird.

Ab V5 geht das also nicht mehr, aber für meine one-woman-show mit 2 Sprachen ist eine LM Lizenz einfach zu teuer!

Habe also bereits 2 DB's, aber bei nachträglich manuelles importieren in der Übersetzungs DB werden die topic ID's neu vergeben und damit wird eine Kontextrelevante Verknüpfung über die topic ID unmöglich, da ich für beide Sprachen stets unterschiedlich ID's implementieren müsste.

Ich weiß das die Verknüpfung intern nur über die GUID's läuft, warum kann ich die Topic ID's also nicht manuell abändern in AIT?
Ich mache das bis jetzt immer mit einem direkt Zugriff auf der DB mit MS Access aber das ich doch recht umständlich

Gute Ideen sind also willkommen!
Danke...

[helmut seeger]

1. beim import von datenbankobjekten wird leider immer eine neue id vergeben. da lässt sich nix machen.
nur beim xml ex- und import können die objekte gemappt werden.
2. nur als hinweis: das LM-Lizenzmodell hat sich ab 5.0 geändert. Die Lizenzkosten berechnen sich jetzt pro Sprache. ich bin mir allerdings nicht sicher, wie zuverlässig der LM in der Version 5 derzeit ist.

helmut

[Anke]

Hallo, Petra,

damit die Topics auch nach dem Import in eine andere Datenbank kontexsensitiv bleiben, nehmen wir nicht die Objekt-ID, sondern die ContextID. Die findest du bei jedem Topic im Register "Windows Help", Unterregister "Linking". Diese Context ID bleibt beim Im- und Exportieren unverändert, sodass du mit zwei Datenbanken arbeiten kannst. Wichtig ist: Die Context-ID VOR dem Export pflegen!!!

Da für uns der LM auch zu teuer ist, haben wir uns zu diesem Weg entschlossen.

Weitere Infos findest du hier:
[url]Für die Hilfe-anbindung werden wir dann die ContextID verwenden[/url]

Viel Erfolg und viele Grüße,

Anke

[helmut seeger]

Anmerkung: Unser Schwesterunternehmen verwendet diese Vorgehensweise. Sie erfordert eine durchdachte Nummernkreispflege und Abstimmung mit der Entwicklung. Am besten ein Excel-Sheet oder ähnliches führen und in den Nummernkreisen genügend Platz für neue Masken lassen.

Was mich aber eigentlich interessiert: wie identifiziert man bei dieser Übersetzungsweise die geänderten Topics?
Das Datum als alleiniges Kriterium scheint mir ein wenig unzuverlässig zu sein.
Release 5 könnte da über die Variantenlösung evtl. ein wenig mehr Unterstützung bieten.

[Petra Mangold]

Hallo Anke,
Danke für den Tipp mit dem linken und die Context-ID, das werde ich mal versuchen!

Werde allerdings zuerst das Feld noch ausführlich mit Leben füllen müssen, befürchte ich:-(
Muss ich zuerst wohl doch noch mit Acces ran, damit ich die Context-ID = Object- ID setze, denn ansonsten werden meine Entwickler nicht wirklich happy sein wenn die Nummern alle geändert werden...
(Unter V4 habe ich immer mit den LM arbeiten können, weil das irgend wie für eine Sprache immer freigeschaltet war in der Enterprize version, ohne Vorwarnung ist das bei V5 nun auf einmal nicht mehr möglich - V4 ist aber nicht Vista tauglich)

Listen führen ist nicht so meins, ich werde also einfach die Object-ID von meine führenden Lib als Leitfaden nehmen und die ab jetzt übernehmen.

Was die Erkennung der Topics für Übersetzungen angeht verwende ich immer die 'Release states'. Die muss ich zwar von Hand zurück setzen, aber da ich danach sortieren kann geht das recht fix und alle gleichzeitig. Für das nachpflegen von Änderungen an bestehende topics tue ich das auch, aber das funktioniert denke ich nur bei mir weil ich alles alleine mache. An sonsten kommt mann wohl nicht um die Versionierung herum, ich konnte mich da aber bis jetzt noch nicht mit anfreunden, mir reichen die Stati....

Frohes schaffen.
Petra

[Anke]

Hallo Petra, hallo Helmut,

wir führen auch keine separaten Listen, sondern haben - so, wie du das auch geplant hast, Petra - ganz einfach die Context-ID = Object-ID gesetzt.

Was eine Delta-Übersetzung angeht: Davor graut mir ein bisschen. Helmut, um deine Frage zu beantworten: wir haben bisher das Datum als Kriterium verwendet. Wenn man einmal einen Export und Import in eine andere DB gemacht hat, sollte man aber zum Beispiel ganz vorsichtig sein mit dem Ändern von Object Templates. Denn dann bekommen alle Topics, obwohl sie inhaltlich gleich geblieben sind, ein aktuelles Datum und würden beim nächsten Export eben auch exportiert. Von daher hast du recht: Das Kriterium ist nicht 100%ig sicher.
Da wir aber eine Übersetzerin gefunden haben, die mit Across arbeitet, wäre ein Export von bereits übersetzten Topics auch nicht furchtbar schlimm, weil hier das TMS verhindert, dass Topics mehrfach übersetzt würden, weil es eben die entsprechenden "Matches" findet.
@Petra: Du solltest auf jeden Fall noch mal prüfen, ob AIT geänderte Context IDs bei einem Export aus der UrsprungsDB mit anschließendem Import in die ÜbersetzungsDB tatsächlich korrekt verarbeitet.... Deshalb haben wir sicherheitshalber darauf geachtet, dass vor dem ersten Export/Import ALLE Context-IDs eingegeben waren.
Ansonsten gibt's noch mal ein paar Links (der eine hat irgendwie nicht richtig funktioniert.... - hoffe, dass es jetzt funktioniert!)

übersetzen ohne LM

http://www.author-it.de/forum/viewtopic.php?p=2752&highlight=#2752

Context-ID/Object-ID

http://www.author-it.de/forum/viewtopic.php?t=1387&highlight=
http://www.author-it.de/forum/viewtopic.php?t=834&highlight=

Ansonsten euch beiden frohes Schaffen und viele Grüße in mein altes Domizil KA.

Anke

[Petra Mangold]

Hallo Anke,
danke für den Tipp bezüglich den import/export. Ich importiere allerdings direkt von Lib aus Lib, da ich ja hauptsächlich eine one woman show durch ziehe und da habe ich grade einen Test durchgeführt und kann sagen das dann die Context-ID auf jeden Fall erhalten bleibt

Ich habe gestern Abend noch schnell (nachdem ich endlich das richtige Feld gefunden hatte) mit SQL die Context-ID = Object-ID für den knapp 800 Topic Objekte in beide Libs gesetzt.
Muß jetzt von Hand nur noch 15 Topics korrigieren oder so, weil dort das original und die Übersetzung bereits aus einander gehen. (Könnte zwar auch wieder direkt in der Datenbank teils Manuell und anschließend mit SQL die Unterschiedliche Object ID's wieder gleich setzten, aber das ist doch recht aufwendig und gefährlich und für als standard Arbeitsvorgang einfach ungeeignet.)

Wenn jetzt die Context ID auch noch ansprechbar ist bin ich ja gerettet.

Die Frage ist vor allem wie ich aus Delphi heraus die ID anspringe - ob wir da etwas ändern müssen oder das AIT beim generieren immer nur die Object-ID nimmt wenn kein Context-ID vorhanden....
Das ich die Antwort nicht kenne, muss ich das wohl mittels trial and error noch mit den Entwickler ausprobieren. Es sei den Du weißt das zufällig auch noch

[Anke]

Hallo Petra,
da solltest du zur Entwicklung gehen - unser Entwickler hat das superschnell gemacht. Allerdings habe ich mich da nicht im Detail eingearbeitet, weil ich hauptsächlich auf der AIT-Seite den Arbeitsablauf geprüft habe.... Ich glaube der Hilfeaufruf funktioniert über Object- und Context-ID. Vielleicht ist die Syntax etwas unterschiedlich, aber die Entwicklung weiß das sicherlich....
Sind bei dir denn in beiden Datenbanken die Object-IDs identisch, sodass du per SQL Object-Id = Context-ID setzen konntest??? Das war dann ja sehr praktisch!

Außerdem hast du mich mit den Release-States auf eine Idee gebracht, die ich weiter verfolgen werde. Das praktische an den Release States ist, dass ich sie als Suchkriterium verwenden kann und so für einen Export die gewünschten Topics suchen kann. Versionen lassen sich nämlich nicht als Suchkriterium verwenden und bei Versionen habe ich auch immer mehrere Versionen in der DB, aber nur eine einzige ist aktiv. Hast du noch ein paar Tipps zu den Release States in Bezug auf Übersetzungs-Workflow ohne LM? Werden die Release States bei einem Export mitgenommen und in die UbersetzungsDB importiert? Wann änderst du dann die Release States in der deutschen DB? Und wann in der ÜbersetzungsDB? Wenn du Lust hast, wäre ich für ein paar Tipps dankbar!

viele Grüße, Anke

[Petra Mangold]

Hallo Anke,
Ja, bei mir waren die Object ID's weitgehend gleich, da ich wie gesagt unter V4 mit der Enterprize Version mit dem LM arbeiten konnte (um genau zu sein war der LM - und die Release states- für uns der Grund damals auf die Enterprize Version zu wechseln, aber das will ja jetzt natürlich keiner mehr wissen....)
Daher konnte ich meine ID's einfach auf beide Seiten verwenden und muß nur die letzte 15 Stück oder so manuell ändern.

Was die Release states betrifft mach ich (wenn ich ganz brav und gewissenhaft bin) folgendes:
Ich habe einen State 'Released' für alles was Frei gegeben ist.
Sobald ich an ein bestehender topic etwas ändere wechsele ich den Status auf 'geändert' wenn die Änderung vollständig ist, wenn nicht kennzeichne ich das Topic als 'Draft', damit ich weiß wo ich dran bin.
Sobald ich ein neues Topic anlege bekommt das (nachdem der 'Draft' status nicht mehr gilt) der Status 'Übersetzen'.
Wenn ich dann die Übersetzung überprüfen, schaue ich welche Topics in der original Lib auf 'geändert' stehen, einfach indem ich beide Libs in separate AIT Sessions neben einander auf mache (ich besitze 2 Lizenzen, damit ich ggf. ein Kollege meine deutsche Gramatik und manchmal abenteuerliche Sätze etwas ein deutschen lassen kann...).

Sobald ich merke das topics fehlen, importiere ich alle topics mit dem Status 'Übersetzen'.
Leider wird dieser Status beim direkten Import nicht übernommen, aber da alle zuletzt importierte topics zusammen ganz unten aufgelistet werden, können die ganz einfach wieder den Status 'Übersetzen' verpasst bekommen.
Nach dem Import müssen die Topics im haupt lib natürlich einen neuen Status bekommen, aber da nach status sortiert werden kann ist das ja nicht weiter aufwendig.

Der vorteil vom LM war natürlich das auch die ganze Hyperlinks und Co automatisch aktualisiert wurden, aber da ich die für die Kontext hilfe nicht brauche werde ich die wohl ab jetzt entweder manuell erzeugen müssen oder auch einfach imporieren. Das wird sich zeigen.
Des weiteren habe ich mir noch angewöhnt die geänderte Bereiche in bestehende Topics wie folgt zu kennzeichnen:
Am Anfang '###' und am Ende der Änderung '####', diese Merkierung weise ich dann ein Format zu das Rot aufleuchted UND in keines der Publishing Formate auftaucht, damit ich das original einfach verwenden kann, ohne angst zu haben das komische Zeichen auftauchen (Ich nutze das Format z.B. auf für interne Bemerkungen wonach ich später suchen kann)

In der Übersetzungs lib gehe ich dann ähnlich vor, damit die Topics die jemand überprüfen soll leicht zu identifizieren sind, auch dort verwende ich wieder meine ### wenn ich nur kleine Abschnitte abgeändert habe.

Ich hoffe das ich mich klar genug ausgedruckt habe und das es eine oder andere Brauchbare Idee für Dich dabei ist.

Frohes schaffen.....
Petra

[Zhoe]