Hallo zusammen (an alle Übersetzer und/oder LVM Benutzer),
bei LVM gibt es ja einige Abkürzungen: LV,PV,VG Diese werden in system-config-lvm auch recht häufig benutzt.
Aufgrund von Platzmangel muss man dort auch die Abkürzungen beibehalten. Nun zur Frage: Lässt man diese Abkürzungen in Englisch oder bildet sie an Hand der deutschen Übersetzung?
(Eduards IMHO sehr gute Übersetzung ist logischer Datenträger, physicher Datenträger, Datenträgergruppe)
Ich bin eigentlich für ersteres, da ich glaube, dass niemand LD,PD,DG versteht. Die Abkürzungen sollte man aber auf jeden Fall in den langen Texten bekannt machen.
Andere knifflige Wörter: Striping und Extend. Streifung ist AFAICT kein gebräuchliches oder in diesem Zusammenhang wirklich verständliches Wort. evtl "Gestreifte Anordnung"? Striping ist aber vielleicht auch schon recht verbreitet?
Extend = Bereich finde ich auch nicht so ganz treffend, ich wäre eher für Abschnitt oder Stück (wie bei einem Stück Kuchen)
Wie ist eure Meinung dazu?
Am Sa, den 16.10.2004 schrieb Ronny Buchmann um 0:03:
Hallo zusammen (an alle Übersetzer und/oder LVM Benutzer),
Ich würde sagen, das ist eher ein Fall für die fedora-trans-de@redhat.com
bei LVM gibt es ja einige Abkürzungen: LV,PV,VG Diese werden in system-config-lvm auch recht häufig benutzt.
Aufgrund von Platzmangel muss man dort auch die Abkürzungen beibehalten. Nun zur Frage: Lässt man diese Abkürzungen in Englisch oder bildet sie an Hand der deutschen Übersetzung?
Sollte laut http://elvis.redhat.com/cgi-bin/i18n-status?rm=mode7&locale=de doch bereits übersetzt sein?!
(Eduards IMHO sehr gute Übersetzung ist logischer Datenträger, physicher Datenträger, Datenträgergruppe)
[...]
Wie ist eure Meinung dazu?
Ich denke, die Bezeichnungen sollten auf jeden Fall identisch zu anaconda verwendet werden.
Christoph
P.S.: Von welchen Quellen oder RPMs reden wir eigentlich?
On Saturday 16 October 2004 15:18, Christoph Wickert wrote:
Am Sa, den 16.10.2004 schrieb Ronny Buchmann um 0:03:
Hallo zusammen (an alle Übersetzer und/oder LVM Benutzer),
Ich würde sagen, das ist eher ein Fall für die fedora-trans-de@redhat.com
Ich habe es an beide Listen geschickt um mehr Antworten von Anwendern zu bekommen.
bei LVM gibt es ja einige Abkürzungen: LV,PV,VG Diese werden in system-config-lvm auch recht häufig benutzt.
Aufgrund von Platzmangel muss man dort auch die Abkürzungen beibehalten. Nun zur Frage: Lässt man diese Abkürzungen in Englisch oder bildet sie an Hand der deutschen Übersetzung?
Sollte laut http://elvis.redhat.com/cgi-bin/i18n-status?rm=mode7&locale=de doch bereits übersetzt sein?!
100% heißt nicht automatisch 100% gut
(Eduards IMHO sehr gute Übersetzung ist logischer Datenträger, physicher Datenträger, Datenträgergruppe)
[...]
Wie ist eure Meinung dazu?
Ich denke, die Bezeichnungen sollten auf jeden Fall identisch zu anaconda verwendet werden.
sehe ich genauso, dort steht momentan "logisches Volumen" etc. Könnte man aber evtl. noch ändern. Datenträger ist IMHO deutlich verständlicher.
Christoph
P.S.: Von welchen Quellen oder RPMs reden wir eigentlich?
system-config-lvm gibt es derzeit nur im CVS
anonymous@rhlinux.redhat.com:/usr/local/CVS
On Sat, 16 Oct 2004 00:03:14 +0200, Ronny Buchmann wrote:
Hallo zusammen (an alle Übersetzer und/oder LVM Benutzer),
bei LVM gibt es ja einige Abkürzungen: LV,PV,VG Diese werden in system-config-lvm auch recht häufig benutzt.
Aufgrund von Platzmangel muss man dort auch die Abkürzungen beibehalten. Nun zur Frage: Lässt man diese Abkürzungen in Englisch oder bildet sie an Hand der deutschen Übersetzung?
Meine Wenigkeit betrachtet die komplette Eindeutschung von Fachdokumentation als Unart, die es zu Bekämpfen gilt, sofern die deutsche Terminologie nicht von einem Gremium abgesegnet wird. Vermiede, daß ein "tabbed dialog" mal in "Reiter" und mal in "Registerkarte" eingedeutscht würde. Paradebeispiel für mißlungene Übersetzungen sind Bücher zu Programmiersprachen, in denen nicht nur der englische Originaltext, sondern auch die Bezeichner und Funktionsnamen der Programmiersprache oder Programmbeispielen übersetzt wurden.
Daher würde ich bevorzugen, die englische Terminologie inklusive der Abkürzungen beizubehalten und bei ihrer ersten Einführung und in einem Glossar zu umschreiben. Sofern sich für jeden Begriff eine gute Übersetzung findet und diese Übersetzung auch konsequent bis zur Systemebene (Kommandozeilenschnittstelle z.B.) angewandt wird, kann es gerne auch umgekehrt geschehen: eingedeutsche Terminologie mit Referenz zu den englischen Originalen.
(Eduards IMHO sehr gute Übersetzung ist logischer Datenträger, physicher Datenträger, Datenträgergruppe)
Was der naheliegenden direkten Übersetzung gemäß Wörterbuch entspricht. Wobei ich "Volume Group" jedoch "Datenträgerverbund" nennen würde.
Ich bin eigentlich für ersteres, da ich glaube, dass niemand LD,PD,DG versteht.
Wer mit der deutschen Begriffsbildung beginnt, verstünde es. Ob jemand jedoch auch Abkürzungen eingedeutscht sehen möchte und ggf. zwischen englischer und deutscher Terminologie hin- und herwechseln müßte, halte ich für fraglich.
Andere knifflige Wörter: Striping und Extend. Streifung ist AFAICT kein gebräuchliches oder in diesem Zusammenhang wirklich verständliches Wort. evtl "Gestreifte Anordnung"?
Streifenförmige Anordnung.
Striping ist aber vielleicht auch schon recht verbreitet?
Extend = Bereich finde ich auch nicht so ganz treffend, ich wäre eher für Abschnitt oder Stück (wie bei einem Stück Kuchen)
Wie ist eure Meinung dazu?
Trifft meiner Ansicht nach nicht die Verwendung im Englischen. Extend = "Belegungseinheit" oder "Einteilungseinheit" war doch schon recht gängig, falls ich mich nicht irre.
Am So, den 17.10.2004 schrieb Michael Schwendt um 15:07:
Meine Wenigkeit betrachtet die komplette Eindeutschung von Fachdokumentation als Unart, die es zu Bekämpfen gilt, sofern die deutsche Terminologie nicht von einem Gremium abgesegnet wird.
Daher würde ich bevorzugen, die englische Terminologie inklusive der Abkürzungen beizubehalten und bei ihrer ersten Einführung und in einem Glossar zu umschreiben. Sofern sich für jeden Begriff eine gute Übersetzung findet und diese Übersetzung auch konsequent bis zur Systemebene (Kommandozeilenschnittstelle z.B.) angewandt wird, kann es gerne auch umgekehrt geschehen: eingedeutsche Terminologie mit Referenz zu den englischen Originalen.
Hmm. Meiner Meinung nach kommt es drauf an, welches Programm übersetzt wird. Gerade bei system-config Sachen u.ä. würde ich eher zu verständlichem Deutsch tendieren. Mittlerweile installieren Leute (meist SuSe-)Linux, die noch nicht mal die "Kommandozeile" von Windows kennen. Wenn man denen mit einem Cron Job oder einer Volume Group kommt, verstehen sie nur Bahnhof. Letzteres wird mit Sicherheit als erstes mit der Soundkarte in Zusammenhang gebracht... ;) Die Übersetzung sollte natürlich so gut sein, dass auch noch der Fachmann versteht, um was es sich eigentlich dreht.
Bei Anwendungen wie Anjuta stimme ich Dir allerdings 100% zu.
Die Welt ändert sich. Für Freaks bleiben ja noch die pure Kommandozeile und die kryptischen Editoren (Emacs,vi,...).
PS: Bin kein Freak und auch kein IT'ler, nur ein Benutzer mit geringfügigen Programmierkenntnissen (am C64 konnte ich mehr wie jetzt)
On Sun, 2004-10-17 at 23:02 +0200, Frank Arnold wrote:
Am So, den 17.10.2004 schrieb Michael Schwendt um 15:07:
Meine Wenigkeit betrachtet die komplette Eindeutschung von Fachdokumentation als Unart, die es zu Bekämpfen gilt, sofern die deutsche Terminologie nicht von einem Gremium abgesegnet wird.
Ich weiß nicht, ob ich das Gremien überlassen würde -- siehe Hickhack um die neue Rechtschreibung ;-).
Daher würde ich bevorzugen, die englische Terminologie inklusive der Abkürzungen beizubehalten und bei ihrer ersten Einführung und in einem Glossar zu umschreiben. Sofern sich für jeden Begriff eine gute Übersetzung findet und diese Übersetzung auch konsequent bis zur Systemebene (Kommandozeilenschnittstelle z.B.) angewandt wird, kann es gerne auch umgekehrt geschehen: eingedeutsche Terminologie mit Referenz zu den englischen Originalen.
Hmm. Meiner Meinung nach kommt es drauf an, welches Programm übersetzt wird. Gerade bei system-config Sachen u.ä. würde ich eher zu verständlichem Deutsch tendieren. Mittlerweile installieren Leute (meist SuSe-)Linux, die noch nicht mal die "Kommandozeile" von Windows kennen. Wenn man denen mit einem Cron Job oder einer Volume Group kommt, verstehen sie nur Bahnhof. Letzteres wird mit Sicherheit als erstes mit der Soundkarte in Zusammenhang gebracht... ;) Die Übersetzung sollte natürlich so gut sein, dass auch noch der Fachmann versteht, um was es sich eigentlich dreht.
Meist ist es doch so, dass wenn solche Fachbegriffe eingedeutscht werden, keiner mehr versteht worum's geht -- der Neuling weil ihm die Zusammenhänge fehlen und der alte Hase weil jetzt wieder "mit Gewalt" ein deutscher Begriff verwendet werden musste. Jemand, der sich noch nie mit LVM auseinander gesetzt hat, muss es sich erst mal von jemandem erklären lassen. Typischerweise ist das dann jemand, der ihm auch die Begriffe beibringt ;-).
Ich würde erst dann einen deutschen Begriff verwenden, wenn ich nicht derjenige bin, der ihn einführt, konkret würde ich also bei "Logical Volume Management", "Volume Group", "Physical/Logical Volume", "Striping" bleiben (auch wenn es schmerzen sollte ;-), da dies die Fachbegriffe sind und es bisher keine deutschen Äquivalente gibt, die sich in irgendeiner Weise durchgesetzt haben.
Nils
Am So, den 17.10.2004 schrieb Michael Schwendt um 15:07:
Meine Wenigkeit betrachtet die komplette Eindeutschung von Fachdokumentation als Unart, die es zu Bekämpfen gilt, sofern die deutsche Terminologie nicht von einem Gremium abgesegnet wird.
Ich denke das ist keine Unart, sondern die Unfähigleit mancher sich in seiner eigenen Sprache für andere verständlich auszudrücken. Da steht der Schrei nach einem Gremium natürlich im Vordergrund.
Frank Arnold wrote:
Hmm. Meiner Meinung nach kommt es drauf an, welches Programm übersetzt wird. Gerade bei system-config Sachen u.ä. würde ich eher zu verständlichem Deutsch tendieren. Mittlerweile installieren Leute (meist SuSe-)Linux, die noch nicht mal die "Kommandozeile" von Windows kennen.
Was spricht eigentlich dagegen, das Leute Linux installieren die die Kommandozeile nicht kennen. Umgekehrt wird ein Schuh draus: Ein Betriebssystems was heute noch Kenntnisse selbigens verlangt ist überholt und an der Realität vorbei für eine handvoll, wie nennst du es, Freaks konzipiert. Die breite Masse wird ausgeschlossen und da nicht erwünscht wird die Dokumentation natürlich ebenfalls nicht für die Masse verfasst.
Also ist es nicht die Frage: übersetze ich alles oder nicht, sondern die Frage muss doch lauten: Wer benötigt das Wissen und ist der Verfasser der Dokumentation gewillt sie jemanden der kein Englisch spricht zugänglich zu machen oder sagt er ganz einfach: wer mit diesen Dingen zu tun hat, muss auch die Sprache sprechen. Eine übrigens sehr verbreitete, wenn auch meiner Ansicht nach falsche Meinung.
Michael
On Mon, 18 Oct 2004 10:59:44 +0200, Michael Kollender wrote:
Meine Wenigkeit betrachtet die komplette Eindeutschung von Fachdokumentation als Unart, die es zu Bekämpfen gilt, sofern die deutsche Terminologie nicht von einem Gremium abgesegnet wird.
Ich denke das ist keine Unart, sondern die Unfähigleit mancher sich in seiner eigenen Sprache für andere verständlich auszudrücken. Da steht der Schrei nach einem Gremium natürlich im Vordergrund.
Nun, "domain" mit "Domäne" zu übersetzen, oder "daemon" mit "Dämon", könnte auch eher an schlechtem Geschmack liegen, anstatt an Unfähigkeit. Aus "e-mail" statt "die e-Mail" (_die_ elektronische Post!) "das Mail" zu machen, ebenso. Vielleicht bin ich aber auch nur uninformiert, und Grammatikexperten oder Linguisten haben für sowas eine Begründung.
Wobei ich mich gerade frage, wie denn RAID eingedeutscht wirken würde. Oder LVM selbst.
Was spricht eigentlich dagegen, das Leute Linux installieren die die Kommandozeile nicht kennen.
Nichts. Nur fände ich eine unvollständige Übersetzung inkonsequent. Mal angenommen, auf Systemebene würden englische Abkürzungen erhalten bleiben, etwas ein fiktives /dev/lvm/* (allein schon /dev könnte /ger sein). Oder automatische Partitionierung zu Beginn einer deutschsprachigen Installation würde /dev/VolGrp01/Vol* anlegen. Vermeidbar, wenn man sich gar nicht erst darauf einläßt, übereifrig Fachbegriffe einzudeutschen.
Umgekehrt wird ein Schuh draus: Ein Betriebssystems was heute noch Kenntnisse selbigens verlangt ist überholt und an der Realität vorbei für eine handvoll, wie nennst du es, Freaks konzipiert. Die breite Masse wird ausgeschlossen und da nicht erwünscht wird die Dokumentation natürlich ebenfalls nicht für die Masse verfasst.
Über den heutzutage erreichbaren Abstraktionsgrad läßt sich prima streiten. Der Nutzer wird besonders bei der Installation und Wartung noch zwangsläufig mit Fachbegriffen und kompliziert wirkenden Konzepten konfrontiert: Partitionen (warum überhaupt partitionieren?), Megabyte, Gigabyte, Swap Space ("Auslagerungsspeicher"), Cache, Master Boot Record, Boot Loader, USB, AGP, ATAPI, Firewire, Formatieren, usw.usf. Aber auch bei der Nutzung: HTTP, HTTPS, SSL, Cookies ("Kekse"? "Marken"? "Stempel"?), Flash, usw.usf. Nicht zu vergessen, verwirrende Namensgebungen, wie JavaScript vs. Java.
Braucht der Nutzer zu wissen, wie groß eine Festplatte ist? Reichte es nicht, wenn die Datenträgergröße in "Anzahl speicherbarer Bilder oder Dokumente durchschnittlicher Größe" angegeben würde? ;) Ähnlich wie die Beschreibung von Volumentarifen, mit denen der Nutzer monatlich 200.000 Webseiten und 100.000 e-Mails abrufen könne. Gefiele mir überhaupt nicht, und ich kann auch nichts weiter zur generellen Akzeptanz solcher Abstraktionen sagen.
Also ist es nicht die Frage: übersetze ich alles oder nicht, sondern die Frage muss doch lauten: Wer benötigt das Wissen und ist der Verfasser der Dokumentation gewillt sie jemanden der kein Englisch spricht zugänglich zu machen oder sagt er ganz einfach: wer mit diesen Dingen zu tun hat, muss auch die Sprache sprechen. Eine übrigens sehr verbreitete, wenn auch meiner Ansicht nach falsche Meinung.
Erläuterung von Sachverhalten und Konzepten in deutscher Sprache mit Bezug zur englischen Terminologie hielte ich für praktikabel. Sofern sich daraus eine breite Kultur entwickelte, ließe es sich ausweiten. Aber eher unwahrscheinlich...
On Monday 18 October 2004 12:08, Michael Schwendt wrote:
Nun, "domain" mit "Domäne" zu übersetzen, oder "daemon" mit "Dämon", könnte auch eher an schlechtem Geschmack liegen, anstatt an Unfähigkeit.
Über Geschmack muss man sich ja nicht streiten, Domäne ist ein durchaus verständliches Wort und trifft den Sinn auch ganz gut (bessere Begriffe will ich nicht ausschließen, aber man sollte auch mal drüber nachdenken, ob der Originalbegriff sinnvoll ist.)
Bei daemon möchte ich Dir eigentlich Recht geben, aber andererseits vermute ich, dass Dämon auf einen deutschsprachigen Laien genauso wirkt, wie daemon auf einen englischsprachigen.
Aus "e-mail" statt "die e-Mail" (_die_ elektronische Post!) "das Mail" zu machen, ebenso. Vielleicht bin ich aber auch nur uninformiert, und Grammatikexperten oder Linguisten haben für sowas eine Begründung.
die E-Mail Dass in einigen Teilen Deutschlands der Hang zu einer recht eigenwilligen Grammatik vorhanden ist, will ich nicht abstreiten...
Also ist es nicht die Frage: übersetze ich alles oder nicht, sondern die Frage muss doch lauten: Wer benötigt das Wissen und ist der Verfasser der Dokumentation gewillt sie jemanden der kein Englisch spricht zugänglich zu machen oder sagt er ganz einfach: wer mit diesen Dingen zu tun hat, muss auch die Sprache sprechen. Eine übrigens sehr verbreitete, wenn auch meiner Ansicht nach falsche Meinung.
Erläuterung von Sachverhalten und Konzepten in deutscher Sprache mit Bezug zur englischen Terminologie hielte ich für praktikabel. Sofern
das ist leider nicht so praktikabel, denn a) wenn man Programmoberflächen übersetzt, ist der Platz für Erläuterungen nicht vorhanden b) die Übersetzung/Erweiterung der Dokumentation (soweit überhaupt vorhanden) benötigt äußerst viel Resourcen.
Am Mo, den 18.10.2004 schrieb Michael Kollender um 10:59:
Was spricht eigentlich dagegen, das Leute Linux installieren die die Kommandozeile nicht kennen. Umgekehrt wird ein Schuh draus: Ein Betriebssystems was heute noch Kenntnisse selbigens verlangt ist überholt und an der Realität vorbei für eine handvoll, wie nennst du es, Freaks konzipiert. Die breite Masse wird ausgeschlossen und da nicht erwünscht wird die Dokumentation natürlich ebenfalls nicht für die Masse verfasst.
Ich habe mich evtl. mit "(SuSe-) Linux" etwas missverständlich ausgedrückt. Das war nur eine nicht wertende Beobachtung aus meinem Umfeld. Ich finde es auch schade, dass diese Leute aus Enttäuschung manchmal wieder zu Windows zurückkehren.
Am Mo, den 18.10.2004 schrieb Michael Schwendt um 12:08:
Über den heutzutage erreichbaren Abstraktionsgrad läßt sich prima streiten. Der Nutzer wird besonders bei der Installation und Wartung noch zwangsläufig mit Fachbegriffen und kompliziert wirkenden Konzepten konfrontiert: Partitionen (warum überhaupt partitionieren?), Megabyte, Gigabyte, Swap Space ("Auslagerungsspeicher"), Cache, Master Boot Record, Boot Loader, USB, AGP, ATAPI, Firewire, Formatieren, usw.usf. Aber auch bei der Nutzung: HTTP, HTTPS, SSL, Cookies ("Kekse"? "Marken"? "Stempel"?), Flash, usw.usf. Nicht zu vergessen, verwirrende Namensgebungen, wie JavaScript vs. Java.
Diese Beispiele sprechen natürlich allesamt nicht für eine Übersetzung. Lernwillige Windows Benutzer kennen diese und komplette Computer-Neulinge, die sich sofort mit Linux auseinander setzen, haben wohl meist eine Art Mentor.
Braucht der Nutzer zu wissen, wie groß eine Festplatte ist? Reichte es nicht, wenn die Datenträgergröße in "Anzahl speicherbarer Bilder oder Dokumente durchschnittlicher Größe" angegeben würde? ;)
Leider ist es schon soweit. Schau Dir einfach mal Werbung für MP3-Player an. "Bis zu 5000 Songs" war ein Statement in der letzten Tchibo-Werbung. Vom der Größe des Speichers habe ich nichts gelesen... ;) Auf Betriebssysteme sollte man das natürlich nicht ausweiten.
Das Problem zur Zeit liegt wohl darin, dass recht viele GUIs übersetzt werden. Die dazugehörige Dokumentation (z.B. Hilfe) aber eher nicht, da hier der Aufwand recht groß ist.
de-users@lists.fedoraproject.org