Die Prinzipien der Dokumentation und Lokalisierung oder wie man eine gute Lokalisierung bei minimalen Kosten erzielt

Hallo allerseits!

Ich heiße Denisov Alexander. Ich arbeite für Naumen und bin verantwortlich für die Dokumentation und Lokalisierung des Naumen Contact Center (NCC) -Softwareprodukts.

In diesem Artikel werde ich über die Probleme sprechen, die bei der Lokalisierung von NCC auf Englisch und Deutsch aufgetreten sind, und wie wir diese Probleme gelöst haben. Natürlich haben wir heute weit entfernt von all unseren Aufgaben gelöst, und höchstwahrscheinlich ist dieser Prozess im Allgemeinen endlos. Der Artikel betrachtet die Vision des gesamten Prozesses als Ganzes und die Prinzipien, an die wir uns halten wollen oder die wir allmählich anzuwenden versuchen. Das Material ist nützlich für diejenigen, die gerade erst mit dem Entwerfen von Software beginnen, deren Lokalisierung planen oder bereits mit Problemen konfrontiert sind, aber noch nicht wissen, wie sie diese lösen sollen.

Einleitung

Oft denkt ein Unternehmen über Softwarelokalisierung nach, wenn das Produkt fertig ist und eine Dokumentation dafür geschrieben wurde. Und es ist auch oft zu spät, etwas zu tun, um in kurzer Zeit eine gute Lokalisierung zu erreichen und nicht viel Ressourcen dafür aufzuwenden.

Es ist unmöglich, in einem Artikel ausführlich über alle Probleme und Schwierigkeiten zu schreiben, daher werde ich ein wenig über die Hauptphasen der Dokumentation und Lokalisierung sprechen und meiner Meinung nach einige der wichtigsten Themen ansprechen:

• Welche Phasen des Softwareentwicklungslebenszyklus wirken sich auf die Qualität der Dokumentation und Lokalisierung aus?
• Was und wann in jeder Phase?
• Welche Ansätze und Fähigkeiten von Werkzeugen können verwendet werden, um Probleme und Probleme jeder Phase zu lösen?
• Wie eine org. Beeinflusst die Struktur die Dokumentation und Lokalisierung?
• Wie organisiere ich das Empfangen von Feedback von Benutzern der Dokumentation?
• Wie können Sie in jeder Phase Zeit und finanzielle Kosten sparen?

Aufgrund meiner langjährigen Erfahrung in der Dokumentation und Lokalisierung von NCC werde ich versuchen, diese Fragen zu beantworten.

Merkmale von NCC und des Entwicklungsprozesses

Das Naumen Contact Center ist eine hochentwickelte Software zur Organisation großer Unternehmens- oder Outsourcing-Contact Center.

Was ist die Schwierigkeit, dieses System zu dokumentieren und zu lokalisieren:

1. Das System ist nicht bewölkt.
2. Komplexer Aufbau, viele Integrationen mit verschiedenen Systemen.
3. Unterstützung für mehrere Versionen.
4. Aufgrund der Absätze 1 bis 3 verfügen wir über komplexe Implementierungen und Aktualisierungen. Jeder Client hat seine eigene Version, seine eigene Konfiguration und Integration in verschiedene Systeme.
5. Das System ist nicht massiv, es wird nur von großen Unternehmen verwendet. Daher ist die Anzahl der Kunden im Vergleich zu kleinen Massenprodukten nicht sehr groß.
6. Eine große Anzahl spezifischer Begriffe.
7. Mehrrollenmodell. Dies bedeutet, dass die Dokumentation und die Benutzeroberfläche auf die Merkmale jeder Rolle (Wissensstand und Merkmale der Aufgaben) zugeschnitten sein müssen.
8. Systemschnittstellen enthalten ca. 30.000 Textzeilen und ca. 3.000 Seiten komplexer technischer Dokumentation.
9. Veröffentlichungen werden 2-3 mal im Jahr veröffentlicht.
10. Nach jeder Version werden ungefähr 10% des Textes und der Dokumentation der Benutzeroberfläche aktualisiert und ergänzt.
11. 3 Sprachen: Russisch (Quelle), Englisch und Deutsch.

Entwicklungslebenszyklus

Lassen Sie uns den Lebenszyklus der Softwareentwicklung betrachten und nur die Phasen auswählen, die sich auf Dokumentation und Lokalisierung beziehen:

