[jboss-cvs] JBossAS SVN: r76266 - projects/docs/enterprise/4.3/Transactions/Programmers_Guide/de-DE.

Sun Jul 27 17:31:08 EDT 2008

Author: jdimanos at jboss.com
Date: 2008-07-27 17:31:07 -0400 (Sun, 27 Jul 2008)
New Revision: 76266

Modified:
   projects/docs/enterprise/4.3/Transactions/Programmers_Guide/de-DE/Chapter.po
Log:
update

Modified: projects/docs/enterprise/4.3/Transactions/Programmers_Guide/de-DE/Chapter.po
===================================================================

--- projects/docs/enterprise/4.3/Transactions/Programmers_Guide/de-DE/Chapter.po	2008-07-27 21:27:47 UTC (rev 76265)
+++ projects/docs/enterprise/4.3/Transactions/Programmers_Guide/de-DE/Chapter.po	2008-07-27 21:31:07 UTC (rev 76266)
@@ -8,7 +8,7 @@
 "Project-Id-Version: Chapter\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-06-05 22:51+0000\n"
-"PO-Revision-Date: 2008-07-27 12:08+1000\n"
+"PO-Revision-Date: 2008-07-28 07:30+1000\n"
 "Last-Translator: Jasna Dimanoski <jdimanos at redhat.com>\n"
 "Language-Team:  <de at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -50,7 +50,7 @@
 #: Chapter.xml:14
 #, no-c-format
 msgid "TxCore – the transaction engine"
-msgstr "TxCore – die Transaction Engine"
+msgstr "TxCore – die Transaction-Engine"
 
 #. Tag: para
 #: Chapter.xml:16
@@ -73,7 +73,7 @@
 "emphasis> (TXOJ) classes are being used. If this is not the case then the "
 "programmer is responsible for all of these issues."
 msgstr ""
-"Wenn im Handbuch die Rede von der Verwendung von Facilities zur Persistenz und Nebenläufigkeitskontrolle ist, so wird von der Verwendung der Klassen von <emphasis>Transaktionalen Objekten für Java</"
+"Wenn im Handbuch die Rede von der Verwendung von \"Facilities\" zur Persistenz und Nebenläufigkeitskontrolle ist, so wird von der Verwendung der Klassen von <emphasis>Transaktionalen Objekten für Java</"
 "emphasis> (TXOJ) ausgegangen. Ist dies nicht der Fall, so ist der Programmierer für alle diese Aspekte verantwortlich."
 
 #. Tag: para
@@ -135,13 +135,13 @@
 msgstr ""
 "<classname>TxCore</classname> muss aus verschiedenen Gründen dazu in der Lage sein, sich an den Status eines Objekts - darunter auch Recovery (der Status repräsentiert einen vergangenen Status des Objekts) und Persistenz (der Status repräsentiert den endgültigen Status eines Objekts zum Zeitpunkt der Beendigung der Anwendung) - zu erinnern. Da diese Anforderungen gemeinsame Funktionalitäten besitzen, werden sie alle unter Verwendung desselben Mechanismus implementiert: die Klassen <classname>InputObjectState</classname> und <classname>OutputObjectState</classname>. Die Klassen warten ein internes Array, in das unter Verwendung der entsprechenden <command>pack</command> (<command>unpack</"
 "command>) Operationen durchgängig Instanzen des Standard-Typs gepackt (entpackt) werden. Die Größe dieses Zwischenspeichers wird automatisch und wie erforderlich angepasst, falls nicht ausreichend Platz verfügbar ist. Sämtliche Instanzen werden in einem Standardformular (die sogenannte \"Network Byte Order\") im Zwischenspeicher gespeichert, damit sie unabhängig von der verwendeten Maschine sind. Jedes andere architekturunabhängige Format (wie XDR "
-"oder ASN.1) könnte einfach implementiert werden, indem die Operationen durch der benötigten Codierung entsprechende ersetzt werden."
+"oder ASN.1) könnte einfach implementiert werden, indem die Operationen durch die der benötigten Codierung entsprechende ersetzt werden."
 
 #. Tag: title
 #: Chapter.xml:43
 #, no-c-format
 msgid "The object store"
-msgstr "Der \"Object Store\""
+msgstr "Der Objektspeicher (\"Object Store\")"
 
 #. Tag: para
 #: Chapter.xml:45
@@ -156,7 +156,7 @@
 "services."
 msgstr ""
 "Implementierungen von Persistenz können von durch den Java SecurityManager gemachten Einschränkungen betroffen sein. Der mit "
-"<classname>TxCore</classname> gelieferte Object Store ist daher unter Verwendung von Techniken von Interface/Implementierung implementiert. Die aktuelle Distribution besitzt Implementierungen, die Objekt-Stati in das lokale Dateisystem oder Datenbank schreiben und Remote Implementierungen, bei denen das Interface einen Client-Stub (Proxy) bei Remote-Diensten verwendet."
+"<classname>TxCore</classname> gelieferte Objektspeicher (\"Object Store\") ist daher unter Verwendung von Techniken von Interface/Implementierung implementiert. Die aktuelle Distribution besitzt Implementierungen, die Objekt-Stati in das lokale Dateisystem oder Datenbank schreiben und Remote-Implementierungen, bei denen das Interface einen Client-Stub (Proxy) bei Remote-Diensten verwendet."
 
 #. Tag: para
 #: Chapter.xml:47
@@ -173,7 +173,7 @@
 #: Chapter.xml:53
 #, no-c-format
 msgid "Recovery and persistence"
-msgstr "Recovery und Persistenz"
+msgstr "Wiederherstellung (\"Recovery) und Persistenz"
 
 #. Tag: para
 #: Chapter.xml:54
