style shortcuts translated and hierarchicalised in prefs/dialog

[dterrahe]

fixes #18325

while testing this I'm getting bitten quite badly by #18196; only a part of the style tree ends up getting localized. Switching off setlocale in the opencl code fixes it.

Renaming or deleting presets (and presumably styles) while in non-English ends up not finding/removing the previous associated action. Still needs fixing.

[TurboGit]

I haven't seen this while I was finalizing my PR :)

[TurboGit]

Tested, for the preference it is all good.

The only remaining issue is the non translated name displayed to the user via the control log in dt_styles_apply_to_dev at the end of the routine. This is working on my PR because I'm also using the internal hash-table, maybe you can do better?

[dterrahe]

Remaining issue with style toast resolved in first commit

Second commit adds hierarchical menus for processing module presets and also changes their names to l10n format so that shortcuts don't break when changing languages. (For now, I haven't attempted to retain existing shortcuts so they'll all be dropped).

There are remaining issues, especially where treeviews and dialogs assume there is no difference between the internal and displayed/translated names. So when editing a preset, the translated name is presented, but then when saving that doesn't match the existing preset (if there are multiple levels divided by |) because the translated name contains " | " rather than just "|" (space before and after). Another issue, that is dealt with, but with consequences, is that internally contextualized translations (C_() or NC_()) are represented by "context|text". This is how Gtk does it. But | is now also used for hierarchies. So internally a context marker is changed to ^ and later changed back just before translating. If a user intentionally puts ^ in a string marked for translation with l10n they may not realise this will be interpreted as a context marker.

[dterrahe]

On second thought, just introducing the hierarchical submenus for processing module presets. In the module hamburger menu only, not for the "favorite presets", because I think people would insert | if they have many per-module presets, but then don't want that to lead to a long list of one-item submodules in the favorite menu (where they would anyway only put the most-used ones).

This does not include the translation work on presets yet (i.e. to make the internal representation, which is linked to shortcuts, be independent of the chosen language so that shortcuts don't break when switching. That's still a more involved change that requires a lot of testing and feedback.

@TurboGit I think this is ready.

[TurboGit]

Thanks!

[dterrahe]

Release notes:

• presets can now be arranged in sub menus, like styles can, by inserting | in their name between levels. The shortcuts dialog/preferences tab now show these collapsible hierarchies for styles and presets too (and the bug that style shortcuts were not translated is fixed).