• Funktionsentwicklung. Im Rahmen dieser Phase werden Texte für die Schnittstelle entwickelt.
• Dokumentation Im Rahmen dieser Phase wird die Dokumentation entwickelt, einschließlich der Erstellung von Screenshots und anderen Bildern.
• Lokalisierung der Schnittstelle in mehreren Sprachen.
• Übersetzung der Dokumentation in andere Sprachen, einschließlich Lokalisierung von Screenshots und anderen Bildern.

Stellen wir uns nun vor, dass ein kleiner Fehler in der Benutzeroberfläche gemacht wurde. Es gilt automatisch für jede Stufe, für mehrere Versionen und Sprachen.



In jeder Phase können zusätzliche Fehler auftreten, das heißt, wir können eine große Anzahl von Fehlern erhalten. Kleinere Schnittstellenfehler werden höchstwahrscheinlich nie behoben, es gibt immer wichtigere Aufgaben. Und wenn Sie sie bearbeiten, sind die Kosten für diese Änderungen sehr hoch, da Sie erneut die gesamte Kette, alle Versionen und Sprachen durchlaufen müssen. Und je mehr Versionen und Sprachen, desto teurer.

In diesem Zusammenhang kann man nicht nur über die Qualität der Lokalisierung der Schnittstelle oder über die Qualität der übersetzten Dokumentation sprechen, da das Ergebnis der Arbeit jeder Stufe die Grundlage für die nächste Stufe ist. Deshalb ist es sehr wichtig, in jeder Phase sofort alles richtig zu machen. Aus diesem Grund lohnt es sich, Softwareentwicklung, Dokumentation und Lokalisierung als Phasen eines einzigen untrennbaren Prozesses zu betrachten.

Organisation von Text in der Oberfläche

Als unsere Programmierer die Lokalisierung des Systems aufnahmen, war es dafür absolut nicht bereit. Der Text der Benutzeroberfläche wurde im Code gespeichert, und der Wunsch des Managements lautete: "Alles schnell erledigen." Die Programmierer schrieben ein Skript, das den gesamten Text aus dem Code herausholte und in die Ressourcendateien warf. Am nächsten Tag gaben sie die Ressourcendateien an den ersten Mitarbeiter weiter, der Englisch konnte und der schnell alles in den Notizblock übersetzte. Was dabei herauskam, ist unten zu sehen.



Das Bild zeigt eine einfache Schaltfläche, es öffnet sich ein Formular mit Parametern, in dem diese Parameter geändert werden können. Es gibt Dutzende solcher Tasten im System. Auf Russisch gab es 3 Optionen für eine solche Schaltfläche, die Lokalisierung ins Englische enthielt bereits 7 Optionen.

In dieser Situation besteht sofort ein großer Wunsch, die Leitungen der Schnittstelle zu bereinigen. Dazu schlage ich vor, folgende Regeln anzuwenden:

• Aufteilung aller Linien in Gruppen.
  
  Alle Zeilen sollten je nach Art der Schnittstellenelemente in Gruppen unterteilt werden. Selbst wenn die Zeilen denselben Text enthalten, können für verschiedene Gruppen unterschiedliche Übersetzungsregeln gelten. Zum Beispiel die Großschreibregel für den ersten Buchstaben jedes Wortes in Englisch. Für einige Arten von Schnittstellenelementen wird es verwendet, für andere nicht.
• Duplikate entfernen.
  
  In jeder Gruppe ist es sinnvoll, alle doppelten Zeilen zu löschen, dh Zeilen mit demselben Text. Dann gibt es die einzige Option sowohl in Russisch als auch in anderen Sprachen. Dies spart Übersetzungskosten. Ich stelle fest, dass die wiederholten Zeilen höchstwahrscheinlich immer noch bestehen bleiben, da der Kontext in einigen Fällen unterschiedlich sein kann. Darüber hinaus können solche Zeilen mit demselben Quelltext auf unterschiedliche Weise übersetzt werden. Beispielsweise kann das Wort Name im Kontext des Namens einer Person als Vorname und im Kontext eines Dateinamens einfach als Name übersetzt werden .
• Hinzufügen von Kontext zu Zeilenbezeichnern.
  
  Die Leitungskennung kann aus der Kennung der Leitung selbst und der Gruppe bestehen, zu der die Leitung gehört. Dies ist erforderlich, damit der Übersetzer den Bezeichner verwenden kann, um eine Lokalisierungsregel auszuwählen. Wenn wir solche korrekten Kennungen haben, kann der Prozess der Überprüfung und Korrektur derselben Großschreibungsfehler leicht automatisiert werden.