@@ -430,7 +430,7 @@
 "persistent object in <emphasis>TXOJ</emphasis> is shown in <xref linkend="
 "\"figure_2\"/>."
 msgstr ""
-"Man geht davon aus, dass ein nicht in Gebrauch befindliches persistentes persistent Objekt in einem <emphasis>passiven</emphasis>-Status gehalten wird, wobei dessen Status sich in einem Object Store befindet und auf Abruf <emphasis>aktiviert</emphasis> wird. Der fundamentale Lebenszyklus eines persistenten Objekts in <emphasis>TXOJ</emphasis> ist in <xref linkend="
+"Man geht davon aus, dass ein nicht in Gebrauch befindliches persistentes Objekt in einem <emphasis>passiven</emphasis>-Status gehalten wird, wobei dessen Status sich in einem Objektspeicher befindet und auf Abruf <emphasis>aktiviert</emphasis> wird. Der fundamentale Lebenszyklus eines persistenten Objekts in <emphasis>TXOJ</emphasis> ist in <xref linkend="
 "\"figure_2\"/> dargestellt."
 
 #. Tag: caption
@@ -445,7 +445,7 @@
 msgid ""
 "The object is initially passive, and is stored in the object store as an "
 "instance of the class <classname>OutputObjectState</classname>."
-msgstr "Das Objekt ist ursprünglich passiv und wird als eine Instanz der Klasse <classname>OutputObjectState</classname> im Object Store gespeichert."
+msgstr "Das Objekt ist ursprünglich passiv und wird als eine Instanz der Klasse <classname>OutputObjectState</classname> im Objektspeicher gespeichert."
 
 #. Tag: para
 #: Chapter.xml:87
@@ -456,7 +456,7 @@
 "operation and is then converted from an <classname>InputObjectState</"
 "classname> instance into a fully-fledged object by the "
 "<command>restore_state</command> operation of the object."
-msgstr "Wenn durch eine Anwendung erforderlich, wird das Objekt automatisch aktiviert, indem es durch einen <command>read_committed</command>-Vorgang aus dem Store gelesen und dann durch den <command>restore_state</command>-Vorgang von einer <classname>InputObjectState</classname>-Instanz in ein vollwertiges Objekt konvertiert wird."
+msgstr "Wenn durch eine Anwendung erforderlich, wird das Objekt automatisch aktiviert, indem es durch einen <command>read_committed</command>-Vorgang aus dem Speicher gelesen und dann durch den <command>restore_state</command>-Vorgang von einer <classname>InputObjectState</classname>-Instanz in ein vollwertiges Objekt konvertiert wird."
 
 #. Tag: para
 #: Chapter.xml:88
@@ -474,7 +474,7 @@
 msgstr ""
 "Ist die Anwendung mit dem Objekt fertig, so wird dieses durch Rückkonvertierung in eine <classname>OutputObjectState</classname>-Instanz "
 "mittels der <command>save_state</command>-Operation deaktiviert, und wird dann mittels write_uncommitted als \"Schattenkopie\" "
-"in den Object Store gespeichert. Diese Schattenkopie kann festgeschrieben werden, in dem die vorangegangene Version mittels "
+"in den Objektspeicher gespeichert. Diese Schattenkopie kann festgeschrieben werden, in dem die vorangegangene Version mittels "
 "<command>commit_state</command>-Operation festgeschrieben wird. Die Existenz von Schattenkopien wird normalerweise durch das Transaktionssystem vor dem Programmierer verborgen. Objekt-Deaktivierung erfolgt normalerweise nur dann, wenn die Transaktion der höchsten Ebene, innerhalb derer das Objekt aktiviert wurde, festgeschrieben wird."
 
 #. Tag: para
@@ -505,7 +505,7 @@
 "available to interfaces include:"
 msgstr ""
 "Der Nebenläufigkeits-Controller wird durch die Klasse "
-"<classname>LockManager</classname> implementiert, die ein vernünftiges Standardverhalten liefert und dem Programmierer gleichzeitig gestattet dieses außer Kraft zu setzen, falls es aufgrund der bestimmten Semantik programmierten Klasse erforderlich sein sollte. Wie mit <classname>StateManager</classname> und Persistenz, wird auch auf die Implementationen der Nebenläufigkeitssteuerung über Interfaces zugegriffen. Neben Zugriff auf Remote Dienste beinhalten die aktuellen Implementierungen von für Interfaces verfügbare Nebenläufigkeitssteuerung:"
+"<classname>LockManager</classname> implementiert, die ein vernünftiges Standardverhalten liefert und dem Programmierer gleichzeitig gestattet dieses außer Kraft zu setzen, falls es aufgrund der bestimmten Semantik der programmierten Klasse erforderlich sein sollte. Wie mit <classname>StateManager</classname> und Persistenz, wird auch auf die Implementierungen der Nebenläufigkeitssteuerung über Interfaces zugegriffen. Neben Zugriff auf Remote-Dienste beinhalten die aktuellen Implementierungen von für Interfaces verfügbare Nebenläufigkeitssteuerung:"
 
 #. Tag: para
 #: Chapter.xml:101
@@ -513,7 +513,7 @@
 msgid ""
 "local disk/database implementation, where locks are made persistent by being "
 "written to the local file system or database."
-msgstr "local disk/database Implementierung, wo Sperren persistent gemacht werden, indem sie in das lokale Datensystem oder die Datenbank geschrieben werden."
+msgstr "lokale Disk/Datenbank Implementierung, bei der Sperren persistent gemacht werden, indem sie in das lokale Datensystem oder die Datenbank geschrieben werden."
 
 #. Tag: para
 #: Chapter.xml:102


