In D30573#697316, @felf wrote:

Und natürlich noch einen Fehler drin gehabt (doppelte Belegung).

Doppelte oder auch mehrfache Belegung ist kein Fehler (manchmal hat man nur eine begrenzte Buchstabenanzahl zur Auswahl), erfordert jedoch mehrfaches Tippen des Buchstaben (Alt+Buchstabe).

In D30573#697319, @felf wrote:

An Kürzel in kio6.po (also Dolphin) angeglichen. („Öff&nen mit“ statt „Öffnen &mit“).

Guten Tag, Frank!

1. „m“ finde ich logischer und einfacher zu merken, da Teil von „mit“, wie ist dann die Eselsbrücke für „n“? Und wie ist es, wenn beides „Öffnen“ und „Öffnen mit“ im gleichen Untermenü vorhanden sind?
2. Überall, wo du in der Übersetzung ein „&“ hinzugefügt hast, fehlt dieses Zeichen im englischen Text. Bist du dir sicher, dass es so funktioniert? Bis jetzt haben wir alle Vorkommen von „&“ im msgstr entfernt, wenn es nicht in msgid drin war.

In D30573#697323, @bxela wrote:

1. „m“ finde ich logischer und einfacher zu merken, da Teil von „mit“, wie ist dann die Eselsbrücke für „n“?

Geht mir genauso. Die Alternative ist, es bei den anderen überall auf m anzupassen, aber dann sollte da natürlich auf andere Konflikte geachtet werden. Mir ist Eindeutigkeit lieber als Mehrfachbelegung.

Und wie ist es, wenn beides „Öffnen“ und „Öffnen mit“ im gleichen Untermenü vorhanden sind?

Das sehe ich weder in Dolphin noch Gwenview. Ist dir ein Beispiel bekannt?

2. Überall, wo du in der Übersetzung ein „&“ hinzugefügt hast, fehlt dieses Zeichen im englischen Text. Bist du dir sicher, dass es so funktioniert?

Die Strings gehören laut Quelltextverweis zum Kontextmenü. Von daher eigentlich schon, wenn auch ungetestet.

Bis jetzt haben wir alle Vorkommen von „&“ im msgstr entfernt, wenn es nicht in msgid drin war.

Ja das war mir aufgefallen. Ich habe es absichtlich so eingebaut, weil das Fehlen eben dazu führt, dass mitunter unpraktische Kürzel automatisch zugewiesen werden. Lustigerweise bekommt „Eigenschaften“ immer das g statt des e, sowohl in Gwenview als auch in Dolphin.

In D30573#697326, @felf wrote:

In D30573#697323, @bxela wrote:

1. „m“ finde ich logischer und einfacher zu merken, da Teil von „mit“, wie ist dann die Eselsbrücke für „n“?

Geht mir genauso. Die Alternative ist, es bei den anderen überall auf m anzupassen, aber dann sollte da natürlich auf andere Konflikte geachtet werden. Mir ist Eindeutigkeit lieber als Mehrfachbelegung.

Und wie ist es, wenn beides „Öffnen“ und „Öffnen mit“ im gleichen Untermenü vorhanden sind?

Das sehe ich weder in Dolphin noch Gwenview. Ist dir ein Beispiel bekannt?

Auf die Schnelle finde ich nur im Dophin-Kontextmenü: Mit Kate öffnen und Öffnen mit

2. Überall, wo du in der Übersetzung ein „&“ hinzugefügt hast, fehlt dieses Zeichen im englischen Text. Bist du dir sicher, dass es so funktioniert?

Die Strings gehören laut Quelltextverweis zum Kontextmenü. Von daher eigentlich schon, wenn auch ungetestet.

Bis jetzt haben wir alle Vorkommen von „&“ im msgstr entfernt, wenn es nicht in msgid drin war.

Ja das war mir aufgefallen. Ich habe es absichtlich so eingebaut, weil das Fehlen eben dazu führt, dass mitunter unpraktische Kürzel automatisch zugewiesen werden. Lustigerweise bekommt „Eigenschaften“ immer das g statt des e, sowohl in Gwenview als auch in Dolphin.

