Thank you very much for your answer Daiki. Actually I wasn't aware of the issue of the plugin files translation. I came across it by chance when trying to port totem to meson[0]. Once I figured out what was going on, I tried to solve the issue also considering the options you mentioned[1], but I ended thinking about those different options as workarounds for the real solution. Being aware of the impact this issue might have considering the number of applications that would benefit from a proper solution, I decided to implement it.
At the moment, I am also concerned about the length of the time between the review and the following gettext release[1]. Finally, as I mentioned in my first mail, I do have my concerns about whether these patches are being well written and about following a proper technical approach. I tried to make my changes by following how the actual code is written, but I might have overlooked something. Hence, any suggestions which could especially enhance the solution qualitatively, would be much appreciated. Best regards, [0] https://bugzilla.gnome.org/show_bug.cgi?id=783205 [1] https://bugzilla.gnome.org/show_bug.cgi?id=783316#c11 2017-06-08 10:13 GMT+02:00 Daiki Ueno <u...@gnu.org>: > Hello, > > Iñigo Martínez <inigomarti...@gmail.com> writes: > >> Following the last mail, you can find attached three patches that add >> full support for libpeas plugin files support. > > Thank you for the patches. While the implementation looks sensible to > me, I am wondering if it could be worked around by using a separate po > directory for plugins, in a similar way gtk+ does for GObject property > blurbs: > https://git.gnome.org/browse/gtk+/tree/po-properties > > Maybe you could have a po-plugins directory with: > > XGETTEXT_OPTIONS = -kName -kDescription ... > > in Makevars and *.plugins in POTFILES.in. > > This way, you wouldn't need to wait another gettext release. > > Regards, > -- > Daiki Ueno
