Pierre
Ich glaube, wenn da mehrere Leerzeichen sind, muß man das der Länge der Übersetzung anpassen, so daß der String insgesamt gleich lang ist. Also z.B.:
Englisch :
Deutsch :
[gelöscht]
Manchmal ist der Übersetzungstext länger als das Original.
Weißt du, was man da machen muss?
Pierre
gute Frage; evtl. muß man das abkürzen. Vielleicht frage ich mal nach, ob die Zeichenzahl fest vorgegeben ist.
Nachtrag: jetzt wollen sie es aber wissen; mußte gerade auch noch die Übersetzung vom AUR an die neue Version anpassen, die ebenfals bald erscheinen soll.
Nachtrag 2: Bei der Sache mit den Leerzeichen müssen wir nur darauf achten, daß alle "Labels", die zusammen auftreten gleich lang sind.
Nachtrag 3: Man muß darauf achten, daß man z.B. in Kbabel eine Schrift mit fester Breite wählt; dann sieht man, ob Original und Übersetzung die gleiche Länge haben. 😉
matthias
Über zusammengesetzte Wörter (auch noch aus zwei Sprachen zusammengesetzte Dinge wie "Cache-Verzeichnis" oder "Download-xyz") werden deutsche User immer stoplern - auch wenn eine Vielzahl der Wörter längst eingedeutscht sind. Denn Bindestrich zur Trennung finde ich schon sehr wichtig. Auch "Repository" ist eine harte Nuss - ich könnte mit dem einfachen "Repo" leben, aber wäre es für alle verständlich? Korrekt ist schon "Repositorium", und als eingedeutschter Plural "Repositorien" - das latinisierte "Repositoria" wäre doch sehr gesteltzt und klingt nicht Nutzer-freundlich. Also ist die letzte Fassung immer ein harter, aber hoffentlich kein fauler Kompromiss.
Pierre: Wenn da kurzfristig an der AUR-Seite auch noch was geändert werden soll, musst Du es bitte genauer erklären.
Ansonsten finde ich es einfach ziemlich stark, wie viele Leute sich jetzt hier an der Diskussion beteiligen!
dafab
Ich bin gerade an dem englischen Wort "target" dran. Teilweise wir es mit Paket übersetzt, aber auch mit dem (wörtlicheren) Ziel.
Beispiel:
#: lib/libalpm/conflict.c:123 lib/libalpm/conflict.c:136
#, c-format
#, fuzzy
targs vs targs: found %s as a conflict for %s
---
Paket gegen Liste: %s befindet sich im Konflikt mit %s
Hier wird targs einmal als "Paket" (müßte das nicht eigentlich Pakete heißen) und einmal als Liste übersetzt. Da ich mir nicht ganz sicher bin was damit überhaupt gemeint ist fällt mir auch keine bessere Übersetzung ein 🙁
Auch Cache wird nicht einheitlich übersetzt. Eigentlich könnte man Cache auch im Deutschen stehen lassen, teilweise haben wir es mit Puffer übersetzt. Geht beides, die Frage ist halt was schöner ist.
MacWolf
ich find Paketpuffer schön 🙂 wobei Cache auch okay ist...ist ja mitlerweile eingedeutscht 😉
Pierre
OK, nun beginnt der Endspurt. Mit den Leerzeichen muß man wirklich mal schauen. Ich habe das mal kompiliert und folgende Ausgabe ist z.B. weniger schön:
[root@athlon64 pacman-rc]# pacman3 -Qi pacman-rc
Name : pacman-rc
Version : 2007.02.12-1
URL : http://archlinux.org
Lizenz : GPL
Gruppen : Nichts
Stellt bereit : Nichts
Hängt ab von : libarchive libdownload
Entfernt : Nichts
Benötigt von : Nichts
Konflikt mit : Nichts
Installationsgröße : 1905 K
Packer : Pierre Schmitz <pierre@archlinux.de>
Architektur : x86_64
Erstellt am : Tue Feb 13 12:12:13 2007 UTC
Bauart : Unbekannt
Installiert am : Tue Feb 13 12:12:30 2007 UTC
Installationsgrund : Ausdrücklich installiert
Installations-Skript : Nein
Beschreibung : pacman 3: Testing Build Release Candidate
Nachtrag:
OK, ich habe einfach die linke "Spalte verbreitert:
[root@athlon64 pacman-rc]# pacman3 -Qi pacman-rc
Name : pacman-rc
Version : 2007.02.12-1
URL : http://archlinux.org
Lizenz : GPL
Gruppen : Nichts
Stellt bereit : Nichts
Hängt ab von : libarchive libdownload
Entfernt : Nichts
Benötigt von : Nichts
Konflikt mit : Nichts
Installationsgröße : 1905 K
Packer : Pierre Schmitz <pierre@archlinux.de>
Architektur : x86_64
Erstellt am : Tue Feb 13 12:32:08 2007 UTC
Bauart : Unbekannt
Installiert am : Tue Feb 13 12:32:15 2007 UTC
Installationsgrund : Ausdrücklich installiert
Installations-Skript : Nein
Beschreibung : pacman 3: Testing Build Release Candidate
Pierre
Übrigens: was target bedeutet ist wirklich nicht immer klar; ich habe es in lib nun durchgängig mit Ziel übersetzt; Paket machte hier nicht immer Sinn. Diese Ausgaben wird man wohl eh nur im Debug-Modus sehen. Genaueres merken wir wohl erst, wenn pacman3 im Einsatz ist.
matthias
"Nichts" ist natürlich eher schlecht. An einigen Stellen würde "keine" besser passen - aber eben nicht an allen. Mir fällt aber nix besseres ein, und es wäre sehr aufwändig, die Fragen an die Antworten anzupassen. "Nicht wirklich gut, aber auch nicht besser zu machen" ist wohl das Dilemma aller Übersetzer.
Pierre
Ja, hier sind wir aber auch nicht besser/schlechter als das Original. Besser wäre es wohl die gesamte Zeile auszublenden, wenn z.B. eh keine Abhängigkeiten vorhanden sind.
Übrigens: ich werde die Übersetzung nun einschicken. Es wird dann sehr bald einen öffentlichen Test geben.
matthias
Rev 35 - so konsistent war das noch nicht (etwa noch viele "Caches"). Hier ist noch ein Klopfer, den ich erstmal nicht verbessert habe:
#: lib/libalpm/conflict.c:201
#, c-format
msgid "target '%s' is also in target list, using NEW conflicts"
msgstr "Ziel '%s' ist auch in der Ziel-Liste, benutze neue Konflikte"
NEIN - wir wollen natürlich keine neuen Konflikte benutzen. Es ist eine Datei namens NEW, die Konflikte verursacht. Ich weiss jetzt nicht, ob das eine interne Arbeitsdatei ist, oder ob NEW lediglich für die neue Version eines Paketes steht.
Aber das sollte doch bitte dringend noch geändert werden. Frohe Ostern an alle Archer.
Pierre
Du kannst es gerne ändern. 😉 Allerding ist mir der Englische Text auch nicht so ganz klar. Wie kommst Du darauf, daß es eine Datei namens NEW gibt.
Ich hoffe eh, daß mit eine der nächsten Versionen alle Meldungen aus libalpm verschwinden. Dort haben wir eine ganze Menge unverständlicher Debug-Nachrichten, die ein Benutzer eh nicht zu Gesicht bekommt.
matthias
Gut, vielleicht ist es auch ein Befehl, ein Argument, ein Feld - was weiss ich. Ich gehe jedenfalls davon aus, dass die engl. Fassung in jedem Fall richtig ist. Und dass NEW hier großgeschrieben wird, muss auf eine feste Konvention zurückgehen - wie bei README. Die einzige anderen Fälle im Text sind DESC, FILES, DEPENDS und NULL. Wenn das jemand erklären kann, ändere ich es gern.
Pierre
Am besten mal bei pacman-dev nachfragen. Ich hätte jetzt gedacht, daß NEW durch die Großschreibung einfach betont werden sollte.
Pierre
Schön zu sehen, daß sich in diesem Fall die Entwickler auch nicht wirklich sicher sind. 😉
@boabdil: Wenn Du soweit bist, aknnst Du die neue Version auch als patch an die pacman-dev-Liste schicken. Die letzte Version, die ich dort hingeschickt habe war 34. Einen Patch mit allen Änderungn sollte man also wie folgt erstellen können: (im Wurzelverzeichnis des Repository)
svn diff -r34 > pacman-de.patch
matthias
Ich schluck das immer noch nicht, dass NEW einfach betont werden sollte - es macht keinen Sinn "neue Konflikte" zu benutzen. Aber da niemand die Lösung weiss, müssen wir es wohl so lassen. (Wie Du schon sagst: Wird eh' niemand jemals sehen.)
Ich würde es mir gern noch mal am Wochende in Ruhe ansehen (auch das mit den DESC Files und so). Was Du oben vorgeschlagen hast, werde ich ausprobieren. Vielleicht ist es aber auch zuviel der Ehre für mich - wenn das nicht klappt, greife ich ggf. auf die bewährte Hasenfuss-Taktik zurück - R36, und Pierre bitten, das zu posten <thumbsup>
Pierre
Sollte aber gehen. Es muß übrigens immer -r34 lauten; egal wieviel noch eingecheckt wird. 😉