Ich habe mal mit "msgfmt -c x.po -o x.mo" getestet, es werden keine Fehler gemeldet, wenn msgstr „&“-Zeichen enthält, msgid jedoch nicht.
Wie dem auch sei, hier muss eine eindeutige Regel her (bzgl. wann „&“ in msgstr, aber nicht in msgid sein darf. Sonst ist es nur Magie …

In D30573#697327, @bxela wrote:

In D30573#697326, @felf wrote:

In D30573#697323, @bxela wrote:

2. Überall, wo du in der Übersetzung ein „&“ hinzugefügt hast, fehlt dieses Zeichen im englischen Text. Bist du dir sicher, dass es so funktioniert?

Die Strings gehören laut Quelltextverweis zum Kontextmenü. Von daher eigentlich schon, wenn auch ungetestet.

Bis jetzt haben wir alle Vorkommen von „&“ im msgstr entfernt, wenn es nicht in msgid drin war.

Ja das war mir aufgefallen. Ich habe es absichtlich so eingebaut, weil das Fehlen eben dazu führt, dass mitunter unpraktische Kürzel automatisch zugewiesen werden. Lustigerweise bekommt „Eigenschaften“ immer das g statt des e, sowohl in Gwenview als auch in Dolphin.

Ich habe mal mit "msgfmt -c x.po -o x.mo" getestet, es werden keine Fehler gemeldet, wenn msgstr „&“-Zeichen enthält, msgid jedoch nicht.
Wie dem auch sei, hier muss eine eindeutige Regel her (bzgl. wann „&“ in msgstr, aber nicht in msgid sein darf. Sonst ist es nur Magie …

@loisspitz @daphipz
Guten Abend, Alois und Philipp!
Was sagt ihr zum Thema „&“ als Markierung für die Tastenkombination „Alt+<Buchstabe>“ in die Übersetzung einzubauen, ohne „&“ im englischen Original drin zu haben?

Was sagt ihr zum Thema „&“ als Markierung für die Tastenkombination „Alt+<Buchstabe>“ in die Übersetzung einzubauen, ohne „&“ im englischen Original drin zu haben?

Seid ihr sicher, dass das funktioniert? GNOME verwendet _ als Kennzeichen für Mnemonics. Wenn dort im Original keiner war, wurde der einfach als "normaler" Unterstrich in die Übersetzung übernommen und dem Benutzer auch _so angezeigt.
Ich denke, dass wir hier genau das gleiche Problem haben werden.

In D30573#697842, @daphipz wrote:

Was sagt ihr zum Thema „&“ als Markierung für die Tastenkombination „Alt+<Buchstabe>“ in die Übersetzung einzubauen, ohne „&“ im englischen Original drin zu haben?

Seid ihr sicher, dass das funktioniert?

Ja, das habe ich schon vor gefühlt 20 Jahren so beim Entwurf von Qt-Oberflächen gemacht. Falls du ihn installiert hast, geh mal in den Qt Widget Desiger, erstelle einen Hauptfenster-Entwurf und gib im Menü einen Text mit & ein.

GNOME verwendet _ als Kennzeichen für Mnemonics. Wenn dort im Original keiner war, wurde der einfach als "normaler" Unterstrich in die Übersetzung übernommen und dem Benutzer auch _so angezeigt.

Davon habe ich tatsächlich noch nie gehört. Allerdings aber ich ebenso noch nie ne Gnome-Anwendung geschrieben.

Ich denke, dass wir hier genau das gleiche Problem haben werden.

Wieso? Es gibt doch genug existierende Beispiele von manuellen &-Setzungen in der Übersetzungsdatenbank. Wenn ihr es nicht so machen wollt, nehme ich es halt wieder raus. Ich find’s nur immer so nervig, dass ich „Öffnen mit“ nicht per Tastatur auswählen kann, weil ich standardmäßig ein US-Layout aktiv habe, weil das „IT-affiner“ ist.

In D30573#698559, @felf wrote:

Wieso? Es gibt doch genug existierende Beispiele von manuellen &-Setzungen in der Übersetzungsdatenbank. Wenn ihr es nicht so machen wollt, nehme ich es halt wieder raus. Ich find’s nur immer so nervig, dass ich „Öffnen mit“ nicht per Tastatur auswählen kann, weil ich standardmäßig ein US-Layout aktiv habe, weil das „IT-affiner“ ist.

Hallo Frank,
du schreibst „Wenn ihr es nicht so machen wollt, …“
→ Woran machen wir fest, dass im msgstr ein „&“ vorkommen darf, obwohl msgid kein „&“ enthält? Z. B. hier ein Beispiel aus deiner Einreichung:

#. +> trunk6 stable6
#: app/fileopscontextmanageritem.cpp:189
#, kde-format
msgid "Open With"
msgstr "Öff&nen mit"

Ist es vielleicht #, kde-format?
Oder legen wir einfach fest, dass im msgstr ein „&“ vorkommen darf, obwohl msgid kein „&“ enthält?
Bei dieser Festlegung geht es nicht nur um diese eine Einreichung, sondern um:

• Übersetzungen, die man selber macht → „&“ drin lassen, löschen oder ist „&“ einfach überall zugelassen, …
• Korrekturlesen

In D30573#698600, @daphipz wrote:

Zeile 403 in messages/gwenview/gwenview.po
Vielleicht "Verknüp&fung hier erstellen"? Oder ist es genau andersherum, dass man das zu verknüpfende Element auswählt?
Oder "Hierher verknüp&fen", um mit den Strings darüber gleichzuziehen?

Hallo Frank, wahrscheinlich hast du den Korrekturvorschlag von Philipp übersehen, deswegen liegt deine Einreichung D30573 bereits fast 5 Wochen unberührt. Könntest du dir bitte Philipp's Anmerkung anschauen, danke!

In D30573#698665, @bxela wrote:

Hallo Frank,
du schreibst „Wenn ihr es nicht so machen wollt, …“
→ Woran machen wir fest, dass im msgstr ein „&“ vorkommen darf, obwohl msgid kein „&“ enthält? Z. B. hier ein Beispiel aus deiner Einreichung:

Meine persönliche Meinung: Wenn die Automatik unschöne Ergebnisse liefert, also Mehrfachbelegungen oder mnemonisch schlecht passende Kürzelbuchstaben.

Oder legen wir einfach fest, dass im msgstr ein „&“ vorkommen darf, obwohl msgid kein „&“ enthält?
Bei dieser Festlegung geht es nicht nur um diese eine Einreichung, sondern um:

• Übersetzungen, die man selber macht → „&“ drin lassen, löschen oder ist „&“ einfach überall zugelassen, …
• Korrekturlesen

WIMRE war es früher deutlich stärker verbreitet, dass & händisch vergeben wurden. Das hat in meinem Gefühl in den letzten Jahren merklich abgenommen. Einerseits weil Tastaturbedienung durch andere Paradigmen verdrängt wird, zum anderen weil die GUIs dieses Feature von sich aus immer mehr verstecken. GTK bietet nicht einmal mehr die Option, die Unterstreichungen dauerhaft anzuzeigen.

In D30573#701464, @felf wrote:

In D30573#698665, @bxela wrote:

Hallo Frank,
du schreibst „Wenn ihr es nicht so machen wollt, …“
→ Woran machen wir fest, dass im msgstr ein „&“ vorkommen darf, obwohl msgid kein „&“ enthält? Z. B. hier ein Beispiel aus deiner Einreichung:

Meine persönliche Meinung: Wenn die Automatik unschöne Ergebnisse liefert, also Mehrfachbelegungen oder mnemonisch schlecht passende Kürzelbuchstaben.

Oder legen wir einfach fest, dass im msgstr ein „&“ vorkommen darf, obwohl msgid kein „&“ enthält?
Bei dieser Festlegung geht es nicht nur um diese eine Einreichung, sondern um:

• Übersetzungen, die man selber macht → „&“ drin lassen, löschen oder ist „&“ einfach überall zugelassen, …
• Korrekturlesen

WIMRE war es früher deutlich stärker verbreitet, dass & händisch vergeben wurden. Das hat in meinem Gefühl in den letzten Jahren merklich abgenommen. Einerseits weil Tastaturbedienung durch andere Paradigmen verdrängt wird, zum anderen weil die GUIs dieses Feature von sich aus immer mehr verstecken. GTK bietet nicht einmal mehr die Option, die Unterstreichungen dauerhaft anzuzeigen.

Ich persönlich nutze Mnemonics im Alltag überhaupt nicht. Deshalb setze ich nur welche in die Übersetzung, wenn sie auch im Original vorhanden sind - "Schuster, bleib bei deinen Leisten". Wenn du, @felf, sie öfter nutzt und dadurch weißt, dass sie an einer bestimmten Stelle Sinn ergeben, setze sie gerne ein!

@felf Bist du noch daran interessiert, diese Einreichung zu bearbeiten? Ich könnte sonst gern übernehmen und die Änderungswünsche einpflegen. Wenn ich bis zum Wochenende nichts von dir höre, würde ich die Einreichung am Montag übernehmen. Ist das in Ordnung?

Hallo @daphipz. Entschuldige, ich bin gerade ziemlich ausgelastet und die kürzliche Flut an Mails auf der Liste hat mich kognitiv überladen. :'(
Übernimm gern hier.