mirror of https://github.com/GNOME/gimp.git
81b569cb8c
Plug-in localization was always partially plug-in side, especially for things like custom GUI. But labels or blurb in GIMP (such as in menus or action search) were localizing GIMP side. It had many drawbacks: - To get menu localization, a plug-in had to set up gettext, even though they might want to use something else for their GUI (after all, giving facilities for gettext is a good idea, but there is no reason to force using this system). - There was a complex internal system passing the localization domain name, as well as the catalog file system path to core, then through various classes which we can now get rid of. - There could be domain name clashes, if 2 plug-ins were to use the same i18n domain name. This was handled in now removed functions gimp_plug_in_manager_get_locale_domains() by simply keeping a unique one (and gimp_plug_in_manager_bind_text_domains() would just bind the domain to the kept directory). In other words, one of the duplicate plug-ins would use the wrong catalog. We could try to make the whole thing more complicated or try to forbid plug-ins to use any random name (in particular made easier with the new extension wrapper). But anyway this whole issue doesn't happen anymore if localization is fully made plug-in side, so why bother? I tried to evaluate the advantages of the core-side localization of plug-in labels/blurbs and could only find one theoretical: if we wanted to keep access to the original English text. This could be useful (theoretically) if we wanted to search (e.g. in the action search) in both localized and English text; or if we wanted to be able to swap easily en/l10n text in a UI without reload. But even if we were to ever do this, it would only be possible for plug-ins (GEGL operations in particular are localized GEGL-side), so it lacks consistency. And it's unsure why special-casing English should really make sense for other language natives who want text in their lang, and search in their lang. They don't necessarily care about original. So in the end, I decided to simplify the whole thing, make localization of plug-ins a plug-in side thing. Core will only receive translated text and that's it. It cuts a lot of code out of the core, simplify runtime processing and make plug-in creation simpler to understand. The only think I still want to look at is how exactly menu paths are translated right now. Note that it still works, but it's possible that some things may be worth improving/simplifying on this side too. |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| Makefile.am | ||
| dockable-menu.c | ||
| dockable-menu.h | ||
| file-menu.c | ||
| file-menu.h | ||
| filters-menu.c | ||
| filters-menu.h | ||
| image-menu.c | ||
| image-menu.h | ||
| menus-types.h | ||
| menus.c | ||
| menus.h | ||
| meson.build | ||
| plug-in-menus.c | ||
| plug-in-menus.h | ||
| tool-options-menu.c | ||
| tool-options-menu.h | ||
| window-menu.c | ||
| window-menu.h | ||
| windows-menu.c | ||
| windows-menu.h | ||