Fix that hotkey file required mixed-language definitions#284
Conversation
The main menus were required in English, but submenus were needed in localized language of the menu label. This made it very difficult to figure out how to make hotkeys work. This patch makes that main menus are also localized, thus the GUI can be used to visually inspect and write in. The patch was developed with help by Claude Code - fully reviewed and tested, except that I cannot get the "Profiles" third level do anything, despite the menu item displays the assigned hotkey. I'll separately submit a Default Hungarian hotkey file.
|
Here is the Claude Code session if necessary, including alternative approaches for later. ❯ I tracked down a bug in this RoxTerm program in this directory, it's an open source terminal. (Now I just try if ● Let me check the memory index and get some context on what you've found. Recalled 1 memory (ctrl+o to expand) ● Bash(git -C /home/lion/tmp/roxterm log --oneline -10 && git -C /home/lion/tmp/roxterm diff master..HEAD --stat) ● The branch fix-hotkeyfile is ahead of master by 0 commits — looks like you haven't committed the fix yet. What's the ✻ Sautéed for 8s ❯ How can I write mutliple lines here? Shift enter seems to submit the prompt. ● In Claude Code, you can write multiple lines using Option+Enter (on Mac) or Alt+Enter (on Linux/Windows) to insert a Alternatively, you can paste multi-line text directly into the prompt. ✻ Worked for 2s ❯ I put a file here called "my-test-hotkeys.txt", this is a copy of the hotkey file RoxTerm currently loads, a standard ● Let me read the relevant code sections before making suggestions. Searched for 5 patterns, read 3 files (ctrl+o to expand) ● Now I have a clear understanding of the mechanism. Let me trace exactly what's happening: How it works:
The inconsistency:
Design options for the file format: Option 1 — All English (recommended for portability) Option 2 — All localized (consistent, simple rule) Option 3 — Symbolic internal IDs (most robust, breaking change) Option 4 — Accept both English and localized (best UX, hardest) Pragmatic recommendation: Option 2 is the smallest, cleanest fix for consistency. Option 1 is better for multi-locale ✻ Crunched for 2m 27s ❯ This feature currently has no GUI (it just opens this file in text editor), so a user with a translated user ● Yes, that reasoning is sound. The two-phase approach makes sense:
One thing worth noting now so it doesn't bite later: if you ever make that switch, existing hand-edited localized So the short-term plan is: fix the section names to use the translated strings (pass _("File") instead of "File" in ✻ Crunched for 15s ❯ Excellent, thanks. Please implement the fix with localized names. ● Let me read the full menutree.c to find the top-level menu item labels and the menutree_labels array. Searched for 1 pattern, read 1 file (ctrl+o to expand) ● Let me check the Tabs menu labels and the menutree header for the full list of IDs. Searched for 1 pattern, read 1 file (ctrl+o to expand) ● Let me read the exact macro definition to confirm Tabs and Search are in TOP_LEVEL_MENU_ITEMS. Searched for 1 pattern, read 1 file (ctrl+o to expand) ● Good — menutree_set_accel_path_for_item is only used inside menutree_apply_shortcuts. I now have everything I need.
● Update(src/menutree.c) ● Update(src/menutree.c) ● Now replace menutree_apply_shortcuts: ● Update(src/menutree.c) ● Now let's verify it compiles: ● Bash(cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug 2>&1 | tail -5 && cmake --build build --target roxterm 2>&1 | grep ● Bash(cmake --build build --target roxterm 2>&1 | tail -5) ● Clean build, no warnings. The changes:
In an English locale the behaviour is identical to before. In a Hungarian (or any other translated) locale, users can ✻ Churned for 7m 17s ❯ /rename roxterm-hotkeys |
|
I don't agree with using option 2 (use the local language in the keyfile). The main problem with it is that the supplied Default file would only work in English. Instead I think we should use option 1 (the keyfile uses untranslated English). The strings can be translated after reading them from the keyfile to match the translated label used by GTK. To make the UX easier, roxterm could regenerate the file just before opening the text editor. It could add all the available menu items to the file, commenting out the ones that aren't bound. When the locale isn't English it could add an additional comment above each one, showing the translated version. |
|
I absolutely agree with your explanation. Thank you for fast feedback! I was also worried about this approach, but this was the smallest change, only 20-25 lines. Getting the original English name of the menu might take a bit more. Please do not close this PR, I'll see if Claude wants to build on this branch or start over from "master". (I think some of these changes are already a good start.) (I think adding more commits to this branch will expand the PR, we will see.) Your ideas are quite good, they fully solve all problems. I'll get back soon with a better solution. |
|
It does make sense for you to continue working with Claude Code, thanks for offering. TBH it's so long since I worked on this that I can't really remember how all this works. You're right, looking up the untranslated names is harder than I realised. I don't know why GTK is translating the accel paths for menu items but not the top-level menus. It shouldn't be translating either, because the accel path strings aren't flagged with () or N(), but perhaps there are matching strings tagged for translation elsewhere. But it doesn't make sense that GTK translates accel paths at all. There is probably a better way to do this, based on GAction, or even with builder XML, but that might need more major refactoring. The reason I didn't do it in a more standard way like that in the first place is probably because it originally started as a GTK 2 app and I took the path of least resistance when upgrading it to GTK 3. Maybe, instead of applying the English strings as accel paths, we could hash them, or use a look-up table, to make sure they are all unique strings that aren't translated. |
|
Sorry, I didn't have time to check this yet, but will return to this soon. Just wanted to answer: GTK is not using any of the names (English or translated), it's the program searching for the menu objects in the menu tree by name, and then assign the hotkey to menu object. The problem is that the original code does that find by this code: Meaning, "go into this menu object" and the last string parameter says what string key to take from the configuration file (key/value pairs). Then e.g. File menu is walked form top to bottom, item's names (which are Hungarian in runtime for me), are appended to word "File" + "/") resulting in a mixed language lookup in the data loaded from the text config file key/value pairs. (There are other places where the complete menu path is harcoded in English string.) My fix simple replaced this hard-coded string parts to the actual visible name of that "File" menu object, into which the code is "descending". What you say is last sentence, is that something like Claude's first reply lists as "option 3"? The core problem with any "systemic keys" is that users need to edit this manually. Maybe it would be easy to simply copy a hotkey edit window from another similar licensed app, or just make one in the roxterm-config app using Claude. It can examine current code and work in 100% similar fashion, won't add a completely different GUI or code. (But I'm a web developer and I make web apps only, with Claude too (in .NET). In the 90's I worked on desktop programs too, e.g. in Visual C++, that was quite a while ago, but I can review and test what Claude creates. Those "hotkey" windows are usually very simple, e.g. like this one in Phototonic (but this is Qt) 
That eliminates the whole original problem, and makes the program easier to use. And not a big work "for me" probably. Config lookup keys could be the current English names of the menu, so that exiting config files remain working. But that returns to the English names regardless whether there is a GUI or not, so maybe that should be first, GUI just separately later. If you agree to receive patch for this, please let me know about any specifics you wish. Or if you know a program that is GTK3 and has a window like this. I'm glad to see "AI patches" may be welcome. Claude Code is a big help in my work and my hobby Linux projects too. It needs work, but I'm not spending hours on finding references to a modified thing for example. Or I'm not forgetting to add +1 or -1 so often like normally. :-) FYI I found po4a in your project, and now I'm designing and developing a FAQ text translation method for antiX. The bash scripts are just wrappers around gettext and po4a, but it's a wonderful one, and needed to examine so many aspects of everything, it's now a 3000 lines long RoxTerm 3.x terminal window chat. :) If you want to take a look, here is the log. https://c64.rulez.org/~lion/antiX/antix-faq-program.txt |
|
I've made some changes so that the accelerator paths are in English so the supplied Default file can work in all languages. I'll try to do the second part soon, adding all possible options to the keyfile with translations. |
|
Wow that's great, thank you! |
|
I've fixed a regression which was causing most of the accelerators (shortcuts) to fail to apply to their menu items. I've also made it so that you don't have to include the ellipses (...) in shortcuts config files and translations. I've updated the po files to remove those ellipses, so hopefully you won't have to make any changes. Some line numbers where the translatable strings are located may change again when I progress to part 2 of this update. Old shortcuts config files should work whether or not they include the ellipses. |
|
I think this issue is ready to be closed now, but I'll leave it open until you confirm it's working for you. I have updated the documentation to show that the accelerator paths should be English now, so you will probably want to update the translation for that before I make a new release. Do you keep in touch with any other translators? |
2 participants
The main menus were required in English, but submenus were needed in localized language of the menu label. This made it very difficult to figure out how to make hotkeys work. This patch makes that main menus are also localized, thus the GUI can be used to visually inspect and write in. The patch was developed with help by Claude Code - fully reviewed and tested, except that I cannot get the "Profiles" third level do anything, despite the menu item displays the assigned hotkey. I'll separately submit a Default Hungarian hotkey file.