Leider ist es sehr zeitaufwändig, diese Regeln auf alle vorhandenen 30.000 Leitungen gleichzeitig anzuwenden. Hier befinden wir uns im Anfangsstadium und ordnen nach und nach die am häufigsten wiederholten Zeilen und entwickeln Regeln für neue Zeilen. Aber Sie müssen zugeben, es wäre super, wenn alle Regeln sofort formuliert und umgesetzt würden!

Dokumentations- und Lokalisierungsprozess

Werfen wir einen Blick auf den zeitbasierten Dokumentations- und Lokalisierungsprozess. Wenn Sie mit der Dokumentation und Lokalisierung beginnen, bevor die Feature-Entwicklung abgeschlossen ist, müssen Sie alles wiederholen (möglicherweise mehrmals).

Gleiches gilt für die Übersetzung von Dokumentationen.

Wenn Sie den Benutzern die Dokumentation geben, bevor alle Änderungen abgeschlossen sind, können Sie sich auf eine Reihe von Kommentaren verlassen. Höchstwahrscheinlich werden einige dieser Kommentare in den letzten Entwicklungsphasen korrigiert, aber Sie müssen zusätzliche Zeit aufwenden, um sie zu verarbeiten.



Wenn die Prozesse nicht koordiniert sind und wir nicht alle Änderungen rechtzeitig verfolgen, entspricht „nichts-nichts-irgendwo“ nicht.

Die Dokumentation stimmt nicht mit der Schnittstelle überein. Screenshots stimmen nicht mit der Benutzeroberfläche und dem Text der Dokumentation überein.



Gleiches gilt für die Lokalisierung. Der Text der Benutzeroberfläche und der Dokumentation in der Ausgangssprache stimmt nicht mit dem Text der Benutzeroberfläche und der Dokumentation in anderen Sprachen überein.



Wir haben beschlossen, dass wir es uns im Moment leisten können, jede neue Etappe erst zu beginnen, nachdem wir die vorherige beendet haben.



Ja, unsere Dokumentation und Lokalisierung erscheinen spät nach der Veröffentlichung. Apropos Lokalisierung: Wir haben bereits die Möglichkeit einer kontinuierlichen Lokalisierung sichergestellt, nutzen diese Gelegenheit jedoch nicht und führen die gesamte Lokalisierung am Ende der Version in einem Schritt durch. Ein paar Tage im Rahmen einer halbjährlichen Veröffentlichung sind eine sehr kleine Phase.

Solange unser Produkt nicht massiv ist, müssen Dokumentation und Lokalisierung nicht dringend am selben Tag erscheinen. Wir haben lange Releases, große Firmenkunden, von denen es im Vergleich zu kleinen und größeren Produkten nicht sehr viele gibt, und sie beginnen nicht sofort mit der Installation einer neuen Version des Produkts oder dem Upgrade darauf. Die Kosten für den ständigen Umbau werden spürbar reduziert.

Terminologieprobleme

In der Phase der Dokumentation und Lokalisierung hatten wir ständig Probleme mit der Terminologie:

• Dieselben Entitäten wurden unterschiedlich genannt, und verschiedene Entitäten wurden gleich benannt.
• Dieselben Begriffe wurden auf unterschiedliche Weise übersetzt, und unterschiedliche Begriffe wurden auf dieselbe Weise übersetzt.
• Eine Entität kann mit ihren untergeordneten Entitäten, aus denen sie besteht, oder übergeordneten Entitäten gleichgesetzt werden.
• Es wurden nicht erfolgreiche oder falsche Begriffe ausgewählt, um eine Entität zu bezeichnen.

Der Entwicklungsprozess sah für uns einige Zeit so aus:

• Analysten schreiben eine Produktion.
• Tester testen die Produktion.
• Entwicklercode.
• Tester testen das Ergebnis.

Und als wir versuchten, uns mit Terminologie in diesen Prozess einzumischen, erhielten wir solche Ausreden:

• Sie werden den gesamten Prozess verlangsamen.
• Dies ist im Allgemeinen nicht so wichtig.
• Sie haben die Werkzeuge, Sie können alles später reparieren.

