Details
- Reviewers
kde-i18n-de felf
Diff Detail
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Da stellt sich mir wieder die allgemeine Frage, wie weit wir in der Entwicklungswelt etablierte Begriffe übersetzen, die selbst git nicht übersetzt, z.B. Tag oder Branch.
| kommit.po | ||
|---|---|---|
| 70 | git --help sagt herunterladen | |
| 125 | Git verwendet Historie | |
| 170 | Branche diffen (oder vergleichen) | |
| 375 | das Remote? | |
| 447 | Stash %1 anwenden | |
| 465 | Stash %1 verwerfen | |
| 595 | Oben hast du noch Auschecken verwendet (was ich auch besser finde; Auslesen habe ich in dem Kontext noch nie gehört) | |
| 601 | zum ausgewählten | |
| 649 | Repositorys | |
| 667 | Branche diffen (oder vergleichen) | |
| 691 | %1 ist der Pfad. Vielleicht Satzfolge anpassen? | |
| 829 | Alle unbeobachteten | |
| 1082 | Commit Schau mal auf die Namen der Code-Dateien: History- und Suchdialog. Hier geht es um das Finden oder Anzeigen von Commits, nicht das Erstellen derselben. | |
| 1315 | wird? | |
| 2306 | Bindestrich? | |
| 2504 | Ausgewählten | |
| 2522 | Ausgewählten | |
| 2536 | Da es in tagswidget.ui steht, wird es um ein Tag gehen, keinen Zweig | |
| 2542 | Bereits auf dem neusten Stand. | |
| 2609 | Graph | |
| 2616 | Hm... hier müsste es sich um die Tag Message handeln | |
Mir hat es als Anfänger schon geholfen, dass ich ein Programm hatte, das auch deutsche Begriffe verwendet. So bin ich nicht ganz verloren dagestanden.
Ich habe mir einige andere open source Programme für git angesehen um mich zusätzlich daran orientiert. Es wird meist Tag verwenden und auch Markierung. Stichwort habe ich verwendet, weil dies bei KDE sonst meist verwendet wird.
Jetzt habe ich in der Übersetzungsdatenbank nochmals nachgesehen.
Tag --> Stichwort: 689 mal,
Tag --> Tag: 1234 mal.
Das stimmt zwar nicht genau. Bei Tag-Tag sind viele falsche dabei, aber sicher nicht die Hälfte. Ich werde die Version mit Stichwort jetzt hochladen und dann machen wir noch mals eine Runde in diesem Review. Oder?
| kommit.po | ||
|---|---|---|
| 70 | Die weiteren Verwendungen von fetch passe ich auch noch an. Das gefällt mir nicht sehr:  Es ist schwierig, wie weit geht man? Am besten für neue Benutzer und versierte Benutzer würden englische Beschriftungen mit deutschen Tooltips sein. Das haben wir leider nicht. | |
| 375 | Ich hatte hier Server im Hinterkopf, aber stimmt, es ist mehr das Remote-Repository | |
| 667 | Hier verwende ich "Zweige vergleichen ..." | |
| 985 | Hier werde ich Beschreibung statt Nachricht verwenden | |
| 1013 | Geändert von Nachricht auf Beschreibung | |
| 2375 | Diese Übersetzung finde ich nicht gut...  Andere verwenden sie auch. Ist "Eintragender" besser? Oder lassen wir das Original? | |
| 2536 | Dieser String dürfte nicht verwendet werden. Der wird im Code ersetzt durch "Checkout..." | |
| 2603 | Geändert zu Beschreibung | |
| 2616 | Ich habe es mir in der Oberfläche nochmals angesehen. Stimmt. Ich glaube Beschreibung passt am besten. In Zeile 2603 und weitere, werde ich es auch zu Beschreibung ändern. | |
| kommit.po | ||
|---|---|---|
| 158 | Also "Stichwort" fände ich als übersetzung für git tag schon eher schlimm, verwendet git selbst das so? | |
| kommit.po | ||
|---|---|---|
| 70 | Es sieht wirklich nicht toll aus. Es ist halt auch hier so im Sprachgebrauch, dass man aus Effizienzgründen praktisch nicht übersetzt, weil man mit dem Programm auf der Konsole sowieso nur englisch „reden“ kann. | |
| 158 | git --help sagt: tag ein mit GPG signiertes Tag-Objekt erzeugen, auflisten, löschen oder verifizieren. Es wird also gar nicht übersetzt. Ich arbeite ja selbst in der Software-Entwicklung. Ich kann mich nicht erinnern, dass jemals jemand Tag im Sprachgebrauch übersetzt hätte. (Allerdings wurden sie an sich nicht oft verwendet) | |
| 471 | des ausgewählten Stashs | |
| 2375 | Ich komme mit Einspieler ganz gut klar, zumal wir auch Einspielen für Committen verwenden. | |
Review aktualisiert, Stichwort durch Tag ersetzt.
@felf: Ist hier noch was zu machen? Oder kannst du den Review auf accept stellen?
Ich habe jetzt nicht alle Häkchen geprüft, weil bei deinen Diffs aus irgendeinem Grund immer unsere Kommentare in einer neuen phabricator-Ansicht geöffnet werden *https://phabricator.kde.org/D30138?id=84035), aber die tatsächlich gemachten Änderungen auf der Hauptseite stehen (https://phabricator.kde.org/D30138). Bei meinen ist das (gefühlt?) nie der Fall. Ich gehe einfach mal davon aus, dass dort, wo ein Häkchen ist, mein Kommentar übernommen wurde.
Zwei neue Bemerkungen habe ich noch hinzugefügt. Wenn die durch sind, kann hier zu.
| kommit.po | ||
|---|---|---|
| 575 | In der Originalseite dieses PR steht oberhalb dieses Strings: #| msgid "New stash..." Ist das behoben? | |
| 2622 | wäre es nicht eigentlich „des Autoren“? Oder ist das schon zu altmodisch und „des Autors“ ist modernes, eingedeutschtes IT-Englisch? ^^ | |
Hallo,
ich glaub, ich weiß schon wieso das immer bei mir so ist. Das originale Diff dürfte ich mit der Diff-Anzeige aus Kdesvn gemacht haben. Da werden nur wenige angrenzende Zeilen ins diff mit übernommen. Das letzte Diff habe ich in der Kommandozeile mit svn diff -X -U60 gemacht. Das stimmen die Zeilen nicht mehr überein und Phabrikator blendet alle Kommentare aus.
Zu dieser Zeit dürfte ich an Hand einer anderen Seite die Reviews erstellt haben. Ich habe da viel herumkopiert, dann manchmal noch die diffs bearbeitet. Ich habe relativ lange gebraucht, bis ich einen einfachen Ablauf gefunden habe.
Deine Anmerkungen habe ich eingearbeitet.
Eingespielt mit https://websvn.kde.org/?revision=1711174&view=revision, Leider mit falscher Beschreibung …