Ich habe das Woerterbuch von drupalcenter und google code zusammengefasst (zwischen dem englischen und deutschen Begriff steht ein Tabulatorzeichen).
Im Prinzip müsste sich diese Datei auch zu TMX bzw. po konvertieren lassen, ein Problem könnte dabei die Zeilen sein, die zwei Übersetzungsvorschläge haben mit Komma getrennt.
access control Zugriffskontrolle
account Benutzerkonto
activated aktiviert
active aktiv
add hinzufügen
administer verwalten
administrator Administrator
anonymous Gast
approved freigegeben
archive Archiv
article Artikel
attachment Anhang
authorized individual berechtigte Person
block Block
blog Weblog
body Haupttext
book outline Inhaltsverzeichnis
browse durchsuchen
button Schaltfläche
capture aufzeichnen
categorize kategorisieren
category Kategorie
chapter Kapitel
check auswerten; sicherstellen
checkboxes Ankreuzfeld
child untergeordnet
clean URLs lesbare URLs
collaborative gemeinschaftlich
configuration Konfiguration
content Inhalt
content types Inhaltstypen
create erstellen
created erstellt
cron Cron
customization Anpassung
date Datum
debugging Auffinden von Fehlern
default Standard-
delete löschen
deleted gelöscht
display mode Ansicht
displayed angezeigt
drag and drop Drap-and-Drop
e-mail E-Mail
edit bearbeiten
event Ereignis
expanded view vollständige Ansicht
feed Newsfeed
filter (n.) Filter
filter (v.) filtern
form Formular
forum Forum
forums Foren
fully-qualified vollständig
handbook Handbuch
handbook page Handbuchseite
help text Hilfetext
home Startseite
hyperlink Verweis
information Informationen
input format Eingabeformat
interval Intervall
item Element
last neueste
legacy Rückwärtskompatibilität
link Link, verlinken
location Adresse
log Protokoll
log in anmelden
log message Protokollnachricht
log out abmelden
main page Startseite
menu item Menüpunkt
message Nachricht
message type Nachrichtentyp
moderate moderieren
moderator Moderator
module Modul
move verschieben
never nie
news feed Newsfeed
next nächstes
node Beitrag
notice Mitteilung
on a regular basis regelmäßig
options Optionen
organize gliedern
orphan verwaist
outline Gliederung
overview Übersicht
page Seite
parent übergeordnet
parse error Verarbeitungsfehler
permission Berechtigung
poll Umfrage
post Beitrag
post (n.) Beitrag
post (v.) speichern/beitragen
post type Inhaltstyp
previous vorheriges
printer-friendly druckerfreundlich
promote to front page Auf der Startseite anzeigen
public öffentlich
publication Veröffentlichung
publish veröffentlichen
queue Warteschlange
RDF feed RDF-Newsfeed
register registrieren
reply (n.) Antwort
reply (v.) antworten
result Ergebnis
revision Version
role Rolle
RSS feed RSS-Newsfeed
search output Suchergebnis
section Abschnitt
session Sitzung
setting Einstellung
severity Schweregrad
sibling nebengeordnet
site Website
story Artikel
string Zeichenkette
submission queue Beitragswarteschlange
submit speichern
Suggestion Vorschlag
syndicate abgleichen
system System-
system event Systemereignis
tab Reiter
taxonomy Taxonomie
teaser Anrisstext
themable anpassbar, Design anpassbar
theme Theme
threaded view Themenansicht
threshold Grenzwert
throttle Lastreduzierung
title Titel
topic Thema
trackback Trackback
unpublished unveröffentlicht
update aktualisieren
URL URL
user Benutzer
user profile Benutzerprofil
view ansehen; betrachten
visitor Besucher
vital unerlässlich
waiting wartend
warning Warnung
watchdog Wächter
weight Reihenfolge
who's online Momentan online
workflow Arbeitsablauf
Weblog als Übersetzung für Blog ist nicht mehr zeitgemäß. Das Wort Blog hat sich im Deutschen durchgesetzt und auch Wikipedia leitet Blog nicht mehr auf Weblog um.
Wächter für watchdog ist eine unglückliche Übersetzung. Wie wär's mit Systemprotokoll oder Ereignisanzeige (Microsoft-Jargon)?
never kann aus der Liste gestrichen werden.
Wie ist Core zu übersetzen, wenn Drupal Core gemeint ist? Vielleicht Kernfunktionalität oder Grundfunktionen?
Können wir uns zunächst auf die Mittel einigen, bevor die Begriffsdiskussion sich unübersichtlich über mehrere Orte und unzählbare Kommentare verteilt? Und auch das wiederholte, erneute Einstellen der Wortliste halte ich für wenig sinnvoll. Wer wird all die Änderungen nachverfolgen?
Ich denke, dabei an diese Punkte, ohne ins Detail zu gehen:
Wörterbucheinträge können diskutiert werden.
Mitglieder können über Änderungen benachrichtigt werden.
Mitglieder können neue Einträge vorschlagen und diskutieren.
Mit Ansichten kann das Wörterbuch in unterschiedlichen Formaten dargestellt werden -- ansehen und exportieren.
Das Wörterbuch kann durchsucht werden; mit passender URL könnte man auch durch URL-Kürzel darauf zugreifen: "w Schlagwort" --> "http://Abc.de/Wörterbuch/Schlagwort"
Eine Drupal-Seite mit eigenen Inhaltstypen und Feldern würden es ermöglichen, Übersetzungen und Diskussionen einander zuzuordnen, Übersetzungen zu markieren ("zur Diskussion", "offizieller Eintrag",...) usw. Das würde auch helfen, die Gedanken zu dokumentieren, damit Wiederholungen vermieden werden können und neue Mitglieder sehen, was passiert ist.
Ja, norwegische Wortliste gut und schön und natürlich kann man das mehrmals vorschlagen. Aber irgendwer musses auch tun.
Bis dahin find ich's nicht so schlimm, das in nem Thread zu diskutieren und ab und zu das Posting mit der Liste zu editieren. Besser als wenn jemand 3 Tage lang eine Wortlisten-Site hackt und die dann niemand benutzt. Es scheinen sowieso nur 5 Leute Übersetzungen im großen Stil beizutragen.
Na dann, "gut und schön" muss ich nicht haben. Es wird ganz sicher niemand tun, wenn niemand sagt, dass er es nutzen würde. Oft genug darauf hingewiesen habe ich, das ist war. Allerdings, es gibt keinen Beitrag zur Sache... Insofern sehe ich kein "bis dahin". Wenn die Mehrheit den Vorteil nicht selbstständig erkennt, werde ich sie davon auch nicht überzeugen. Natürlich funktioniert es in einer langen Diskussion, verstreut über viele Orte und vermengt zu vielen einzelnen Übersetzungen. Es ist, als wolle man die Zugspitze mit Schippe und Eimer abtragen. Anfangs ist es noch übersichtlich und es geht "schnell", die eigentliche Arbeit wird ohne schweres Gerät nicht zu bewältigen sein: Wer behält den Überblick? Was ist mit denen, die sich später oder nach uns engagieren wollen? Woran können wir die Verlässlichkeit festmachen, die dieses Projekt braucht? Ich habe kein Interesse an Übersetzungen, die durch Bauchgefühl und Wechselhaftigkeit der "Entscheider" (aka Übersetzter) festgeschrieben werden. Diese präsentieren sich hier zuweilen selbst mit schrecklichem Deutsch, oder halten sich mit Debatten über "Wer hat die meisten Einzelübersetzungen" auf. Die Qualität verkommt zu oft zur Randerscheinung. Ein Beispiel, welches hier sicher jedem schon einmal untergekommen ist: Engl. "to control" ist im Deutschen nur sehr, sehr selten "kontrollieren". "Access control" ist sicher keine dieser Ausnahmen, und entsprechend nicht mit "Zugriffskontrolle" zu übersetzen, sondern etwa mit "Zugriffssteuerung". "Kontrollieren" hat etwas mit Aufsicht, Überprüfung, Probe oder (Selbst-) Beherrschung zu tun. Weitere beliebte Schnitzer sind Verklausulierungen (oft im Zusammenhang mit engl. "of" und dt. "von"), unnütze Worterweiterungen ((Be-) Nutzer), feinstes Denglisch (inklusive Deppenleerzeichen und sächsischem Genitiv) und Rechtschreibfehler (besonders falsches "ss" anstatt "ß"). Derlei fehler- oder laienhafte Übersetzungen finden sich zu häufig, was zunächst auf das Gesamtpaket "deutsche Übersetzung" und dann auch auf Drupal als solches zurückfällt. Schließlich ist auch die deutsche Sprache betroffen, wenn diese Fehler in die Welt getragen werden. Liebe Eltern, mit dieser Sprache wachsen eure Kinder auf, und verlieren dabei jede Logik, die dem Deutschen innewohnt: nutzbringend, nützlich, nutzen, Nutzer -- nicht etwa "User"; und schlimm ist's, wenn nicht bekannt ist, dass im "Chicken-Döner" Hähnchen ist. Und, liebe Kinder, wie steht's um die Deutschnoten? Gibt es für euch noch ein Englisch außerhalb der Spiele- und Computerwelt? -- Kurz, so etwas macht die deutsche Übersetzung unbrauchbar, was für mich dazu geführt hat, dass ich seit Drupal 6 eigene Übersetzungen pflege. Ich kenne den Aufwand, auch wenn es sich auf die Oberfläche für Gäste und reguläre Nutzer beschränkt. Dieser Aufwand und die Aktivität der deutschen Übersetzergemeinschaft (Umzug auf l.d.o usw.) waren für mich Anlass, mich für eine Drupal-7-Übersetzung einzubringen. Mir ist auch bewusst, dass eine gemeinschaftliche Übersetzung unwahrscheinlich jeden 100%ig zufriedenstellen wird, und dass die Sprache für manche Projekte bedeutsamer ist, als für andere. Das aktuelle Maß ist jedoch, wie gesagt, unbrauchbar. Das mitzuändern bin ich gern bereit. Nicht jedoch, wenn ich mich regelmäßig erst durch zig Orte wühlen muss, um zu gucken, welches Thema besprochen wird, und wie sein aktueller Stand ist. Ich denke auch, das erstickt früher oder später jedes Engagement. Diese Zeit könnte den Übersetzungen zugute kommen. Der aktuell oben zu lesende Satz spricht Bände: "OK, habe nach 3 Zeilen schon keine Lust mehr so das Wörterbuch zu pflegen. Ein CT sowie View-Ausgabe muss her." In diesem Sinne, viel Erfolg! -- Gemeinsam, oder auf getrenntem Weg.
Es wird ganz sicher niemand tun, wenn niemand sagt, dass er es nutzen würde.
Natürlich würde ich so ein System gerne nutzen. Ist ja wohl klar.
Natürlich funktioniert es in einer langen Diskussion, verstreut über viele Orte und vermengt zu vielen einzelnen Übersetzungen. Es ist, als wolle man die Zugspitze mit Schippe und Eimer abtragen.
Unzählige FAQs sind über Jahrzehnte genau so aus Usenet- oder Forenthreads entstanden und das klappt ganz gut: Ein Maintainer stöbert ab und zu durch den Thread und aktualisiert das offizielle FAQ, damit die anderen alles bequem in einem Dokument haben.
Heutzutage kann man das in Wiki-Form noch deutlich effizienter machen, vor allem, wenn die User verantwortungsvoll ändern, wovon man bei uns ausgehen kann.
Was ist mit denen, die sich später oder nach uns engagieren wollen?
Ich verstehe die Frage nicht. Ob ein Anfänger eine Wortliste von einem eigenen System herunterlädt oder aus einem Wiki ist doch egal.
Woran können wir die Verlässlichkeit festmachen, die dieses Projekt braucht?
Das läuft wie bei allen OpenSource-Projekten: Entweder vollständig ungeordnet, d.h. jeder Kontributor macht "best effort" oder mit einem Workflow über einen Maintainer, den es ja bereits gibt.
Ich habe kein Interesse an Übersetzungen, die durch Bauchgefühl und Wechselhaftigkeit der "Entscheider" (aka Übersetzter) festgeschrieben werden. Diese präsentieren sich hier zuweilen selbst mit schrecklichem Deutsch
Drupal-Prinzip "scratch your own itch". Ich fand auch viele Übersetzung grauenhaft und habe mich sehr darüber geärgert, dass Strings in wichtigen Modulen in D6 nicht oder falsch übersetzt waren. Das ist der Grund, warum ich Übersetzungen beigetragen habe und jetzt wieder beitrage. Wenn Du Dich einbringst und gute Übersetzungen machst, kannst Du auch das Recht bekommen, schlechte Übersetzungen zu verwerfen oder den besten Übersetzungsvorschlag als offizielle Übersetzung zu akzeptieren. Einfach machen!
was für mich dazu geführt hat, dass ich seit Drupal 6 eigene Übersetzungen pflege.
Wo sind die? Wo kann man die begutachten oder herunterladen? Wo ist diese Arbeit in die Community zurückgeflossen?
Nicht jedoch, wenn ich mich regelmäßig erst durch zig Orte wühlen muss, um zu gucken, welches Thema besprochen wird, und wie sein aktueller Stand ist.
Ich verstehe Dein Problem nicht. Es ist doch völlig egal, in welcher Form eine aktuelle Wortliste vorliegt, Hauptsache sie ist verbindlich und aktuell.
Ich denke auch, das erstickt früher oder später jedes Engagement. Diese Zeit könnte den Übersetzungen zugute kommen.
Umgekehrt wird ein Schuh draus: Statt in vielen Stunden in System zu bauen und zu pflegen, in dem dasselbe drinsteht wie in einer z.B. von Thomas aktualisierten Seite, sollten Leute lieber Übersetzungen vorschlagen oder "approven".
In diesem Sinne, viel Erfolg! -- Gemeinsam, oder auf getrenntem Weg.
Nochmal: Das hier ist kein Restaurant, wo man anderen aufträgt, was man gerne hätte, es ist noch nicht einmal ein Selbstbedienungsrestaurant, es ist eine Küche. Jeder ist froh, wenn Du kochst. Jeder ist froh, wenn Du einen neuen Herd anschaffst. Jeder ist froh, wenn Du Norweger nach einem Herd fragst. Aber sich hinsetzen und über das Essen (oder gar den Verfall der deutschen Sprache) zu lamentieren und/oder beleidigt abzuziehen ist kein adäquates Verhalten. Nichts für Ungut, aber das musste mal gesagt werden.
Wenn Du Dich mit Drupal auskennst, wirst Du so ein System selber erstellen können. Oder Du kannst die Norweger fragen, ob sie es Dir geben. Oder Du kannst jemanden bitten/beauftragen, so ein System zu entwickeln. Ich hätte Interesse, aber schätze den Zugewinn gegenüber der manuell gepflegten Liste nicht besonders groß ein.
Ich sehe das ähnlich wie Linulo. Das anhand einer von jedem editierbaren Wiki-Seite zu handhaben, hat sich ja auch schon in den anderen Grupppen etabliert. So schlimm finde ich das gar nicht.
Es scheinen sowieso nur 5 Leute Übersetzungen im großen Stil beizutragen.
Als der Übersetzungsserver noch bei Drupal war (na eigentlich kkaefer.com), habe ich fleißig an den Übersetzungen mitgearbeitet und auch approved. Nachdem Konstantin aber meinte, der Drupal-Übersetzungsserver sei nicht gut genug, und ihn einfach zur Krake Google verlegt hatte, hatte ich keine Lust mehr, mitzuarbeiten.
Wenn sich die aktuelle Kindergartendiskussion a la "meine Schüppe ist schöner als deine Schüppe" gelegt hat, werde ich wieder mitarbeiten. Die Werkzeuge, die einem zur Verfügung stehen, sollten dann auch genutzt werden.
Ich werde also abwarten, bis die Arbeitsabläufe, zu nutzende Ressourcen usw. festgelegt sind und dann werde ich wieder einsteigen. Bis dahin ist mir meine Zeit zu kostbar, um mich in diese Diskussion zu verstricken.
Also, überlegt mal, warum nur 5 Leute Übersetzungen in großem Stil beitragen!
Ja, so ähnlich ging's mir auch, druppi. Gabor war sein Server noch nicht gut genug und er wurde nicht auf d.o installiert. Konstantin hat dann einfach einen aufgesetzt und ich habe da auch mitübersetzt und approved. Meine Einstellung gegenüber Google ist etwas differenzierter. Ich habe überhaupt kein Problem damit, eine Übersetzung auf Google Code zu verwalten wenn sie sowieso OpenSource ist und bei allem berechtigten Google-Gebashe darf man auch nicht vergessen, dass Google mit vielen Summer of Code Projekten für Drupal kräftig mithilft, Drupal besser zu machen.
Was mich am meisten geärgert hat, war, dass es für D6 monatelang keine po-Datei gab, die man in Drupal importieren konnte, nur die Version mit 20 einzelnen po-Dateien (pro Modul).
Auch heute noch hat der Localization Server Unzulänglichkeiten, die seinen Nutzen einschränken, aber die Import- und Exportfunktionen sind inzwischen gut, was das ein wenig ausgleicht. Ideal wäre, wenn die Bedienung des Localization Servers so beschleunigt werden könnte, dass er sich genauso flüssig wie ein offline-Editor benutzen lässt. Insbesondere die zum Approven nötigen Arbeitsabläufe sind noch inakzeptabel umständlich.
Egal. Drupal ist toll und ich möchte, dass D7 bei Release einen hochwertig und vollständig übersetzten Core hat und die wichtigsten Module auch und ich werde nach Kräften mithelfen, dass das erreicht wird. Die beste Zeit zu helfen ist genau jetzt, nach String Freeze und bevor alle kritischen Bugs gefixt sind. Daher wäre es kontraproduktiv, ausgerechnet jetzt abzuwarten.
Warum nur 5 Leute intensiv mitarbeiten ist klar: Die meisten Leute nehmen gerne aber sind nicht bereit, selber etwas zu geben. Die Infrastruktur mag nicht perfekt sein, aber trotzdem kann jeder, der es will, mitarbeiten, und auch sinnvoll mitarbeiten. Wenn mal eine von 30 Übersetzungen nicht perfekt ist weil vielleicht eine Wörterliste nicht up-to-date ist, ist das kein Beinbruch, dann haben wir halt ab und zu nicht ganz perfekte Übersetzungen. Ein Grund, nicht zu helfen, ist das nicht, nur eine Ausrede.
In den Strings taucht es immer in Verbindung mit "modules" auf.
Vorschläge für "core modules": Grundmodule, Drupal-Kern, Drupal-Kernfunktionen, Kernfunktionen.
Vorschläge für "contributed modules": Zusatzmodule, zusätzliche Module.
Wir sind ja nicht die einzigen, die eine Wörterliste pflegen wollen und der Localization Server bietet doch alle Funktionen, die wir brauchen, um eine solche Liste kollaborativ zu pflegen. Wäre es da nicht naheliegend, aus der Wörterliste einfach ein eigenes Projekt für localize.drupal.org zu machen? Wir hätten mit einem Schlag eine schöne Oberfläche, bereits bestehende Accounts, Import/Export, etc.
Beachte: Das Projekt "Dictionary" hier im Localization-Server ist keine Wörterliste sondern ein gleichnamiges Drupal-Modul.
man könnte das sogar noch ausbauen, wenn man bei der Übersetzung eines Textes die relevanten Wörter oder Wortsequenzen aus dem Wörterbuch eingeblendet bekommt (nicht als Satz, sondern als Wortliste). Das würde dann mit Sicherheit dazu führen, dass die Übersetzung vereinheitlicht wird (weil man nicht mehr "nachschauen" muss).
Da ich kein Modulentwickler bin, kann ich auch nur mit Ideen aushelfen :(
Nanu? Wo ist denn der Wörterbuch-Eintrag für "password" geblieben? Ich bin mir sicher, dass wir in DICTIONARY.TXT dafür "Kennwort" stehen hatten. Jetzt sehe ich aber etliche Suggestions und sogar Übersetzungen mit "Passwort". Ich finde "Kennwort" besser, aber inzwischen kennt der Duden "Passwort" und Wikipedia leitet sogar von "Kennwort" auf "Passwort" um. Ich gehe davon aus, dass es an der Zeit ist, auf "Passwort" umzuschwenken.
Was im Englischen mit einem Wort beschrieben werden kann, muss im Deutschen häufig durch kompliziertere Umschreibungen ausgedrückt werden. "Fetcher" so zu übersetzen halte ich für extrem schlecht (aber einfach).
M.E. müsste man es mit "Programm zum..." oder "Funktion[alität] zum..." übersetzen. Ich habe hier bewusst nicht "...Abrufen" verwendet weil:
"Programm zum Herunterladen von Daten aus einer externen Quelle. Ein geeignetes Programm [oder eine geeignete Funktion, je nach Kontext] für die externe Quelle wählen, aus der die Daten geladen werden sollen"
Ich finde, dass die deutsche Sprache in diesem Fall doch so einfach ist.
Ich hole ein wenig aus: Im Aggregator-Modul wird erklärt, was mit RSS-Feeds gemacht werden kann. Sie werden von irgendwoher geholt (z.B. von einer URL), lexikalisch analysiert (z.B. gemäß RSS-Standard) und verarbeitet (z.B. abgespeichert). Für die lexikalische Analyse existiert im Englischen und im Deutschen ein Fachbegriff (to parse / parsen), für die beiden anderen Schritte aber nicht. Die Autoren des Aggregator-Moduls haben neue Fachbegriffe eingeführt, die es mit dieser speziellen Bedeutung für Newsfeeds vorher nicht gab: "Fetcher" für die Komponente, die den Feed holt und "Processor" für eine Komponente, die den Feed verarbeitet.
Wenn ein gebürtig Englischsprechender das Wort "Fetcher" liest, wird er wissen, dass etwas gemeint ist, das irgendetwas heranschafft, herholt. Dasselbe gilt für das deutsche "Abrufer".
Entschuldige, wenn ich erst eine Frage stelle und dann besserwisserisch korrigiere wenn Du einen Vorschlag machst. Die Überzeugung ist erst langsam gereift, dass die "Abrufer"-Übersetzung in meinen Augen die beste ist.
P.S.: "abrufen" trifft es besser als "holen", weil das Holen periodisch wiederholt wird. Im Englischen gibt es AFAIK kein Wort, das das so ausdrückt wie das deutsche "Abrufen".
For more information, see the online handbook entry for <a href=\"@foobar\">FooBar module</a>.
Dieser Text ist nicht einfach zu übersetzen und er taucht sehr häufig auf, deshalb sollten wir uns auf eine einheitliche Übersetzung einigen. In den bisheringen Übersetzungen wurde es recht einheitlich so übersetzt:
Nähere Informationen bezüglich der Konfiguration und Anpassung gibt es auf der Handbuch-Seite zum <a href=\"@foobar\">FooBar-Modul</a>.
Ja, das "bezüglich der Konfiguration und Anpassung" ist dazuerfunden, aber es taucht in den bestehenden Übersetzungen sehr häufig auf. Ich glaube, wir hatten uns damals darauf geeinigt, das so zu schreiben. Das "gibt" ist ein Workaround, um eine Anrede ("finden Sie") zu umgehen.
Ich finde folgenden Vorschlag besser, weil er kürzer ist und genau dasselbe aussagt:
Der Eintrag <a href=\"@foobar\">FooBar module</a> des Online-Benutzerhandbuchs enthält weitere Informationen.
Man beachte, dass der englische Name im Hyperlink nicht übersetzt ist. Das liegt daran, dass Links sowieso (meist?) auf englische Hilfstexte verweisen.
Was haltet Ihr davon? Besser? Schlechter? Gegenvorschläge?
* Es lässt keine Informationen weg und erfindet nichts hinzu.
* Es ist prägnant.
* Der Verweistext ist selbstsprechend.
* Die Konstruktion „Modul ‚Modulname‘“ ist auch für lange Modulnamen geeignet.
Meiner Meinung nach kann man sich viel Arbeit ersparen, wenn man nicht nur die Texte sieht, sondern sich auch vor Augen hält, wer diese Texte überhaupt liest und welche Erfahrungswerte der Leser / die Leserin mitbringt oder mitbringen muss:
Da gibt es zunächst die Administratoren und Konfiguratoren, die die Einrichtung und Konfiguration des Systems vornehmen. Müssen die unbedingt alles auf deutsch lesen? Die wären wahrscheinlich mit den englischen Originaltexten zufrieden (zufriedener?). Schließlich sind die Hilfetexte, in denen dann auf die (englischsprachigen) Menüpunkte referenziert wird, auch in englisch verfasst. Oder macht sich einer die Mühe, diese Texte ebenfalls zu übersetzen. Voraussetzung für diese Aufgabe als Administrator oder Konfigurator ist doch wohl mindestens, dass man sich mit dem System auseinandergesetzt hat, dass man die englische Dokumentation verstanden hat. Und dann soll plötzlich alles auf Deutsch sein?
Dann gibt es die anonymen Benutzer, die irgendwie auf die Seite gelangen und deutsche Texte erwarten. Also sollten alle Texte, die einem anonymen Surfer dargestellt werden, auf deutsch übersetzt sein.
Schlussendlich bewegen wir uns auf der Ebene der Beitragenden (Kontributoren), die Texte einstellen, kotrollieren, den Arbeitsablauf steuern usw. Hier muss man von Fall zu Fall unterscheiden, ob eine Übersetzung notwendig ist oder nicht. Das hängt von der Site und von den Anforderungen, die der Betreiber der Site an seine Benutzer stellt, ab.
Für mich hat bei einer Übersetzung die Anforderung der unter 2 genannte Benutzergruppe die höchste Priorität, die unter 1 genannte Benutzergruppe die geringste. Vorzugsweise verzichtet man für diese Benutzergruppe ganz auf Übersetzungen!
Ich habe mal einen Satz gelesen (war der von Alexander Hass?): Warum sollte man "Views" mit "Ansichten" übersetzen? Nur, weil sich der Schöpfer des Wortes "Views" für das, was aus der Datenbank rausfließt, dieses Wort ausgedacht hat? Hätte er das "Bubbleshow" genannt, weil die Daten seiner Ansicht nach wie Blasen aus der Datenbank hervorsprudeln, würden wir das dann mit "Blasenschau" oder "Blubberblasen" übersetzen? - Wer kennt denn die Menüpunkte "File Edit View.." nicht? Wie wird das übersetzt? "Datei Bearbeiten Ansicht...". Und was macht "View - Ansicht"? Es stellt die Darstellung der Elemente auf dem Bildschirm ein, schaltet Elemente ein und aus und so weiter. Wie wird das in Drupal gemacht? Nicht mit "Views" sondern mit "Themes" und "Blocks".
Meines Erachtens nach können (und sollten) wir auf die Übersetzung von Zeichenketten auf der Administrationsoberfläche vollständig verzichten! Leider wird dabei auch ein Kauderwelsch entstehen, weil Texte sowohl hier als auch dort verwendet werden können. Ich wünschte mir dafür eine Option in Drupal, mit der ich festlegen kann dass z.B. im Pfad "admin" nur noch die Originaltexte und keine Übersetzungen mehr angezeigt werden.
Den Wunsch, das Admin-Backend separat oder überhaupt nicht zu übersetzen, gab es schon oft. Aber bisher ging das nicht wegen der Art, auf die das Übersetzungssystem funktioniert. Du konntest Dir nie sicher sein, ob ein String nicht vielleicht sowohl in der Oberfläche für Gäste, User und Admins verwendet wird. Schau Dir zum Beispiel mal an, wo überall der String "Access denied" verwendet wird.
Erst mit Drupal 7 gibt es erstmalig eine Chance, das über Contexte zu trennen. Wenn Du Lust hast, diskutiere dazu auf groups.drupal.org mit, wo ich eine Diskussion dazu angestoßen habe. Ich könnte mir zum Beispiel gut Kontexte "Administration" und "Watchdog" vorstellen.
Aus meiner Sicht ist 'Submit' mit 'Speichern' öfters nicht korrekt übersetzt (z.B. wenn ich an Panels denke oder an Suchfelder), vielmehr wäre 'Abschicken' in den meisten Fällen treffend.
Der häufig vorkommende String None ist leider schon als 'Kein' bestätigt. Nach meiner Erfahrung ist das nicht gut, da es je nach Zusammenhang kein, keine, keines etc. heißen muss. Daher schlage ich 'Ohne' vor (habe ich auf ld.o. auch vorgeschlagen).
Und noch einmal: hat sich erledigt. Habe wiedergefunden, was ich gesucht habe. Früher oder später muss man ja hier die Übersicht verlieren. Die Beiträge haben sich auch schon über das Seitenende hinausgeschoben, so dass Direktverweise nicht mehr funktionieren. Aber ich habe ja schon genug für eine angemesse Diskussionsplattform geworben... ;-)
Zugegeben kein überschwängliches, aber ich habe mehrmals betont, dass ich so ein System gut fände und habe auch einen Vorschlag gemacht, wie man das toll und ohne Programmiererei verwalten könnte. Eigentlich bräuchten nur jemanden, der so nett ist, diesbezüglich mal ne Mail zu schreiben.
Comments
die richtige Diskussionsplattform
Wie ich schon erwähnte: Wir sollten uns sowas hier zulegen: http://drupalnorge.no/ordliste/engelsk-norsk
Solange das noch nicht ganz
Solange das noch nicht ganz steht, verlinke ich einfach mal hierhin: http://l10n.drupalcenter.de/node/4
Ich habe mir die Wortliste
Ich habe mir die Wortliste angesehen. Wo kann ich meine Vorschläge vorschlagen?
Gibt es Absichten, eine Wortliste wie oben vorgeschlagen aufzubauen?
Woerterbuch
Ich habe das Woerterbuch von drupalcenter und google code zusammengefasst (zwischen dem englischen und deutschen Begriff steht ein Tabulatorzeichen).
Im Prinzip müsste sich diese Datei auch zu TMX bzw. po konvertieren lassen, ein Problem könnte dabei die Zeilen sein, die zwei Übersetzungsvorschläge haben mit Komma getrennt.
access control Zugriffskontrolle
account Benutzerkonto
activated aktiviert
active aktiv
add hinzufügen
administer verwalten
administrator Administrator
anonymous Gast
approved freigegeben
archive Archiv
article Artikel
attachment Anhang
authorized individual berechtigte Person
block Block
blog Weblog
body Haupttext
book outline Inhaltsverzeichnis
browse durchsuchen
button Schaltfläche
capture aufzeichnen
categorize kategorisieren
category Kategorie
chapter Kapitel
check auswerten; sicherstellen
checkboxes Ankreuzfeld
child untergeordnet
clean URLs lesbare URLs
collaborative gemeinschaftlich
configuration Konfiguration
content Inhalt
content types Inhaltstypen
create erstellen
created erstellt
cron Cron
customization Anpassung
date Datum
debugging Auffinden von Fehlern
default Standard-
delete löschen
deleted gelöscht
display mode Ansicht
displayed angezeigt
drag and drop Drap-and-Drop
e-mail E-Mail
edit bearbeiten
event Ereignis
expanded view vollständige Ansicht
feed Newsfeed
filter (n.) Filter
filter (v.) filtern
form Formular
forum Forum
forums Foren
fully-qualified vollständig
handbook Handbuch
handbook page Handbuchseite
help text Hilfetext
home Startseite
hyperlink Verweis
information Informationen
input format Eingabeformat
interval Intervall
item Element
last neueste
legacy Rückwärtskompatibilität
link Link, verlinken
location Adresse
log Protokoll
log in anmelden
log message Protokollnachricht
log out abmelden
main page Startseite
menu item Menüpunkt
message Nachricht
message type Nachrichtentyp
moderate moderieren
moderator Moderator
module Modul
move verschieben
never nie
news feed Newsfeed
next nächstes
node Beitrag
notice Mitteilung
on a regular basis regelmäßig
options Optionen
organize gliedern
orphan verwaist
outline Gliederung
overview Übersicht
page Seite
parent übergeordnet
parse error Verarbeitungsfehler
permission Berechtigung
poll Umfrage
post Beitrag
post (n.) Beitrag
post (v.) speichern/beitragen
post type Inhaltstyp
previous vorheriges
printer-friendly druckerfreundlich
promote to front page Auf der Startseite anzeigen
public öffentlich
publication Veröffentlichung
publish veröffentlichen
queue Warteschlange
RDF feed RDF-Newsfeed
register registrieren
reply (n.) Antwort
reply (v.) antworten
result Ergebnis
revision Version
role Rolle
RSS feed RSS-Newsfeed
search output Suchergebnis
section Abschnitt
session Sitzung
setting Einstellung
severity Schweregrad
sibling nebengeordnet
site Website
story Artikel
string Zeichenkette
submission queue Beitragswarteschlange
submit speichern
Suggestion Vorschlag
syndicate abgleichen
system System-
system event Systemereignis
tab Reiter
taxonomy Taxonomie
teaser Anrisstext
themable anpassbar, Design anpassbar
theme Theme
threaded view Themenansicht
threshold Grenzwert
throttle Lastreduzierung
title Titel
topic Thema
trackback Trackback
unpublished unveröffentlicht
update aktualisieren
URL URL
user Benutzer
user profile Benutzerprofil
view ansehen; betrachten
visitor Besucher
vital unerlässlich
waiting wartend
warning Warnung
watchdog Wächter
weight Reihenfolge
who's online Momentan online
workflow Arbeitsablauf
Blog
In paar Vorschläge:
Einigen wir uns zunächst auf die Mittel?
Können wir uns zunächst auf die Mittel einigen, bevor die Begriffsdiskussion sich unübersichtlich über mehrere Orte und unzählbare Kommentare verteilt? Und auch das wiederholte, erneute Einstellen der Wortliste halte ich für wenig sinnvoll. Wer wird all die Änderungen nachverfolgen?
Ich möchte eine Wortliste nach norwegischem Vorbild vorschlagen: http://drupalnorge.no/ordliste/engelsk-norsk
Ich denke, dabei an diese Punkte, ohne ins Detail zu gehen:
Eine Drupal-Seite mit eigenen Inhaltstypen und Feldern würden es ermöglichen, Übersetzungen und Diskussionen einander zuzuordnen, Übersetzungen zu markieren ("zur Diskussion", "offizieller Eintrag",...) usw. Das würde auch helfen, die Gedanken zu dokumentieren, damit Wiederholungen vermieden werden können und neue Mitglieder sehen, was passiert ist.
Wortliste
Ja, norwegische Wortliste gut und schön und natürlich kann man das mehrmals vorschlagen. Aber irgendwer musses auch tun.
Bis dahin find ich's nicht so schlimm, das in nem Thread zu diskutieren und ab und zu das Posting mit der Liste zu editieren. Besser als wenn jemand 3 Tage lang eine Wortlisten-Site hackt und die dann niemand benutzt. Es scheinen sowieso nur 5 Leute Übersetzungen im großen Stil beizutragen.
Na dann, "gut und schön" muss
Na dann, "gut und schön" muss ich nicht haben. Es wird ganz sicher niemand tun, wenn niemand sagt, dass er es nutzen würde. Oft genug darauf hingewiesen habe ich, das ist war. Allerdings, es gibt keinen Beitrag zur Sache... Insofern sehe ich kein "bis dahin". Wenn die Mehrheit den Vorteil nicht selbstständig erkennt, werde ich sie davon auch nicht überzeugen. Natürlich funktioniert es in einer langen Diskussion, verstreut über viele Orte und vermengt zu vielen einzelnen Übersetzungen. Es ist, als wolle man die Zugspitze mit Schippe und Eimer abtragen. Anfangs ist es noch übersichtlich und es geht "schnell", die eigentliche Arbeit wird ohne schweres Gerät nicht zu bewältigen sein: Wer behält den Überblick? Was ist mit denen, die sich später oder nach uns engagieren wollen? Woran können wir die Verlässlichkeit festmachen, die dieses Projekt braucht? Ich habe kein Interesse an Übersetzungen, die durch Bauchgefühl und Wechselhaftigkeit der "Entscheider" (aka Übersetzter) festgeschrieben werden. Diese präsentieren sich hier zuweilen selbst mit schrecklichem Deutsch, oder halten sich mit Debatten über "Wer hat die meisten Einzelübersetzungen" auf. Die Qualität verkommt zu oft zur Randerscheinung. Ein Beispiel, welches hier sicher jedem schon einmal untergekommen ist: Engl. "to control" ist im Deutschen nur sehr, sehr selten "kontrollieren". "Access control" ist sicher keine dieser Ausnahmen, und entsprechend nicht mit "Zugriffskontrolle" zu übersetzen, sondern etwa mit "Zugriffssteuerung". "Kontrollieren" hat etwas mit Aufsicht, Überprüfung, Probe oder (Selbst-) Beherrschung zu tun. Weitere beliebte Schnitzer sind Verklausulierungen (oft im Zusammenhang mit engl. "of" und dt. "von"), unnütze Worterweiterungen ((Be-) Nutzer), feinstes Denglisch (inklusive Deppenleerzeichen und sächsischem Genitiv) und Rechtschreibfehler (besonders falsches "ss" anstatt "ß"). Derlei fehler- oder laienhafte Übersetzungen finden sich zu häufig, was zunächst auf das Gesamtpaket "deutsche Übersetzung" und dann auch auf Drupal als solches zurückfällt. Schließlich ist auch die deutsche Sprache betroffen, wenn diese Fehler in die Welt getragen werden. Liebe Eltern, mit dieser Sprache wachsen eure Kinder auf, und verlieren dabei jede Logik, die dem Deutschen innewohnt: nutzbringend, nützlich, nutzen, Nutzer -- nicht etwa "User"; und schlimm ist's, wenn nicht bekannt ist, dass im "Chicken-Döner" Hähnchen ist. Und, liebe Kinder, wie steht's um die Deutschnoten? Gibt es für euch noch ein Englisch außerhalb der Spiele- und Computerwelt? -- Kurz, so etwas macht die deutsche Übersetzung unbrauchbar, was für mich dazu geführt hat, dass ich seit Drupal 6 eigene Übersetzungen pflege. Ich kenne den Aufwand, auch wenn es sich auf die Oberfläche für Gäste und reguläre Nutzer beschränkt. Dieser Aufwand und die Aktivität der deutschen Übersetzergemeinschaft (Umzug auf l.d.o usw.) waren für mich Anlass, mich für eine Drupal-7-Übersetzung einzubringen. Mir ist auch bewusst, dass eine gemeinschaftliche Übersetzung unwahrscheinlich jeden 100%ig zufriedenstellen wird, und dass die Sprache für manche Projekte bedeutsamer ist, als für andere. Das aktuelle Maß ist jedoch, wie gesagt, unbrauchbar. Das mitzuändern bin ich gern bereit. Nicht jedoch, wenn ich mich regelmäßig erst durch zig Orte wühlen muss, um zu gucken, welches Thema besprochen wird, und wie sein aktueller Stand ist. Ich denke auch, das erstickt früher oder später jedes Engagement. Diese Zeit könnte den Übersetzungen zugute kommen. Der aktuell oben zu lesende Satz spricht Bände: "OK, habe nach 3 Zeilen schon keine Lust mehr so das Wörterbuch zu pflegen. Ein CT sowie View-Ausgabe muss her." In diesem Sinne, viel Erfolg! -- Gemeinsam, oder auf getrenntem Weg.
Deutsche Übersetzung ist eine Küche
Es wird ganz sicher niemand tun, wenn niemand sagt, dass er es nutzen würde.
Natürlich würde ich so ein System gerne nutzen. Ist ja wohl klar.
Natürlich funktioniert es in einer langen Diskussion, verstreut über viele Orte und vermengt zu vielen einzelnen Übersetzungen. Es ist, als wolle man die Zugspitze mit Schippe und Eimer abtragen.
Unzählige FAQs sind über Jahrzehnte genau so aus Usenet- oder Forenthreads entstanden und das klappt ganz gut: Ein Maintainer stöbert ab und zu durch den Thread und aktualisiert das offizielle FAQ, damit die anderen alles bequem in einem Dokument haben.
Heutzutage kann man das in Wiki-Form noch deutlich effizienter machen, vor allem, wenn die User verantwortungsvoll ändern, wovon man bei uns ausgehen kann.
Was ist mit denen, die sich später oder nach uns engagieren wollen?
Ich verstehe die Frage nicht. Ob ein Anfänger eine Wortliste von einem eigenen System herunterlädt oder aus einem Wiki ist doch egal.
Woran können wir die Verlässlichkeit festmachen, die dieses Projekt braucht?
Das läuft wie bei allen OpenSource-Projekten: Entweder vollständig ungeordnet, d.h. jeder Kontributor macht "best effort" oder mit einem Workflow über einen Maintainer, den es ja bereits gibt.
Ich habe kein Interesse an Übersetzungen, die durch Bauchgefühl und Wechselhaftigkeit der "Entscheider" (aka Übersetzter) festgeschrieben werden. Diese präsentieren sich hier zuweilen selbst mit schrecklichem Deutsch
Drupal-Prinzip "scratch your own itch". Ich fand auch viele Übersetzung grauenhaft und habe mich sehr darüber geärgert, dass Strings in wichtigen Modulen in D6 nicht oder falsch übersetzt waren. Das ist der Grund, warum ich Übersetzungen beigetragen habe und jetzt wieder beitrage. Wenn Du Dich einbringst und gute Übersetzungen machst, kannst Du auch das Recht bekommen, schlechte Übersetzungen zu verwerfen oder den besten Übersetzungsvorschlag als offizielle Übersetzung zu akzeptieren. Einfach machen!
was für mich dazu geführt hat, dass ich seit Drupal 6 eigene Übersetzungen pflege.
Wo sind die? Wo kann man die begutachten oder herunterladen? Wo ist diese Arbeit in die Community zurückgeflossen?
Nicht jedoch, wenn ich mich regelmäßig erst durch zig Orte wühlen muss, um zu gucken, welches Thema besprochen wird, und wie sein aktueller Stand ist.
Ich verstehe Dein Problem nicht. Es ist doch völlig egal, in welcher Form eine aktuelle Wortliste vorliegt, Hauptsache sie ist verbindlich und aktuell.
Ich denke auch, das erstickt früher oder später jedes Engagement. Diese Zeit könnte den Übersetzungen zugute kommen.
Umgekehrt wird ein Schuh draus: Statt in vielen Stunden in System zu bauen und zu pflegen, in dem dasselbe drinsteht wie in einer z.B. von Thomas aktualisierten Seite, sollten Leute lieber Übersetzungen vorschlagen oder "approven".
In diesem Sinne, viel Erfolg! -- Gemeinsam, oder auf getrenntem Weg.
Nochmal: Das hier ist kein Restaurant, wo man anderen aufträgt, was man gerne hätte, es ist noch nicht einmal ein Selbstbedienungsrestaurant, es ist eine Küche. Jeder ist froh, wenn Du kochst. Jeder ist froh, wenn Du einen neuen Herd anschaffst. Jeder ist froh, wenn Du Norweger nach einem Herd fragst. Aber sich hinsetzen und über das Essen (oder gar den Verfall der deutschen Sprache) zu lamentieren und/oder beleidigt abzuziehen ist kein adäquates Verhalten. Nichts für Ungut, aber das musste mal gesagt werden.
Wenn Du Dich mit Drupal auskennst, wirst Du so ein System selber erstellen können. Oder Du kannst die Norweger fragen, ob sie es Dir geben. Oder Du kannst jemanden bitten/beauftragen, so ein System zu entwickeln. Ich hätte Interesse, aber schätze den Zugewinn gegenüber der manuell gepflegten Liste nicht besonders groß ein.
Ich sehe das ähnlich wie
Ich sehe das ähnlich wie Linulo. Das anhand einer von jedem editierbaren Wiki-Seite zu handhaben, hat sich ja auch schon in den anderen Grupppen etabliert. So schlimm finde ich das gar nicht.
Es scheinen sowieso nur 5 Leute Übersetzungen im großen Stil bei
Es scheinen sowieso nur 5 Leute Übersetzungen im großen Stil beizutragen.
Als der Übersetzungsserver noch bei Drupal war (na eigentlich kkaefer.com), habe ich fleißig an den Übersetzungen mitgearbeitet und auch approved. Nachdem Konstantin aber meinte, der Drupal-Übersetzungsserver sei nicht gut genug, und ihn einfach zur Krake Google verlegt hatte, hatte ich keine Lust mehr, mitzuarbeiten.
Wenn sich die aktuelle Kindergartendiskussion a la "meine Schüppe ist schöner als deine Schüppe" gelegt hat, werde ich wieder mitarbeiten. Die Werkzeuge, die einem zur Verfügung stehen, sollten dann auch genutzt werden.
Ich werde also abwarten, bis die Arbeitsabläufe, zu nutzende Ressourcen usw. festgelegt sind und dann werde ich wieder einsteigen. Bis dahin ist mir meine Zeit zu kostbar, um mich in diese Diskussion zu verstricken.
Also, überlegt mal, warum nur 5 Leute Übersetzungen in großem Stil beitragen!
Ging mir ähnlich
Ja, so ähnlich ging's mir auch, druppi. Gabor war sein Server noch nicht gut genug und er wurde nicht auf d.o installiert. Konstantin hat dann einfach einen aufgesetzt und ich habe da auch mitübersetzt und approved. Meine Einstellung gegenüber Google ist etwas differenzierter. Ich habe überhaupt kein Problem damit, eine Übersetzung auf Google Code zu verwalten wenn sie sowieso OpenSource ist und bei allem berechtigten Google-Gebashe darf man auch nicht vergessen, dass Google mit vielen Summer of Code Projekten für Drupal kräftig mithilft, Drupal besser zu machen.
Was mich am meisten geärgert hat, war, dass es für D6 monatelang keine po-Datei gab, die man in Drupal importieren konnte, nur die Version mit 20 einzelnen po-Dateien (pro Modul).
Auch heute noch hat der Localization Server Unzulänglichkeiten, die seinen Nutzen einschränken, aber die Import- und Exportfunktionen sind inzwischen gut, was das ein wenig ausgleicht. Ideal wäre, wenn die Bedienung des Localization Servers so beschleunigt werden könnte, dass er sich genauso flüssig wie ein offline-Editor benutzen lässt. Insbesondere die zum Approven nötigen Arbeitsabläufe sind noch inakzeptabel umständlich.
Egal. Drupal ist toll und ich möchte, dass D7 bei Release einen hochwertig und vollständig übersetzten Core hat und die wichtigsten Module auch und ich werde nach Kräften mithelfen, dass das erreicht wird. Die beste Zeit zu helfen ist genau jetzt, nach String Freeze und bevor alle kritischen Bugs gefixt sind. Daher wäre es kontraproduktiv, ausgerechnet jetzt abzuwarten.
Warum nur 5 Leute intensiv mitarbeiten ist klar: Die meisten Leute nehmen gerne aber sind nicht bereit, selber etwas zu geben. Die Infrastruktur mag nicht perfekt sein, aber trotzdem kann jeder, der es will, mitarbeiten, und auch sinnvoll mitarbeiten. Wenn mal eine von 30 Übersetzungen nicht perfekt ist weil vielleicht eine Wörterliste nicht up-to-date ist, ist das kein Beinbruch, dann haben wir halt ab und zu nicht ganz perfekte Übersetzungen. Ein Grund, nicht zu helfen, ist das nicht, nur eine Ausrede.
Blog übernommen
Wächter finde ich auch unpassend, Systemprotokoll finde ich recht zutreffend.
Core und Contrib - brauchen wir eine Lösung.
Core, Contrib
In den Strings taucht es immer in Verbindung mit "modules" auf.
Vorschläge für "core modules": Grundmodule, Drupal-Kern, Drupal-Kernfunktionen, Kernfunktionen.
Vorschläge für "contributed modules": Zusatzmodule, zusätzliche Module.
Wörterliste als localize-Projekt
Wir sind ja nicht die einzigen, die eine Wörterliste pflegen wollen und der Localization Server bietet doch alle Funktionen, die wir brauchen, um eine solche Liste kollaborativ zu pflegen. Wäre es da nicht naheliegend, aus der Wörterliste einfach ein eigenes Projekt für localize.drupal.org zu machen? Wir hätten mit einem Schlag eine schöne Oberfläche, bereits bestehende Accounts, Import/Export, etc.
Beachte: Das Projekt "Dictionary" hier im Localization-Server ist keine Wörterliste sondern ein gleichnamiges Drupal-Modul.
Linulos Vorschlag klingt gut.
Linulos Vorschlag klingt gut.
Die Idee ist sehr gut
man könnte das sogar noch ausbauen, wenn man bei der Übersetzung eines Textes die relevanten Wörter oder Wortsequenzen aus dem Wörterbuch eingeblendet bekommt (nicht als Satz, sondern als Wortliste). Das würde dann mit Sicherheit dazu führen, dass die Übersetzung vereinheitlicht wird (weil man nicht mehr "nachschauen" muss).
Da ich kein Modulentwickler bin, kann ich auch nur mit Ideen aushelfen :(
Password?
Nanu? Wo ist denn der Wörterbuch-Eintrag für "password" geblieben? Ich bin mir sicher, dass wir in DICTIONARY.TXT dafür "Kennwort" stehen hatten. Jetzt sehe ich aber etliche Suggestions und sogar Übersetzungen mit "Passwort". Ich finde "Kennwort" besser, aber inzwischen kennt der Duden "Passwort" und Wikipedia leitet sogar von "Kennwort" auf "Passwort" um. Ich gehe davon aus, dass es an der Zeit ist, auf "Passwort" umzuschwenken.
"Fetcher" (in Verbindung mit RSS/OPML)
Vorschlag: Abrufer
Fetchers download data from an external source. Choose a fetcher suitable for the external source you would like to download from.
So einfach ist die deutsche Sprache aber nicht!
Was im Englischen mit einem Wort beschrieben werden kann, muss im Deutschen häufig durch kompliziertere Umschreibungen ausgedrückt werden. "Fetcher" so zu übersetzen halte ich für extrem schlecht (aber einfach).
M.E. müsste man es mit "Programm zum..." oder "Funktion[alität] zum..." übersetzen. Ich habe hier bewusst nicht "...Abrufen" verwendet weil:
"Programm zum Herunterladen von Daten aus einer externen Quelle. Ein geeignetes Programm [oder eine geeignete Funktion, je nach Kontext] für die externe Quelle wählen, aus der die Daten geladen werden sollen"
enthält nirgendwo "abrufen"!
Ich habe neue Fachbegriffe eingeführt
Ich finde, dass die deutsche Sprache in diesem Fall doch so einfach ist.
Ich hole ein wenig aus: Im Aggregator-Modul wird erklärt, was mit RSS-Feeds gemacht werden kann. Sie werden von irgendwoher geholt (z.B. von einer URL), lexikalisch analysiert (z.B. gemäß RSS-Standard) und verarbeitet (z.B. abgespeichert). Für die lexikalische Analyse existiert im Englischen und im Deutschen ein Fachbegriff (to parse / parsen), für die beiden anderen Schritte aber nicht. Die Autoren des Aggregator-Moduls haben neue Fachbegriffe eingeführt, die es mit dieser speziellen Bedeutung für Newsfeeds vorher nicht gab: "Fetcher" für die Komponente, die den Feed holt und "Processor" für eine Komponente, die den Feed verarbeitet.
Wenn ein gebürtig Englischsprechender das Wort "Fetcher" liest, wird er wissen, dass etwas gemeint ist, das irgendetwas heranschafft, herholt. Dasselbe gilt für das deutsche "Abrufer".
Entschuldige, wenn ich erst eine Frage stelle und dann besserwisserisch korrigiere wenn Du einen Vorschlag machst. Die Überzeugung ist erst langsam gereift, dass die "Abrufer"-Übersetzung in meinen Augen die beste ist.
P.S.: "abrufen" trifft es besser als "holen", weil das Holen periodisch wiederholt wird. Im Englischen gibt es AFAIK kein Wort, das das so ausdrückt wie das deutsche "Abrufen".
For more information, see the online handbook entry...
For more information, see the online handbook entry for <a href=\"@foobar\">FooBar module</a>.
Dieser Text ist nicht einfach zu übersetzen und er taucht sehr häufig auf, deshalb sollten wir uns auf eine einheitliche Übersetzung einigen. In den bisheringen Übersetzungen wurde es recht einheitlich so übersetzt:
Nähere Informationen bezüglich der Konfiguration und Anpassung gibt es auf der Handbuch-Seite zum <a href=\"@foobar\">FooBar-Modul</a>.
Ja, das "bezüglich der Konfiguration und Anpassung" ist dazuerfunden, aber es taucht in den bestehenden Übersetzungen sehr häufig auf. Ich glaube, wir hatten uns damals darauf geeinigt, das so zu schreiben. Das "gibt" ist ein Workaround, um eine Anrede ("finden Sie") zu umgehen.
Ich finde folgenden Vorschlag besser, weil er kürzer ist und genau dasselbe aussagt:
Der Eintrag <a href=\"@foobar\">FooBar module</a> des Online-Benutzerhandbuchs enthält weitere Informationen.
Man beachte, dass der englische Name im Hyperlink nicht übersetzt ist. Das liegt daran, dass Links sowieso (meist?) auf englische Hilfstexte verweisen.
Was haltet Ihr davon? Besser? Schlechter? Gegenvorschläge?
Vorschlag
Das Handbuch enthält weitere Informationen zum Modul „Modulname“.
* Es lässt keine Informationen weg und erfindet nichts hinzu.
* Es ist prägnant.
* Der Verweistext ist selbstsprechend.
* Die Konstruktion „Modul ‚Modulname‘“ ist auch für lange Modulnamen geeignet.
Gefällt mir gut
Gefällt mir gut
Warum überhaupt alles übersetzen?
Meiner Meinung nach kann man sich viel Arbeit ersparen, wenn man nicht nur die Texte sieht, sondern sich auch vor Augen hält, wer diese Texte überhaupt liest und welche Erfahrungswerte der Leser / die Leserin mitbringt oder mitbringen muss:
Für mich hat bei einer Übersetzung die Anforderung der unter 2 genannte Benutzergruppe die höchste Priorität, die unter 1 genannte Benutzergruppe die geringste. Vorzugsweise verzichtet man für diese Benutzergruppe ganz auf Übersetzungen!
Ich habe mal einen Satz gelesen (war der von Alexander Hass?): Warum sollte man "Views" mit "Ansichten" übersetzen? Nur, weil sich der Schöpfer des Wortes "Views" für das, was aus der Datenbank rausfließt, dieses Wort ausgedacht hat? Hätte er das "Bubbleshow" genannt, weil die Daten seiner Ansicht nach wie Blasen aus der Datenbank hervorsprudeln, würden wir das dann mit "Blasenschau" oder "Blubberblasen" übersetzen? - Wer kennt denn die Menüpunkte "File Edit View.." nicht? Wie wird das übersetzt? "Datei Bearbeiten Ansicht...". Und was macht "View - Ansicht"? Es stellt die Darstellung der Elemente auf dem Bildschirm ein, schaltet Elemente ein und aus und so weiter. Wie wird das in Drupal gemacht? Nicht mit "Views" sondern mit "Themes" und "Blocks".
Meines Erachtens nach können (und sollten) wir auf die Übersetzung von Zeichenketten auf der Administrationsoberfläche vollständig verzichten! Leider wird dabei auch ein Kauderwelsch entstehen, weil Texte sowohl hier als auch dort verwendet werden können. Ich wünschte mir dafür eine Option in Drupal, mit der ich festlegen kann dass z.B. im Pfad "admin" nur noch die Originaltexte und keine Übersetzungen mehr angezeigt werden.
Vielleicht erfasse ich dazu mal ein Issue
Issue ist drin!
http://drupal.org/node/744656
Das ist nicht so einfach
Den Wunsch, das Admin-Backend separat oder überhaupt nicht zu übersetzen, gab es schon oft. Aber bisher ging das nicht wegen der Art, auf die das Übersetzungssystem funktioniert. Du konntest Dir nie sicher sein, ob ein String nicht vielleicht sowohl in der Oberfläche für Gäste, User und Admins verwendet wird. Schau Dir zum Beispiel mal an, wo überall der String "Access denied" verwendet wird.
Erst mit Drupal 7 gibt es erstmalig eine Chance, das über Contexte zu trennen. Wenn Du Lust hast, diskutiere dazu auf groups.drupal.org mit, wo ich eine Diskussion dazu angestoßen habe. Ich könnte mir zum Beispiel gut Kontexte "Administration" und "Watchdog" vorstellen.
Submit
Aus meiner Sicht ist 'Submit' mit 'Speichern' öfters nicht korrekt übersetzt (z.B. wenn ich an Panels denke oder an Suchfelder), vielmehr wäre 'Abschicken' in den meisten Fällen treffend.
None = Ohne !?
Der häufig vorkommende String None ist leider schon als 'Kein' bestätigt. Nach meiner Erfahrung ist das nicht gut, da es je nach Zusammenhang kein, keine, keines etc. heißen muss. Daher schlage ich 'Ohne' vor (habe ich auf ld.o. auch vorgeschlagen).
Missverständnis?
gelöscht!
Hat sich erledigt.
Und noch einmal: hat sich erledigt. Habe wiedergefunden, was ich gesucht habe. Früher oder später muss man ja hier die Übersicht verlieren. Die Beiträge haben sich auch schon über das Seitenende hinausgeschoben, so dass Direktverweise nicht mehr funktionieren. Aber ich habe ja schon genug für eine angemesse Diskussionsplattform geworben... ;-)
Angemesse Diskussionsplattform
Schade, dass es bei der Werbung geblieben ist.
Schade, dass es bei "kein Interesse" geblieben ist.
Schade, dass es bei "kein Interesse" geblieben ist.
Von mir gab's Interesse
Zugegeben kein überschwängliches, aber ich habe mehrmals betont, dass ich so ein System gut fände und habe auch einen Vorschlag gemacht, wie man das toll und ohne Programmiererei verwalten könnte. Eigentlich bräuchten nur jemanden, der so nett ist, diesbezüglich mal ne Mail zu schreiben.