Aber "später" stellte sich heraus, dass wir nicht alles reparieren können. Beispielsweise gab es Situationen, in denen Systemobjekte aufgrund einer falsch verstandenen Terminologie auf den falschen Hierarchieebenen platziert oder zu falschen Gruppen zusammengefasst wurden.

Jetzt überprüfen wir die Begriffe und den Text der Benutzeroberfläche parallel zum Einstellungstest. Das heißt, während Tester ihre Kommentare schreiben, schreiben wir unsere eigenen.



Was wir während der Produktionstests tun:

• Wir enthüllen neue Begriffe.
• Überprüfen Sie den Text der Benutzeroberfläche: für die korrekte Verwendung von Begriffen, die Einhaltung des Styleguides und die Einhaltung der Rollen.
• Wir identifizieren vorhandene Zeilen, um keine Duplikate zu erstellen.
• Wir sind uns einig über die Notwendigkeit einer Lokalisierung, da einige Teile der Schnittstelle nur in einem Land verwendet werden können.

Wenn wir neue Begriffe enthüllen, fügen wir sie dem Glossar hinzu, während:

• Fügen Sie eine Definition oder einen Kontext hinzu.
• Wir geben die Beziehung zu anderen Begriffen an (geben Sie Eltern- und Kinderbegriffe an).
• Wir versuchen, die englische Bedeutung sofort anzugeben, da nach Auswahl des englischen Namens manchmal klar wird, dass das Russische nicht sehr richtig gewählt wird.

Wir können sagen, dass wir aufgrund der Koordination von Terminologie und Schnittstellentexten in der Phase der Festlegung der Genehmigung in den folgenden Phasen viel Zeit für mehrere Korrekturen gespart haben.

Dokumentation

Die Grundsätze, an die wir uns bei der Dokumentation halten:

• Verwendung eines Single-Source-Systems.
• Verwenden des Glossars.
• Verwenden Sie den Styleguide.
• Aufteilung der Dokumentation in kleine und leicht veräußerbare Dokumente.
  Dies lohnt sich auch dann, wenn das Hauptformat das Web ist. Bei Bedarf können Sie nicht die gesamte Dokumentation, sondern nur die wichtigsten Dokumente übersetzen oder schrittweise durchführen.

Jetzt werde ich über einige der wichtigsten Aspekte des Dokumentationsprozesses sprechen.

Text wiederverwenden

In den meisten Systemen aus einer Hand können Variablen verwendet werden. Aus diesem Grund haben wir Skripte entwickelt, die Schnittstellendateien automatisch in variable Dateien konvertieren. Bei der Entwicklung der Dokumentation geben wir keine Texte von Schnittstellenelementen ein, sondern fügen Variablen in den Text ein. So werden in der russischen Version automatisch russische Linien eingezogen, in der englischen Version Englisch in Deutsch-Deutsch.



Was sind die Vorteile:

• Fehler im Text von Schnittstellenelementen werden ausgeschlossen, wenn sie in der Dokumentation erwähnt werden. Die Texte der Schnittstellenelemente in der Dokumentation sind immer identisch mit den Texten in der Schnittstelle.
• Wenn sich Textzeilen in der Benutzeroberfläche geändert haben, ändern sie sich automatisch in der Dokumentation.
• Fehler sind beim Übersetzen von Texten von Schnittstellenelementen in der Dokumentation ausgeschlossen.
• Ein Übersetzer verbringt weniger Zeit mit Arbeiten.

Die Dokumentation enthält viele doppelte Sätze. Zum Beispiel ein Satz wie - "Klicken Sie auf die Schaltfläche Speichern ." In Single-Source-Systemen kann ein solcher Vorschlag in einem Snippet platziert werden. Ein Snippet ist eine so kleine Datei, die in andere Seiten der Dokumentation eingefügt werden kann.



Wie Sie sehen können, wird der Text der Schaltfläche Speichern im Snippet auch durch die Variable ersetzt.

Dies bietet die folgenden Vorteile:

• Bedeutungsgleiche Sätze sind überall identisch, was bedeutet, dass die Einheitlichkeit des Textes zunimmt.
• Die Kosten für die Entwicklung der Dokumentation durch Wiederverwendung werden reduziert.
• Solche Sätze werden nur einmal übersetzt. Dies reduziert die Kosten des Übersetzers.

Screenshots und andere Bilder

In unserer Dokumentation verwenden wir häufig Screenshots und andere Bilder, die möglicherweise Text enthalten.

