Looking at the way that key press combinations/keybindings are displayed it looks like that these are handled in an inconsistent way and are not translated.
To be more precise: The keybindings listed in the menu labels look fine. But if the preferences for the keybindings are opened then the display of keybindings looks different than in the menu labels:
- the key names are not translated (also the dialogs text is translated) - ```Ctrl``` seems to be displayed as ```Primary```. The menu items always use ```Ctrl```.
the key names are not translated (also the dialogs text is translated)
Being an ASCII only person I can't test it, but I checked and the key name strings seem to be marked for translation and they are translated in the random po file I checked (fr.po). Maybe its just that nobody has translated them for your language. Which one did you use?
Ctrl seems to be displayed as Primary. The menu items always use Ctrl.
This is a GTK issue. Geany gets the key names from GTK and it returns `primary` instead of `ctrl`.
I think its because which is the primary key depends on the keyboard, and system and keymapping. For example Macs have all sorts of funny modifier keys. The use of `primary` is a portable name that works on all systems and so can be portably saved in files, but of course when showing it on the menus GTK knows the particular system its running on and what the real `primary` key is and uses that name, `ctrl` on your system.
This is a GTK issue. Geany gets the key names from GTK and it returns primary instead of ctrl.
But this is not happening in the keybindings listed after a menu item. Are that constructed in a different way? Can the preferences dialog simply do the same thing?
Being an ASCII only person I can't test it, but I checked and the key name strings seem to be marked for translation and they are translated in the random po file I checked (fr.po). Maybe its just that nobody has translated them for your language. Which one did you use?
I thought I was precise but maybe I was not clear enough :smiley: With "the key names are not translated" I only meant the key names in the keybindings preferences dialog. Again, if I check the menus I e.g. see that "Shift" is translated to "Umschalt" (german). But the keybindings preferences dialog shows "Shift". So the key name is translated but the dialog does not "use" the translation.
I only meant the key names in the keybindings preferences dialog.
My misunderstanding, I read it as the action names not the key names
But this is not happening in the keybindings listed after a menu item. Are that constructed in a different way? Can the preferences dialog simply do the same thing?
Both names are constructed by GTK, not by Geany, its not in our control as far as I know. I guess the name used in the keybinding files needs to be portable, so its always in English for the same reason as using `primary`.
Maybe I should clarify, the key name shown in the keybindings menu is something that is understandable by GTK so it can set it, and we can save and restore it in the keybindings file, specifically it must be readable by [gtk_accelerator_parse()](https://developer.gnome.org/gtk3/stable/gtk3-Keyboard-Accelerators.html#gtk-...).
Note that the user can directly edit the shortcuts in the keybindings prefs dialog, they don't have to use the capture sub-dialog. As there is no way of un-translating key names so they have to be in the portable form, which happens to be English.
Hmmm...couldn't the ```GtkTreeStore``` which is holding the keys be expanded with another invisible column?
Then the displayable translated key name goes in the column which is displayed today and the portable and parse-able version goes into the invisible column. On applying the config, the values from the invisible column can be used to set the key accelerator. Just an idea.
Note that the user can directly edit the shortcuts in the keybindings prefs dialog,
Invisible columns are not editable :)
I guess the dialog could have two columns, showing both the key label and the key name, with the key name being editable.
Well, the user could edit the visible column. On doing so the invisible column would need to be updated with the corresponding parse-able value of the just entered value.
I guess the dialog could have two columns, showing both the key label and the key name, with the key name being editable.
The dialog would become quite wide I think. But that's a matter of personal favour I guess.
Well, the user could edit the visible column. On doing so the invisible column would need to be updated with the corresponding parse-able value of the just entered value.
IIUC you want the visible column to be a translated name. As I said above, there is no way of un-translating strings available to my knowledge, so the "updating" is not a simple thing.
(can't even send the text to google translate to convert it, "Umschalt s" comes back as "Switch s" *sigh*)
I see. Could a translation be done using the .po files? That would be a backwards translation then. Instead of the usual direction like "Shift" --> "Umschalt" do "Umschalt" --> "Shift". But I guess it's not possible?
Not tested, but I'm guessing GTK+ itself uses [`gtk_accelerator_get_label`](https://developer.gnome.org/gtk3/stable/gtk3-Keyboard-Accelerators.html#gtk-...) or [`gtk_accelerator_get_label_with_keycode`](https://developer.gnome.org/gtk3/stable/gtk3-Keyboard-Accelerators.html#gtk-...) or such to get the translated name for display.
@codebrainz yes, but @LarsGit223 wants to go from the label to the keycode/keyname which isn't available. It needs the inverse of `gtk_accelerator_get_label()`.
@LarsGit223 I don't know how GTK gets the translated names, I guess it has some po files in its own domain, but even then I don't know if there is a reverse of `gettext()`.
Sounds like the concept with the invisible column is not working/would not work. So the two-column concept would be kind of a possible workaround.
I am not sure its worth it though, the keyname is just a programming language, and Geany is targetted at programmers after all.
A rather simple/clean solution would be to just put a tooltip column that says something like:
``` Click to edit, blah blah blah. Current shortcut: {translated name} Default shortcut: {translated name} ```
Or something like that. It's not intrusive in the UI and adds value even for Anglos.
I noticed this issue when working on #1633 and #1395 and seeing keybindings like `<Primary>something` is rather confusing.
Note that the user can directly edit the shortcuts in the keybindings prefs dialog, they don't have to use the capture sub-dialog. As there is no way of un-translating key names so they have to be in the portable form, which happens to be English.
Does anybody really use the possibility to edit the keybindings directly? I don't think anyone wants to write keybindings like `<Primary><Shift>s` by hand. I would personally just remove the possibility of manual editing and then `gtk_accelerator_get_label()` could be used to show the user-friendly name only. Note the string above the keybindings list is incorrect: "...or double click on an action to edit the string representation of the shortcut directly" isn't true because double-clicking makes the Grab Key dialog appear (one would have to slowly double-click).
If manual editing is a hard-requirement there could be an edit box below the symbol list tree which could get filled with the currently selected keybinding in the form of `gtk_accelerator_name()` which could be edited there.
@techee yeah, a single editing entry showing only the selected keybinding would be fine, then the whole table could indeed be the user friendly lable.
github-comments@lists.geany.org