Das Internet ist zwar eine tolle Informationsquelle, aber man findet auch viel Schrott. Oft ist es schwer zu entscheiden, was richtig (oder zumindest akzeptabel) ist und was nicht. Um zu bestimmen, wie zuverlässig eine bestimmte Quelle ist, würde ich folgende Prioritäten zuweisen:
1. Website des Kunden/Herstellers: Die Terminologie des Kunden hat Vorrang vor allem anderen. Wenn euch der Kunde kein Glossar zur Verfügung gestellt hat, lohnt es sich, die Website des Kunden zu durchforsten.
2. Website des Betriebssystemherstellers (bei Computerprodukten): Wenn ein Produkt auf einem Betriebssystem wie Microsoft Windows oder Apple OS X basiert, sollte man auch die Terminologie von Microsoft oder Apple in Betracht ziehen. Alle Betriebssystemhersteller unterhalten umfassende Websites mit hohem Informationsgehalt.
3. Website eines Mitbewerbers: Oft lohnt es sich, die Website eines Konkurrenten zu besuchen, v.a. wenn dieser Konkurrent eine marktführende Position inne hat. In diesem Fall richtet sich euer Kunde vielleicht nach der vom Martkführer verwendeten Terminologie.
4. Websites von renommierten Fachzeitschriften: Praktisch jede führende Fachzeitschrift betreibt eine Website, auf der man von Experten verfasste Artikel wie Produktreviews, Rezensionen, Kommentare usw. finden kann. Diese Artikel sind oft eine wertvolle Informationsquelle.
5. Öffenliche Enzyklopädien wie http://de.wikipedia.org: Viele Artikel sind von Experten geschrieben und deshalb terminologisch wertvoll. Nicht unbedingt als Primärquelle zu empfehlen, aber sehr nützlich, um die Gültigkeit eines anderswo gefundenen Begriffs zu bestätigen.
Dienstag, 27. Februar 2007
Mittwoch, 21. Februar 2007
Tipps zur Übersetzung von Benutzerhandbüchern
Viele Übersetzer verdienen sich mit der Übersetzung von Benutzerhandbüchern und ähnlichen Dokumenten ihren Lebensunterhalt. Deshalb ist diese Textkategorie gerade für die Sprachrichtung Englisch > Deutsch so wichtig.
Im Gegensatz zu allgemeinen, literarischen oder marketingbezogenen Texten, wo es in erster Linie auf den Stil ankommt, liegt der Schwerpunkt bei technischen Texten auf fachlicher Genauigkeit, korrekter Terminologie und leicht verständlicher Ausdruckweise.
In einem eher literarischen Text ist Abwechslung in puncto Wortwahl und Satzkonstruktion nicht nur angebracht, sondern sogar erwünscht. In einem Benutzerhandbuch würde ich allerdings davon abraten. Es hilft dem Anwender sehr wenig, wenn der Übersetzer in einem Satz von einem Dialogfeld, in einem anderen von einem Dialogfenster und in einem dritten von einer Dialogbox spricht oder wenn Anweisungen einmal im Imperativ und dann im Infinitiv geschrieben sind.
Ich kann nicht genug betonen, wie wichtig Einheitlichkeit ist: einheitliche Terminologie, einheitlicher Stil, einheitliche Satzkonstruktion. In dieser Hinsicht lässt sich ein technischer Text fast wie eine mathematische Formel betrachten:
Wort A (Englisch) = Wort A (Deutsch)
NICHT:
Wort A (Englisch) = Wort A (Deutsch) ODER Wort B (Deutsch) ODER Wort C (Deutsch)
Beispiel: „Screen“ lässt sich auf vielerlei Weise übersetzen. „Bildschirm“, „Monitor“, „Anzeige“ oder sogar „Display“. Egal, wofür ihr euch entscheidet (bzw. was der Kunde will), verwendet eine und nur eine Übersetzung.
Das gleiche gilt für Satzkonstruktionen:
Für Anweisungen wie „To read a document, double-click the file icon“ gibt es mehrere Möglichkeiten:
A: Um ein Dokument zu lesen, doppelklicken Sie auf das Dateisymbol.
B: Doppelklicken Sie zum Lesen eines Dokuments auf das Dateisymbol.
C: Doppelklicken Sie auf das Dateisymbol, um das Dokument zu lesen.
D: Zum Lesen eines Dokuments auf das Dateisymbol doppelklicken.
...
Egal, für welche Konstruktion ihr euch entscheidet (A ist für mich die einfachste und deshalb angemessenste), seid konsequent und wechselt nicht zwischen mehreren Alternativen hin und her. Das würde den Leser unnötig verwirren.
Drückt euch so leicht verständlich wie möglich aus. Verwendet einfache Sätze, auch wenn sie für euch vielleicht zu einfach klingen. Ihr verfasst kein literarisches Meisterwerk, sondern einen Text, der benutzerfreundlich sein soll.
Beispiel:
Englisch: To zoom in on an element, select the Zoom tool located in the Tools panel, and click the element.
Alternative A: Durch Auswahl des im Bedienfeld „Werkzeuge“ befindlichen Vergrößerungswerkzeugs und anschließendes Klicken auf das gewünschte Element lässt sich dieses vergrößert darstellen.
Alternative B: Um ein Element vergrößert darzustellen, wählen Sie im Bedienfeld „Werkzeuge“ das Vergrößerungswerkzeug aus und klicken Sie dann auf das Element.
Alternative A hört sich elegant an und ist völlig korrekt. Alternative B ist zwar nicht so elegant, aber wesentlich einfacher formuliert und deshalb einfacher und schneller zu verstehen. Für mich ist Alternative B die bessere Lösung für ein Benutzerhandbuch, da selbst ein weniger gebildeter Leser die zu vermittelnde Information sofort begreift.
Versucht in einem technischen Text nicht, euch literarisch zu verwirklichen, sondern denkt an das Zielpublikum und passt euren Stil entsprechend an. Ihr habt eure Aufgabe erfolgreich gemeistert, wenn der Benutzer nicht merkt, dass er eine Übersetzung liest!
Im Gegensatz zu allgemeinen, literarischen oder marketingbezogenen Texten, wo es in erster Linie auf den Stil ankommt, liegt der Schwerpunkt bei technischen Texten auf fachlicher Genauigkeit, korrekter Terminologie und leicht verständlicher Ausdruckweise.
In einem eher literarischen Text ist Abwechslung in puncto Wortwahl und Satzkonstruktion nicht nur angebracht, sondern sogar erwünscht. In einem Benutzerhandbuch würde ich allerdings davon abraten. Es hilft dem Anwender sehr wenig, wenn der Übersetzer in einem Satz von einem Dialogfeld, in einem anderen von einem Dialogfenster und in einem dritten von einer Dialogbox spricht oder wenn Anweisungen einmal im Imperativ und dann im Infinitiv geschrieben sind.
Ich kann nicht genug betonen, wie wichtig Einheitlichkeit ist: einheitliche Terminologie, einheitlicher Stil, einheitliche Satzkonstruktion. In dieser Hinsicht lässt sich ein technischer Text fast wie eine mathematische Formel betrachten:
Wort A (Englisch) = Wort A (Deutsch)
NICHT:
Wort A (Englisch) = Wort A (Deutsch) ODER Wort B (Deutsch) ODER Wort C (Deutsch)
Beispiel: „Screen“ lässt sich auf vielerlei Weise übersetzen. „Bildschirm“, „Monitor“, „Anzeige“ oder sogar „Display“. Egal, wofür ihr euch entscheidet (bzw. was der Kunde will), verwendet eine und nur eine Übersetzung.
Das gleiche gilt für Satzkonstruktionen:
Für Anweisungen wie „To read a document, double-click the file icon“ gibt es mehrere Möglichkeiten:
A: Um ein Dokument zu lesen, doppelklicken Sie auf das Dateisymbol.
B: Doppelklicken Sie zum Lesen eines Dokuments auf das Dateisymbol.
C: Doppelklicken Sie auf das Dateisymbol, um das Dokument zu lesen.
D: Zum Lesen eines Dokuments auf das Dateisymbol doppelklicken.
...
Egal, für welche Konstruktion ihr euch entscheidet (A ist für mich die einfachste und deshalb angemessenste), seid konsequent und wechselt nicht zwischen mehreren Alternativen hin und her. Das würde den Leser unnötig verwirren.
Drückt euch so leicht verständlich wie möglich aus. Verwendet einfache Sätze, auch wenn sie für euch vielleicht zu einfach klingen. Ihr verfasst kein literarisches Meisterwerk, sondern einen Text, der benutzerfreundlich sein soll.
Beispiel:
Englisch: To zoom in on an element, select the Zoom tool located in the Tools panel, and click the element.
Alternative A: Durch Auswahl des im Bedienfeld „Werkzeuge“ befindlichen Vergrößerungswerkzeugs und anschließendes Klicken auf das gewünschte Element lässt sich dieses vergrößert darstellen.
Alternative B: Um ein Element vergrößert darzustellen, wählen Sie im Bedienfeld „Werkzeuge“ das Vergrößerungswerkzeug aus und klicken Sie dann auf das Element.
Alternative A hört sich elegant an und ist völlig korrekt. Alternative B ist zwar nicht so elegant, aber wesentlich einfacher formuliert und deshalb einfacher und schneller zu verstehen. Für mich ist Alternative B die bessere Lösung für ein Benutzerhandbuch, da selbst ein weniger gebildeter Leser die zu vermittelnde Information sofort begreift.
Versucht in einem technischen Text nicht, euch literarisch zu verwirklichen, sondern denkt an das Zielpublikum und passt euren Stil entsprechend an. Ihr habt eure Aufgabe erfolgreich gemeistert, wenn der Benutzer nicht merkt, dass er eine Übersetzung liest!
Dienstag, 20. Februar 2007
Fehler im Ausgangstext, Teil 2
Was für ein Zufall, dass ich letzte Woche von Fehlern im Ausgangstext sprach. Gestern machte ich eine Übersetzung für einen Kunden in Deutschland, ein Jeopardy-ähnliches Spiel für eine Website. In einem relativ kurzen Dokument fand ich gleich drei Sachen, die nicht ganz stimmten:
Problem 1:
Der flächenmäßig größte Bundesstaat der USA.
Antwortmöglichkeiten: Florida, Neu Mexiko, Kalifornien, Texas
Problem: Weder noch! Die richtige Antwort lautet Alaska.
Lösung: Antwort 4, Texas, ersetzt durch Alaska
Problem 2:
Riesige Tiere, die vor Jahrtausenden auf der Erde lebten.
Richtige Antwort: Dinosaurier
Problem: Dinosaurier lebten nicht "vor Jahrtausenden", sondern vor Millionen von Jahren!
Lösung: Übersetzt als "Giant animals that roamed the Earth millions of years ago."
Problem 3:
So werden Suchmaschinen auch genannt.
Richtige Antwort: Spider
Problem: Spider sind keine Suchmaschinen, sondern Programme, die von Suchmaschinen zum Durchforsten von Webseiten verwendet werden.
Lösung: Übersetzt als "Programs used by search engines to analyze web pages."
Durch selbstständiges Ausbessern von Fehlern dieser Art (ggf. nach Rücksprache mit dem Kunden) können wir Übersetzer den von uns gebotenen Service aufwerten.
Gerhard
Problem 1:
Der flächenmäßig größte Bundesstaat der USA.
Antwortmöglichkeiten: Florida, Neu Mexiko, Kalifornien, Texas
Problem: Weder noch! Die richtige Antwort lautet Alaska.
Lösung: Antwort 4, Texas, ersetzt durch Alaska
Problem 2:
Riesige Tiere, die vor Jahrtausenden auf der Erde lebten.
Richtige Antwort: Dinosaurier
Problem: Dinosaurier lebten nicht "vor Jahrtausenden", sondern vor Millionen von Jahren!
Lösung: Übersetzt als "Giant animals that roamed the Earth millions of years ago."
Problem 3:
So werden Suchmaschinen auch genannt.
Richtige Antwort: Spider
Problem: Spider sind keine Suchmaschinen, sondern Programme, die von Suchmaschinen zum Durchforsten von Webseiten verwendet werden.
Lösung: Übersetzt als "Programs used by search engines to analyze web pages."
Durch selbstständiges Ausbessern von Fehlern dieser Art (ggf. nach Rücksprache mit dem Kunden) können wir Übersetzer den von uns gebotenen Service aufwerten.
Gerhard
Fehler im Ausgangstext, Teil 2
Was für ein Zufall, dass ich letzte Woche von Fehlern im Ausgangstext sprach. Gestern machte ich eine Übersetzung für einen Kunden in Deutschland, ein Jeopardy-ähnliches Spiel für eine Website. In einem relativ kurzen Dokument fand ich gleich drei Sachen, die nicht ganz stimmten:
Problem 1:
Der flächenmäßig größte Bundesstaat der USA.
Antwortmöglichkeiten: Florida, Neu Mexiko, Kalifornien, Texas
Problem: Weder noch! Die richtige Antwort lautet Alaska.
Lösung: Antwort 4, Texas, ersetzt durch Alaska
Problem 2:
Riesige Tiere, die vor Jahrtausenden auf der Erde lebten.
Richtige Antwort: Dinosaurier
Problem: Dinosaurier lebten nicht "vor Jahrtausenden", sondern von Zigmillionen von Jahren!
Lösung: Übersetzt als "Giant animals that roamed the Earth millions of years ago."
Problem 3:
So werden Suchmaschinen auch genannt.
Richtige Antwort: Spider
Problem: Spider sind keine Suchmaschinen, sondern Programme, die von Suchmaschinen zum Durchforsten von Webseiten verwendet werden.
Lösung: Übersetzt als "Programs used by search engines to analyze web pages."
Durch selbstständiges Ausbessern von Fehlern dieser Art (ggf. nach Rücksprache mit dem Kunden) können wir Übersetzer den von uns gebotenen Service aufwerten.
Gerhard
Problem 1:
Der flächenmäßig größte Bundesstaat der USA.
Antwortmöglichkeiten: Florida, Neu Mexiko, Kalifornien, Texas
Problem: Weder noch! Die richtige Antwort lautet Alaska.
Lösung: Antwort 4, Texas, ersetzt durch Alaska
Problem 2:
Riesige Tiere, die vor Jahrtausenden auf der Erde lebten.
Richtige Antwort: Dinosaurier
Problem: Dinosaurier lebten nicht "vor Jahrtausenden", sondern von Zigmillionen von Jahren!
Lösung: Übersetzt als "Giant animals that roamed the Earth millions of years ago."
Problem 3:
So werden Suchmaschinen auch genannt.
Richtige Antwort: Spider
Problem: Spider sind keine Suchmaschinen, sondern Programme, die von Suchmaschinen zum Durchforsten von Webseiten verwendet werden.
Lösung: Übersetzt als "Programs used by search engines to analyze web pages."
Durch selbstständiges Ausbessern von Fehlern dieser Art (ggf. nach Rücksprache mit dem Kunden) können wir Übersetzer den von uns gebotenen Service aufwerten.
Gerhard
Fehler im Ausgangstext, Teil 2
Was für ein Zufall, dass ich letzte Woche von Fehlern im Ausgangstext gesprochen habe. Gestern machte ich eine Übersetzung für einen Kunden in Deutschland, ein Jeopardy-ähnliches Spiel für eine Website. In einem relativ kurzen Dokument fand ich gleich drei Sachen, die nicht ganz stimmten:
Problem 1:
Der flächenmäßig größte Bundesstaat der USA.
Antwortmöglichkeiten: Florida, Neu Mexiko, Kalifornien, Texas
Problem: Weder noch! Die richtige Antwort lautet Alaska.
Lösung: Antwort 4, Texas, ersetzt durch Alaska
Problem 2:
Riesige Tiere, die vor Jahrtausenden auf der Erde lebten.
Richtige Antwort: Dinosaurier
Problem: Dinosaurier lebten nicht "vor Jahrtausenden", sondern von Zigmillionen von Jahren!
Lösung: Übersetzt als "Giant animals that roamed the Earth millions of years ago."
Problem 3:
So werden Suchmaschinen auch genannt.
Richtige Antwort: Spider
Problem: Spider sind keine Suchmaschinen, sondern Programme, die von Suchmaschinen zum Durchforsten von Webseiten verwendet werden.
Lösung: Übersetzt als "Programs used by search engines to analyze web pages."
Durch selbstständiges Ausbessern von Fehlern dieser Art (ggf. nach Rücksprache mit dem Kunden) können wir Übersetzer den von uns gebotenen Service aufwerten.
Gerhard
Problem 1:
Der flächenmäßig größte Bundesstaat der USA.
Antwortmöglichkeiten: Florida, Neu Mexiko, Kalifornien, Texas
Problem: Weder noch! Die richtige Antwort lautet Alaska.
Lösung: Antwort 4, Texas, ersetzt durch Alaska
Problem 2:
Riesige Tiere, die vor Jahrtausenden auf der Erde lebten.
Richtige Antwort: Dinosaurier
Problem: Dinosaurier lebten nicht "vor Jahrtausenden", sondern von Zigmillionen von Jahren!
Lösung: Übersetzt als "Giant animals that roamed the Earth millions of years ago."
Problem 3:
So werden Suchmaschinen auch genannt.
Richtige Antwort: Spider
Problem: Spider sind keine Suchmaschinen, sondern Programme, die von Suchmaschinen zum Durchforsten von Webseiten verwendet werden.
Lösung: Übersetzt als "Programs used by search engines to analyze web pages."
Durch selbstständiges Ausbessern von Fehlern dieser Art (ggf. nach Rücksprache mit dem Kunden) können wir Übersetzer den von uns gebotenen Service aufwerten.
Gerhard
Donnerstag, 15. Februar 2007
Unklarer oder fehlerhafter Ausgangstext
Was macht man, wenn der zu übersetzende Ausgangstext unklar ist oder Fehler enthält?
Diese Situation kommt relativ häufig vor - öfter als erwünscht. Manche Dokumente sind sehr gut geschrieben und so gut wie fehlerfrei. Bei anderen merkt man, dass der Autor nicht viel Wert auf eine klare Ausdrucksweise gelegt hat bzw. dass der Text nicht oder nur schlampig editiert wurde.
In einer perfekten Welt würde man natürlich sofort beim Kunden nachfragen. Aber oft ist das aus Zeitgründen nicht möglich oder der Kunde will mit solchen Bagatellen nicht belästigt werden und möchte, dass sich der Übersetzer selbst darum kümmert.
Was tun?
- EINFACHE FEHLER. Manche Fehler lassen sich leicht korrigieren - falsch geschriebene Produkt- oder Firmennamen oder eindeutige sachliche Fehler (wie z. B. "Dublin, UK" statt "Dublin, Ireland"). Hier einfach den Fehler ausbessern.
- FEHLERHAFTE STELLEN WEGLASSEN. If in doubt, leave it out. Ich bin ein großer Anhänger dieses Mottos. Lieber weglassen als einen Fehler einbauen. Aber natürlich geht das nicht immer (und in Hausaufgaben und Prüfungen schon gar nicht). Ganze Sätze kann man nicht einfach weglassen, aber kürzere Sachen schon, vor allem in Auflistungen.
- NEBULÖSE FORMULIERUNGEN. Oft ist der Ausgangstext so kompliziert oder einfach schlampig formuliert, dass man nicht genau weiß, was der Autor eigentlich sagen will. In diesem Fall kann man (so wie Dolmetscher das auch tun) einfach eine allgemeine Aussage hinzufügen, die gut klingt, auch wenn sie der Absicht des Autors vielleicht nicht 100% entspricht. Adjektive wie "effektiv", "effizient", "leistungsfähig" usw. sind immer gut.
Ein kleines Beispiel aus der Übersetzung, die ich heute morgen gemacht habe:
EN: [Registry Mechanic uses a high-performance detection algorithm to quickly identify missing and invalid references in your Windows registry.] These problems can occur for many reasons including being left-behind after the un-installation or incorrect removal of software, by missing or corrupt hardware drivers, or orphaned startup programs.
Problem: Was ist gemeint mit "including being left-behind"? Was ist "left-behind"?
Lösung: Ich machte im Deutschen eine Aufzählung daraus und fügte am Ende das höchst nützliche "o. ä." an.
DE: Für derartige Probleme gibt es vielerlei Gründe: Daten, die nach der Deinstallation oder der inkorrekten Entfernung von Softwareprogrammen weiterhin vorhanden sind, fehlende oder beschädigte Hardwaretreiber, ungültige Startup-Programme o. ä.
Gerhard
Diese Situation kommt relativ häufig vor - öfter als erwünscht. Manche Dokumente sind sehr gut geschrieben und so gut wie fehlerfrei. Bei anderen merkt man, dass der Autor nicht viel Wert auf eine klare Ausdrucksweise gelegt hat bzw. dass der Text nicht oder nur schlampig editiert wurde.
In einer perfekten Welt würde man natürlich sofort beim Kunden nachfragen. Aber oft ist das aus Zeitgründen nicht möglich oder der Kunde will mit solchen Bagatellen nicht belästigt werden und möchte, dass sich der Übersetzer selbst darum kümmert.
Was tun?
- EINFACHE FEHLER. Manche Fehler lassen sich leicht korrigieren - falsch geschriebene Produkt- oder Firmennamen oder eindeutige sachliche Fehler (wie z. B. "Dublin, UK" statt "Dublin, Ireland"). Hier einfach den Fehler ausbessern.
- FEHLERHAFTE STELLEN WEGLASSEN. If in doubt, leave it out. Ich bin ein großer Anhänger dieses Mottos. Lieber weglassen als einen Fehler einbauen. Aber natürlich geht das nicht immer (und in Hausaufgaben und Prüfungen schon gar nicht). Ganze Sätze kann man nicht einfach weglassen, aber kürzere Sachen schon, vor allem in Auflistungen.
- NEBULÖSE FORMULIERUNGEN. Oft ist der Ausgangstext so kompliziert oder einfach schlampig formuliert, dass man nicht genau weiß, was der Autor eigentlich sagen will. In diesem Fall kann man (so wie Dolmetscher das auch tun) einfach eine allgemeine Aussage hinzufügen, die gut klingt, auch wenn sie der Absicht des Autors vielleicht nicht 100% entspricht. Adjektive wie "effektiv", "effizient", "leistungsfähig" usw. sind immer gut.
Ein kleines Beispiel aus der Übersetzung, die ich heute morgen gemacht habe:
EN: [Registry Mechanic uses a high-performance detection algorithm to quickly identify missing and invalid references in your Windows registry.] These problems can occur for many reasons including being left-behind after the un-installation or incorrect removal of software, by missing or corrupt hardware drivers, or orphaned startup programs.
Problem: Was ist gemeint mit "including being left-behind"? Was ist "left-behind"?
Lösung: Ich machte im Deutschen eine Aufzählung daraus und fügte am Ende das höchst nützliche "o. ä." an.
DE: Für derartige Probleme gibt es vielerlei Gründe: Daten, die nach der Deinstallation oder der inkorrekten Entfernung von Softwareprogrammen weiterhin vorhanden sind, fehlende oder beschädigte Hardwaretreiber, ungültige Startup-Programme o. ä.
Gerhard
15. Februar, 9.30 Uhr
Sorry, dass ich gestern nichts geschrieben habe. Es war Valentinstag und habe einen halben Tag geschwänzt. Das muss auch mal sein :-)
Heute morgen mache ich eine Übersetzung für ZoneAlarm: Beschreibungen für Produkte von Partnerfirmen, die Kunden, die auf der Website von Zone Labs ein ZoneAlarm-Produkt kaufen, beim Checkout in einem sog. Cross-Sell-Bereich sehen. Die Texte sind eine Mischung aus Marketing und technischen Daten. Nicht weiter schwer und deshalb recht schnell zu übersetzen. Ich weiß, wir sind alle Idealisten und würden am liebsten nur Sachen übersetzen, die uns intellektuell ansprechen, aber für Leute, die sich ihren Lebensunterhalt als Übersetzer verdienen, sieht die Wirklichkeit so aus: mehr Übersetzen = mehr Verdienen. Und "mehr Übersetzen" geht nur, wenn man schnell übersetzt, und das kann man nur, wenn der Text entweder wirklich einfach ist oder wenn man mit der Materie vertraut ist. Deshalb ist es toll, wenn man ein paar Stammkunden hat, die einem immer wieder das gleiche Zeug schicken!
Gerhard
Heute morgen mache ich eine Übersetzung für ZoneAlarm: Beschreibungen für Produkte von Partnerfirmen, die Kunden, die auf der Website von Zone Labs ein ZoneAlarm-Produkt kaufen, beim Checkout in einem sog. Cross-Sell-Bereich sehen. Die Texte sind eine Mischung aus Marketing und technischen Daten. Nicht weiter schwer und deshalb recht schnell zu übersetzen. Ich weiß, wir sind alle Idealisten und würden am liebsten nur Sachen übersetzen, die uns intellektuell ansprechen, aber für Leute, die sich ihren Lebensunterhalt als Übersetzer verdienen, sieht die Wirklichkeit so aus: mehr Übersetzen = mehr Verdienen. Und "mehr Übersetzen" geht nur, wenn man schnell übersetzt, und das kann man nur, wenn der Text entweder wirklich einfach ist oder wenn man mit der Materie vertraut ist. Deshalb ist es toll, wenn man ein paar Stammkunden hat, die einem immer wieder das gleiche Zeug schicken!
Gerhard
Dienstag, 13. Februar 2007
Deutsche Anführungszeichen
Silvie erwähnte gestern, dass ihr von mehreren Seiten aus angehalten worden seid, immer deutsche Anführungszeichen, d.h. „ “, zu verwenden. Dieses Thema ist der Büchse der Pandora nicht unähnlich. Ich sehe das so:
- KLARER FALL: In für den Druck bestimmten Dokumenten (Handbüchern, Marketingmaterialien usw.) sollten immer deutsche Anführungszeichen verwendet werden. Das gilt auch für alle eure Hausaufgaben.
- NICHT SO KLAR: Auf Webseiten findet man alles mögliche - deutsche Anführungszeichen, gerade Anführungszeichen, geschweifte englische Anführungszeichen. Verkompliziert wird das ganze dadurch, dass v.a. ältere Browserversionen nur gerade Anführungszeichen unterstützen. Persönlich würde ich auch auf Webseiten deutsche AFZ verwenden, aber es kann durchaus sein, dass ein Kunde spezifische Vorgaben hat, also im Zweifelsfall nachfragen.
- ÜBERHAUPT NICHT KLAR: Softwarelokalisierung. Hier IMMER nachfragen, welche Anführungszeichen verwendet werden können und wie diese einzugeben sind.
Je nachdem, wie der Programmcode geschrieben ist, können normale doppelte AFZ (d. h. " ") als Trennzeichen verwenden werden. Beispiel:
POPUP "&View"
BEGIN
MENUITEM "View &File menu", ID_VIEW_FILE_MENU
MENUITEM "View &Edit menu", ID_VIEW_EDIT_MENU
MENUITEM "View &Tools menu", ID_VIEW_TOOLS_MENU
Wenn in den übersetzten Strings zusätzliche doppelte AFZ verwendet werden, funktioniert der gesamte Code nicht mehr.
Falsch:
POPUP "&Ansicht"
BEGIN
MENUITEM "Menü "&Datei" anzeigen", ID_VIEW_FILE_MENU
MENUITEM "Menü "&Bearbeiten" anzeigen", ID_VIEW_EDIT_MENU
MENUITEM "Menü "&Extras" anzeigen", ID_VIEW_TOOLS_MENU
In solchen Fällen gibt es in der Regel folgende Alternativen (manchmal, aber nicht immer, funktionieren alle drei):
- Zusätzliche doppelte Anführungszeichen DOPPELT eingeben ("" "")
- Doppelten Anführungszeichen einen umgekehrten Schrägstrich voranstellen (\" \"); im Englischen wird das als "escaping the quotes" bezeichnet
- Einfache Anführungszeichen verwenden (' '); dies führt aber dazu, dass in der Benutzeroberfläche lediglich einfache AFZ erscheinen, die ich persönlich für häßlich halte
Im Beispiel oben wären also folgende korrekte Lösungen denkbar:
POPUP "&Ansicht"
BEGIN
MENUITEM "Menü ""&Datei"" anzeigen", ID_VIEW_FILE_MENU
MENUITEM "Menü ""&Bearbeiten"" anzeigen", ID_VIEW_EDIT_MENU
MENUITEM "Menü ""&Extras"" anzeigen", ID_VIEW_TOOLS_MENU
POPUP "&Ansicht"
BEGIN
MENUITEM "Menü \"&Datei\" anzeigen", ID_VIEW_FILE_MENU
MENUITEM "Menü \"&Bearbeiten\" anzeigen", ID_VIEW_EDIT_MENU
MENUITEM "Menü \"&Extras\" anzeigen", ID_VIEW_TOOLS_MENU
POPUP "&Ansicht"
BEGIN
MENUITEM "Menü '&Datei' anzeigen", ID_VIEW_FILE_MENU
MENUITEM "Menü '&Bearbeiten' anzeigen", ID_VIEW_EDIT_MENU
MENUITEM "Menü '&Extras' anzeigen", ID_VIEW_TOOLS_MENU
Verwirrt? Ich manchmal auch!!!
Gerhard
- KLARER FALL: In für den Druck bestimmten Dokumenten (Handbüchern, Marketingmaterialien usw.) sollten immer deutsche Anführungszeichen verwendet werden. Das gilt auch für alle eure Hausaufgaben.
- NICHT SO KLAR: Auf Webseiten findet man alles mögliche - deutsche Anführungszeichen, gerade Anführungszeichen, geschweifte englische Anführungszeichen. Verkompliziert wird das ganze dadurch, dass v.a. ältere Browserversionen nur gerade Anführungszeichen unterstützen. Persönlich würde ich auch auf Webseiten deutsche AFZ verwenden, aber es kann durchaus sein, dass ein Kunde spezifische Vorgaben hat, also im Zweifelsfall nachfragen.
- ÜBERHAUPT NICHT KLAR: Softwarelokalisierung. Hier IMMER nachfragen, welche Anführungszeichen verwendet werden können und wie diese einzugeben sind.
Je nachdem, wie der Programmcode geschrieben ist, können normale doppelte AFZ (d. h. " ") als Trennzeichen verwenden werden. Beispiel:
POPUP "&View"
BEGIN
MENUITEM "View &File menu", ID_VIEW_FILE_MENU
MENUITEM "View &Edit menu", ID_VIEW_EDIT_MENU
MENUITEM "View &Tools menu", ID_VIEW_TOOLS_MENU
Wenn in den übersetzten Strings zusätzliche doppelte AFZ verwendet werden, funktioniert der gesamte Code nicht mehr.
Falsch:
POPUP "&Ansicht"
BEGIN
MENUITEM "Menü "&Datei" anzeigen", ID_VIEW_FILE_MENU
MENUITEM "Menü "&Bearbeiten" anzeigen", ID_VIEW_EDIT_MENU
MENUITEM "Menü "&Extras" anzeigen", ID_VIEW_TOOLS_MENU
In solchen Fällen gibt es in der Regel folgende Alternativen (manchmal, aber nicht immer, funktionieren alle drei):
- Zusätzliche doppelte Anführungszeichen DOPPELT eingeben ("" "")
- Doppelten Anführungszeichen einen umgekehrten Schrägstrich voranstellen (\" \"); im Englischen wird das als "escaping the quotes" bezeichnet
- Einfache Anführungszeichen verwenden (' '); dies führt aber dazu, dass in der Benutzeroberfläche lediglich einfache AFZ erscheinen, die ich persönlich für häßlich halte
Im Beispiel oben wären also folgende korrekte Lösungen denkbar:
POPUP "&Ansicht"
BEGIN
MENUITEM "Menü ""&Datei"" anzeigen", ID_VIEW_FILE_MENU
MENUITEM "Menü ""&Bearbeiten"" anzeigen", ID_VIEW_EDIT_MENU
MENUITEM "Menü ""&Extras"" anzeigen", ID_VIEW_TOOLS_MENU
POPUP "&Ansicht"
BEGIN
MENUITEM "Menü \"&Datei\" anzeigen", ID_VIEW_FILE_MENU
MENUITEM "Menü \"&Bearbeiten\" anzeigen", ID_VIEW_EDIT_MENU
MENUITEM "Menü \"&Extras\" anzeigen", ID_VIEW_TOOLS_MENU
POPUP "&Ansicht"
BEGIN
MENUITEM "Menü '&Datei' anzeigen", ID_VIEW_FILE_MENU
MENUITEM "Menü '&Bearbeiten' anzeigen", ID_VIEW_EDIT_MENU
MENUITEM "Menü '&Extras' anzeigen", ID_VIEW_TOOLS_MENU
Verwirrt? Ich manchmal auch!!!
Gerhard
13. Februar, 9.30 Uhr
Bin eben mit dem Beantworten der wichtigsten E-Mails des Tages fertig geworden. Das dauert jeden morgen zwischen 45 Minuten und einer Stunde, je nachdem wie viele Projekte ich manage. Diese linguistischen Reviews sind vom PM her sehr aufwändig. Eines unserer Projekte geht in 14 Sprachen, d.h. wir müssen mit 14 Reviewern kommunizieren UND mit unseren Ansprechpartnern beim Kunden...
Noch dazu kommt, dass ich viele E-Mails erhalten, die mich eigentlich nicht tangieren. Viele Leute verwenden den CC:-Button zu oft bzw. falsch. Ich will nicht über alles informiert werden, was intern bei Kunden so los ist :-) Aber das nur am Rande...
Erste produktive Aufgabe des Tages: Korrekturlesen einer Übersetzung von Sabine. Es geht um neue Produkte der Firma CamelBak: Trinkflaschen, Backpacks usw. Sabine macht dieses Marketing-Gelabere besser als ich. Oft bricht man sich einen ab, vor allem bei so was:
Never look back.
We’ve all heard it before.
Well, it’s bogus.
To innovate and break new ground, you have to know what’s been done.
Understand your limits.
Consider the elements.
Then step out of the back gate, drop in, and do something that’s never been done.
At the bottom, look back and marvel at what you did.
Just for a moment.
Cool.
Now go for more.
Look where we started.
Look where we are.
And we’re going for more.
Unsere Lösung:
Nie den Blick zurück werfen.
Das haben wir schon oft gehört.
Aber stimmt das?
Um Innovationen zu entwickeln und neues Terrain zu betreten, musst du wissen, was vorher war.
Deine Grenzen verstehen.
Dir der Elemente bewusst sein.
Dann kannst du die Piste verlassen und etwas tun, was vor dir noch keiner getan hat.
Wenn du unten angekommen bist, wirf einen Blick nach oben und freu dich an dem, was du geschafft hast.
Nur einen Augenblick lang.
Cool.
Und dann mach weiter.
Schau, wo du begonnen hast.
Schau, wo du jetzt bist.
Das ist erst der Anfang.
Selbst daran könnte man noch lange feilschen. Aber in der Realität ist dafür oft wenig Zeit. Kunden wollen immer alles sofort, am besten gestern.
Gerhard
Noch dazu kommt, dass ich viele E-Mails erhalten, die mich eigentlich nicht tangieren. Viele Leute verwenden den CC:-Button zu oft bzw. falsch. Ich will nicht über alles informiert werden, was intern bei Kunden so los ist :-) Aber das nur am Rande...
Erste produktive Aufgabe des Tages: Korrekturlesen einer Übersetzung von Sabine. Es geht um neue Produkte der Firma CamelBak: Trinkflaschen, Backpacks usw. Sabine macht dieses Marketing-Gelabere besser als ich. Oft bricht man sich einen ab, vor allem bei so was:
Never look back.
We’ve all heard it before.
Well, it’s bogus.
To innovate and break new ground, you have to know what’s been done.
Understand your limits.
Consider the elements.
Then step out of the back gate, drop in, and do something that’s never been done.
At the bottom, look back and marvel at what you did.
Just for a moment.
Cool.
Now go for more.
Look where we started.
Look where we are.
And we’re going for more.
Unsere Lösung:
Nie den Blick zurück werfen.
Das haben wir schon oft gehört.
Aber stimmt das?
Um Innovationen zu entwickeln und neues Terrain zu betreten, musst du wissen, was vorher war.
Deine Grenzen verstehen.
Dir der Elemente bewusst sein.
Dann kannst du die Piste verlassen und etwas tun, was vor dir noch keiner getan hat.
Wenn du unten angekommen bist, wirf einen Blick nach oben und freu dich an dem, was du geschafft hast.
Nur einen Augenblick lang.
Cool.
Und dann mach weiter.
Schau, wo du begonnen hast.
Schau, wo du jetzt bist.
Das ist erst der Anfang.
Selbst daran könnte man noch lange feilschen. Aber in der Realität ist dafür oft wenig Zeit. Kunden wollen immer alles sofort, am besten gestern.
Gerhard
Montag, 12. Februar 2007
12. Februar
Eine meiner Aufgaben seit fast zwei Wochen: In einem 900-seitigen Handbuch die Formatierungsfehler korrigieren, die sich durch die Bearbeitung mit Trados eingeschlichen haben - und das in sechs Sprachen (DE, ES, FR, IT, NL und PT). Das ist ein Auftrag, den wir für eine andere Übersetzungsagentur machen, die keine Kapazitäten dafür frei hatte. Sabine und ich arbeiten ab und zu mit anderen kleineren Agenturen zusammen, nach dem Motto "eine Hand wäscht die andere". Im Prinzip ist das das gleiche wie Übersetzer, die sich untereinander einen Gefallen tun, aber natürlich gegen Bezahlung.
Ich weiß nicht, wie viel praktische Erfahrung ihr mit Trados habt, aber vor allem bei der Übersetzung mit der Trados Workbench in Word (im Gegensatz zur Arbeit im TagEditor, der eine autonome Übersetzungsumgebung bildet und deshalb nicht von den Eigenheiten von Word abhängig ist) kommt es häufig zu Formatierungsproblemen. Keiner weiß genau, ob das die Schuld von Word oder der Workbench ist - wahrscheinlich liegt es an beiden. Auf www.proz.com könnt ihr langwierige Diskussionen zu diesem Thema lesen.
Dieses Handbuch enthält sehr viele Lesezeichen und blau dargestellte Hyperlinks, die zu Navigationszwecken auf diese Lesezeichen verweisen. Nach dem Cleanen der Dateien stellte sich heraus, dass viele dieser Lesezeichen und Hyperlinks (und oft auch die blaue Farbkodierung) verschwunden waren. Ich musste deshalb alle Dateien einzeln durchgehen und die verloren bzw. kaputt gegangene Formatierung wiederherstellen. Das dauerte ewig und war ziemlich anstrengend, weil ich wahnsinnig aufpassen musste. Aber heute morgen wurde ich endlich mit der letzten Sprache, Holländisch, fertig. Jetzt müssen wir warten, bis der Kunde die lokalisierten Screenshots liefert, dann müssen diese in die einzelnen Handbücher reinkopiert werden. Ca. 250 Screenshots pro Sprache, das wird auch wieder einige Tage dauern.
Mit dem Übersetzen hat so was nicht viel zu tun, weil es jeder, der sich einigermaßen mit Word auskennt, hätte machen können. Aber es zeigt, dass man als Übersetzer nicht nur durch das reine Übersetzen Geld verdienen kann, sondern auch mit Zusatzleistungen. Je mehr ihr einem Kunden bieten könnt, desto attraktiver seid ihr als Auftragnehmer. Wenn ihr einer Agentur euer Résumé schickt, solltet ihr unbedingt angeben, mit welchen Softwareanwendungen ihr vertraut seid und welche anderen Aufgaben ihr noch übernehmen könnt.
Ich weiß nicht, wie viel praktische Erfahrung ihr mit Trados habt, aber vor allem bei der Übersetzung mit der Trados Workbench in Word (im Gegensatz zur Arbeit im TagEditor, der eine autonome Übersetzungsumgebung bildet und deshalb nicht von den Eigenheiten von Word abhängig ist) kommt es häufig zu Formatierungsproblemen. Keiner weiß genau, ob das die Schuld von Word oder der Workbench ist - wahrscheinlich liegt es an beiden. Auf www.proz.com könnt ihr langwierige Diskussionen zu diesem Thema lesen.
Dieses Handbuch enthält sehr viele Lesezeichen und blau dargestellte Hyperlinks, die zu Navigationszwecken auf diese Lesezeichen verweisen. Nach dem Cleanen der Dateien stellte sich heraus, dass viele dieser Lesezeichen und Hyperlinks (und oft auch die blaue Farbkodierung) verschwunden waren. Ich musste deshalb alle Dateien einzeln durchgehen und die verloren bzw. kaputt gegangene Formatierung wiederherstellen. Das dauerte ewig und war ziemlich anstrengend, weil ich wahnsinnig aufpassen musste. Aber heute morgen wurde ich endlich mit der letzten Sprache, Holländisch, fertig. Jetzt müssen wir warten, bis der Kunde die lokalisierten Screenshots liefert, dann müssen diese in die einzelnen Handbücher reinkopiert werden. Ca. 250 Screenshots pro Sprache, das wird auch wieder einige Tage dauern.
Mit dem Übersetzen hat so was nicht viel zu tun, weil es jeder, der sich einigermaßen mit Word auskennt, hätte machen können. Aber es zeigt, dass man als Übersetzer nicht nur durch das reine Übersetzen Geld verdienen kann, sondern auch mit Zusatzleistungen. Je mehr ihr einem Kunden bieten könnt, desto attraktiver seid ihr als Auftragnehmer. Wenn ihr einer Agentur euer Résumé schickt, solltet ihr unbedingt angeben, mit welchen Softwareanwendungen ihr vertraut seid und welche anderen Aufgaben ihr noch übernehmen könnt.
Willkommen
Hallo ihr! Willkommen bei unserem Blog. Das ist mein allererster Blogging-Versuch und ich muss zugeben, dass ich mir ein bisschen komisch vorkomme. Eigentlich schreibe ich das nur für euch vier, aber im Internet weiß man nie, wer was sieht - vor allem, weil dieser Blog ja öffentlich zugänglich ist.
Also, ich will versuchen, jeden Tag ein paar Einträge zu machen, damit ihr einen besseren Eindruck davon erhaltet, was Übersetzer (und Projektleiter) so alles tun.
Die ersten 10 Jahre nach meinem Abschluss am MIIS 1987 (M.A. in T&I German) arbeitete ich als freiberuflicher Übersetzer für Übersetzungsagenturen in den USA. Anfänglich übersetzte ich alles, was mir angeboten wurde - von Patenten zu Vorhangstangen bis hin zu medizintechnischen Geräten. Im Laufe der Zeit erhielt ich immer mehr Aufträge aus der Softwarebranche, so dass sich ganz natürlich eine Spezialisierung auf SW-Lokalisierung und -Dokumentation entwickelte. Vor ungefähr zehn Jahren schloss ich mich dann mit einer anderen Übersetzerin, Sabine Hathaway zusammen, um auch größere Aufträge zu übernehmen, die für einen einzelnen Übersetzer zu umfangreich gewesen wären, und daraus entstand dann unsere Firma Localizers LLC (www.localizers.com).
Als kleine (SEHR kleine) Boutique-Agentur können (und wollen) wir nicht mit den großen Agenturen wie SDL und Lionbridge konkurrieren. Wir sehen unsere Stärke eher in unserer Flexibilität und unserem Kundenservice - gerade in diesen Aspekten sind wir den großen Agenturen mit ihrer inhärenten Bürokratie und Hierarchie einen großen Schritt voraus. Neben Übersetzung machen wir auch viel "linguistic review", d.h. wir überprüfen bereits lokalisierte Softwareanwendungen und machen terminologische und stilistische Verbesserungsvorschläge. Für mehrere Kunden sind wir sogar ganz für die Terminologieverwaltung zuständig.
Ich persönlich mache eigentlich alles, was gemacht werden muss: Übersetzen (EN-DE und DE-EN, letzteres allerdings wegen der geringeren Nachfrage eher selten), Korrekturlesen, Vor- und Nachbearbeitung von Dateien, Bearbeitung von Grafiken und DTP (jeweils in allen von uns unterstützten Sprachen). Es ist lustig, ein japanisches Dokument zu formatieren, das kann ich auch sagen!!! :-)
So, jetzt habt ihr einen besseren Einblick in unsere kleine Firma. Nach dem Mittagessen beschreibe ich, woran ich zur Zeit arbeite.
Gerhard
Also, ich will versuchen, jeden Tag ein paar Einträge zu machen, damit ihr einen besseren Eindruck davon erhaltet, was Übersetzer (und Projektleiter) so alles tun.
Die ersten 10 Jahre nach meinem Abschluss am MIIS 1987 (M.A. in T&I German) arbeitete ich als freiberuflicher Übersetzer für Übersetzungsagenturen in den USA. Anfänglich übersetzte ich alles, was mir angeboten wurde - von Patenten zu Vorhangstangen bis hin zu medizintechnischen Geräten. Im Laufe der Zeit erhielt ich immer mehr Aufträge aus der Softwarebranche, so dass sich ganz natürlich eine Spezialisierung auf SW-Lokalisierung und -Dokumentation entwickelte. Vor ungefähr zehn Jahren schloss ich mich dann mit einer anderen Übersetzerin, Sabine Hathaway zusammen, um auch größere Aufträge zu übernehmen, die für einen einzelnen Übersetzer zu umfangreich gewesen wären, und daraus entstand dann unsere Firma Localizers LLC (www.localizers.com).
Als kleine (SEHR kleine) Boutique-Agentur können (und wollen) wir nicht mit den großen Agenturen wie SDL und Lionbridge konkurrieren. Wir sehen unsere Stärke eher in unserer Flexibilität und unserem Kundenservice - gerade in diesen Aspekten sind wir den großen Agenturen mit ihrer inhärenten Bürokratie und Hierarchie einen großen Schritt voraus. Neben Übersetzung machen wir auch viel "linguistic review", d.h. wir überprüfen bereits lokalisierte Softwareanwendungen und machen terminologische und stilistische Verbesserungsvorschläge. Für mehrere Kunden sind wir sogar ganz für die Terminologieverwaltung zuständig.
Ich persönlich mache eigentlich alles, was gemacht werden muss: Übersetzen (EN-DE und DE-EN, letzteres allerdings wegen der geringeren Nachfrage eher selten), Korrekturlesen, Vor- und Nachbearbeitung von Dateien, Bearbeitung von Grafiken und DTP (jeweils in allen von uns unterstützten Sprachen). Es ist lustig, ein japanisches Dokument zu formatieren, das kann ich auch sagen!!! :-)
So, jetzt habt ihr einen besseren Einblick in unsere kleine Firma. Nach dem Mittagessen beschreibe ich, woran ich zur Zeit arbeite.
Gerhard
Abonnieren
Posts (Atom)