Um selbst Screenshots in verschiedenen Sprachen zu machen, schreiben wir unter jeden Screenshot den Text, der darauf verwendet wird. Dieser Text ist markiert und erscheint nicht in der fertigen Dokumentation. Bevor wir die Dokumentation übersetzen, übersetzen wir Texte für Screenshots. Und während der Übersetzung der Dokumentation machen wir Screenshots von technischen Redakteuren ohne Sprachkenntnisse.

Bei der Verwendung von Screenshots gibt es andere Schwierigkeiten. Wie können Sie beispielsweise alle Änderungen verfolgen, wenn die Benutzeroberfläche eine Textzeile ändert, die an 50 Stellen verwendet wird?

Wie finde ich dann alle Screenshots dieser 50 Stellen, um sie in der Dokumentation zu ersetzen?

Um dieses Problem zu lösen, verwenden wir das QVisual-Tool, das wir bei Tinkoff entwickelt haben. Der Prozess der Arbeit damit sieht folgendermaßen aus:

1. Während der Entwicklung der Dokumentation stellen wir unter jedem Screenshot einen Link zu dem Stand her, an dem dieser Screenshot aufgenommen wurde.
2. Ab einem bestimmten Punkt erstellen wir eine Liste aller Links.
3. Wir laden die empfangene Liste in QVisual.
4. QVisual durchläuft eine Version des Produkts und erstellt eine Reihe von Screenshots.
5. Als nächstes nehmen wir die neue Version des Produkts und QVisual führt sie mit denselben Links durch.
6. QVisual vergleicht dann zwei Sätze von Screenshots und generiert einen Bericht. Im Bericht sehen Sie grafisch die Unterschiede zwischen den beiden Versionen. Ein Beispiel ist unten. Sie sehen sofort, dass in der neuen Version des Screenshots ein zusätzliches Feld Sprache der Benutzeroberfläche angezeigt wurde .
7. Als nächstes wiederholen wir das Vergleichsverfahren (S. 1-6) für jede Sprache.
8. Wir nehmen die Berichte und gehen die Screenshots in der Dokumentation durch.

So reduzieren wir die Kosten für zahlreiche manuelle Screenshot-Prüfungen. Darüber hinaus ist es manuell nicht immer möglich, alle Fehler zu identifizieren, man kann einfach etwas übersehen.

Zwar können nicht alle Fenster über Links geöffnet werden, und dies funktioniert nur für die Weboberfläche, es werden jedoch einige Probleme beim Aktualisieren von Screenshots behoben.

Schnittstellenlokalisierung

Wenn dies noch nicht geschehen ist, müssen Sie vor dem Lokalisieren der Benutzeroberfläche alle Glossarbegriffe übersetzen.

Wenn das Glossar übersetzt ist, kann die Lokalisierung beginnen. Dabei halten wir uns an folgende Grundsätze:

• Verwenden Sie das Glossar.
• Wir benutzen das Translation Memory.
• Wir verwenden den Styleguide.
• Wir verwenden einen Kontext.
• Wir verwenden die automatische Qualitätssicherung (QS).

Ich stelle fest, dass der Kontext möglicherweise eine höhere Priorität für die Entscheidung über die Übersetzung hat als dieselbe, bereits übersetzte Zeile im Translation Memory. Abhängig vom Kontext können auch bestimmte Übersetzungsregeln gelten, die im Styleguide angegeben sind.

Es gibt verschiedene Möglichkeiten, den Kontext bereitzustellen:

• Wie ich oben geschrieben habe, kann der Kontext in der Zeichenfolgenkennung selbst oder in zusätzlichen Feldern von Ressourcendateien festgelegt werden (sofern das Format dies zulässt).
• Screenshots können hinzugefügt werden. Derzeit können wir besonders komplexen Zeilen manuell Screenshots hinzufügen.
• Bereitstellung von Ständen und Dokumentationen in der Ausgangssprache. Wie die Praxis zeigt, funktioniert diese Methode nicht. Übersetzer verwenden normalerweise nicht die ihnen zur Verfügung gestellten Materialien und Stände. Vielleicht, weil die Zeit, die zum Übersetzen einer Zeile benötigt wird, um ein Vielfaches zunimmt.

Übersetzung der Dokumentation

Die Grundsätze, die wir bei der Übersetzung von Dokumentationen einhalten möchten:

• Zunächst übersetzen wir Texte für Screenshots und andere Bilder. Wie ich oben geschrieben habe, werden Screenshots parallel zur Übersetzung der Dokumentation aufgenommen. Dies geschieht am Stand mit übersetzten Texten für Screenshots.
• Wir übersetzen nur geänderte und neue Zeilen. Zuvor übersetzte Zeilen mit einer 100% igen Übereinstimmung sehen einfach nicht aus. Ja, Sie können die gesamte Dokumentation für jede Version erneut lesen. Wenn Sie jedoch berücksichtigen, dass jede Version ungefähr 10% des Textes aktualisiert, sind die verbleibenden 90% des Textes ungerechtfertigt.
• Verwenden Sie das Glossar. Das Glossar muss in der Phase der Lokalisierung der Schnittstelle früher übersetzt werden.
• Wir verwenden die Speicherübersetzungsdokumentation.
• Wir verwenden die Speicherübersetzungsschnittstelle.
• Wir verwenden den Styleguide.
• Wir verwenden die automatische Qualitätskontrolle (QS).

Organisationsstruktur und Feedback

Ich werde ein paar Worte zur Organisationsstruktur des Unternehmens sagen. Es ist für jeden anders, aber stellen Sie sich einen Fall vor, in dem jede Abteilung ihre eigene Abteilung hat.



Das Feedback von einer Abteilung zur vorherigen in dieser Version wird schwierig sein, die Interaktion zwischen Mitarbeitern verschiedener Abteilungen ist schwierig. Die Lösung aller Probleme durch den Kopf ist auch ein "schmaler Hals". Jeder Leiter hat seine eigene Vision, Ziele und Prioritäten. Für zusätzliche Genehmigungen kann viel Zeit aufgewendet werden.

Meiner Meinung nach sollte eine Abteilung für alle Texte in allen Sprachen verantwortlich sein.

Bei dieser Verteilung der Verantwortung ist jede Version des Produkts ein separates Projekt aus mehreren Phasen, und die Qualität der Implementierung dieses Projekts muss als Ganzes beantwortet werden. Es ist einfacher, Feedback zu geben, Probleme schnell zu verstehen, eine Retrospektive zu erstellen und die Grundursache des Problems zu finden.

Ich werde ein Beispiel geben.

Aufgrund der Tatsache, dass unsere technischen Redakteure selbst Übersetzungen mithilfe der Qualitätssicherung überprüfen, haben wir Dutzende, wenn nicht Hunderte von Inkonsistenzfehlern festgestellt.

Es stellte sich heraus, dass der Übersetzer die Sätze in ihrer Bedeutung, aber auf unterschiedliche Weise identisch sieht und dieselbe Übersetzung für sie vornimmt. Wir haben die Aufgabe initiiert und der technische Redakteur hat alle verschiedenen Versionen desselben Textes im Sinne eines Ausschnitts ersetzt. Jetzt wird es keine solchen wiederholten Fehler mehr geben. Fachleute müssen keine Zeit damit verbringen, sie zu analysieren, und die Übersetzung in neue Sprachen wird in Zukunft einfacher sein.



Wenn der Übersetzer während der Übersetzung Fragen hat, ist es für uns bereits eine „Glocke“, dass in den frühen Stadien etwas nicht stimmt und wir die Korrekturaufgabe erledigen müssen.

Welche Qualitätsdokumentation wird benötigt?

Bevor Sie versuchen, eine perfekte Dokumentation in allen Sprachen zu erstellen, sollten Sie sich überlegen, welche Qualität benötigt wird. Zusätzliche Fragen helfen bei der Beantwortung dieser Frage:

• Wer sind die Benutzer der Dokumentation?
  Wenn die Dokumentation gemeinfrei ist und die Kunden auf dieser Grundlage die Entscheidung treffen, das Produkt zu kaufen, sollte die Qualität nahezu ideal sein. ( ), . , . , : , , . .
• ?
  , , . . ? , , .

:

• .
  
  , , -50 , . - 1-2 , .
• .
  
  CAT-. , (, ), .
• , , , .
• , .

Web- . , , .

. , .

. . , .

:

• .
  
  - , . . , Ctrl+Enter . . .
• .
  
  , . , , .
• .
  
  , , . , ( ), . , . .

, , , . , , .

Schlussfolgerungen

, -, .

, , .

. .

, ! !

, !