GNOME Bugzilla – Bug 680072
gettext issues
Last modified: 2012-07-20 05:23:41 UTC
A couple of issues with the gettext usage in libsecret: - Gettext doesn't seem to be initialized, so the translatable strings wont work. - The strings in the library will need to dgettext to avoid using the domain of the application using the library. - When packaging in Debian/Ubuntu we will split out secret-tool into an optional binary package separate from libsecret (do you consider this tool optional?). However the translations are in the same message catalog. Do there need to be translatable strings in the library (they seem to be only on errors) or can there be two catalogs?
Created attachment 218970 [details] [review] Initialize gettext in secret-tool
Thanks for catching that. (In reply to comment #0) > A couple of issues with the gettext usage in libsecret: > - Gettext doesn't seem to be initialized, so the translatable strings wont > work. I assume you mean in secret-tool. Does the attached patch fix this for you? Does it look right? > - The strings in the library will need to dgettext to avoid using the domain of > the application using the library. I'm using <glib/gi18n-lib.h> as usual, and this uses dgettext() + GETTEXT_PACKAGE. Am I missing something here? > - When packaging in Debian/Ubuntu we will split out secret-tool into an > optional binary package separate from libsecret (do you consider this tool > optional?). However the translations are in the same message catalog. Do there > need to be translatable strings in the library (they seem to be only on errors) > or can there be two catalogs? secret-tool for command line access to passwords. To me the library and the tool seem to go together. It's true that we don't recommend that the error messages returned from libsecret be displayed to the user. But it's still customary to use translatable messages in GError. How come this issue hasn't come up with other libraries like gcr (which consist of multiple components, libgcr, libgck, and command line tools)?
> How come this issue hasn't come up with other libraries like gcr (which consist > of multiple components, libgcr, libgck, and command line tools)? I don't think there's an issue here - just ship all translations in one domain, with the library. Your commandline tool will link against the library anyway.
(In reply to comment #2) > Thanks for catching that. > > (In reply to comment #0) > > A couple of issues with the gettext usage in libsecret: > > - Gettext doesn't seem to be initialized, so the translatable strings wont > > work. > > I assume you mean in secret-tool. Does the attached patch fix this for you? > Does it look right? You also need: setlocale (LC_ALL, ""); first otherwise no locale is loaded I believe. > > - The strings in the library will need to dgettext to avoid using the domain of > > the application using the library. > > I'm using <glib/gi18n-lib.h> as usual, and this uses dgettext() + > GETTEXT_PACKAGE. Am I missing something here? From /usr/include/glib-2.0/glib/gi18n.h: #define _(String) gettext (String) From libsecret/secret-session.c: g_simple_async_result_set_error (res, SECRET_ERROR, SECRET_ERROR_PROTOCOL, _("Couldn't communicate with the secret storage")); So if I'm not mistaken if I linked gcalctool against libsecret it would use the gettext function to look up the string and that uses the domain set with the textdomain() call - "gcalctool" in this case instead. > > - When packaging in Debian/Ubuntu we will split out secret-tool into an > > optional binary package separate from libsecret (do you consider this tool > > optional?). However the translations are in the same message catalog. Do there > > need to be translatable strings in the library (they seem to be only on errors) > > or can there be two catalogs? > > secret-tool for command line access to passwords. To me the library and the > tool seem to go together. It's true that we don't recommend that the error > messages returned from libsecret be displayed to the user. But it's still > customary to use translatable messages in GError. > > How come this issue hasn't come up with other libraries like gcr (which consist > of multiple components, libgcr, libgck, and command line tools)? They probably have the same issue. Some background on the issue; in Debian/Ubuntu we have to package the tool separately from the library so you can have two libraries installed at once. This is required so when the ABI changes you don't have to update all dependencies at the same time. Because the translations are shared between the tool and the library we end up needing three packages libsecret-1-0, libsecret-tools and libsecret-common (containing the translations). As Matthias pointed out in this case we can just ship the translations with the library and rely on them being installed which I hadn't considered. So from that point of view there's not a packaging issue here. However, I would suggest considering splitting the translations into two domains anyway. GNOME projects have traditionally lumped all project translations into one domain probably because autotools makes life harder not doing that. Translations for libsecret are of a higher priority as the chances of a random application using libsecret having something go wrong and show an error message to a user is reasonably high whereas secret-tool is probably only going to be used by sysadmins/hackers who can probably handle it not being 100% translated. This is much like a number of projects that have split their schema property translations into a separate domain since they have different priorities.
Created attachment 219080 [details] [review] Initialize gettext in secret-tool
(In reply to comment #4) > (In reply to comment #2) > > Thanks for catching that. > > > > (In reply to comment #0) > > > A couple of issues with the gettext usage in libsecret: > > > - Gettext doesn't seem to be initialized, so the translatable strings wont > > > work. > > > > I assume you mean in secret-tool. Does the attached patch fix this for you? > > Does it look right? > > You also need: > setlocale (LC_ALL, ""); > first otherwise no locale is loaded I believe. Alright, done and committed. > > > - The strings in the library will need to dgettext to avoid using the domain of > > > the application using the library. > > > > I'm using <glib/gi18n-lib.h> as usual, and this uses dgettext() + > > GETTEXT_PACKAGE. Am I missing something here? > > From /usr/include/glib-2.0/glib/gi18n.h: Note that I'm talking about <glib/gi18n-lib.h> Notice the *-lib.h*. Have you tried it out and seen a problem though? > > > - When packaging in Debian/Ubuntu we will split out secret-tool into an > > > optional binary package separate from libsecret (do you consider this tool > > > optional?). However the translations are in the same message catalog. Do there > > > need to be translatable strings in the library (they seem to be only on errors) > > > or can there be two catalogs? > > > > secret-tool for command line access to passwords. To me the library and the > > tool seem to go together. It's true that we don't recommend that the error > > messages returned from libsecret be displayed to the user. But it's still > > customary to use translatable messages in GError. > > > > How come this issue hasn't come up with other libraries like gcr (which consist > > of multiple components, libgcr, libgck, and command line tools)? > > They probably have the same issue. > > Some background on the issue; in Debian/Ubuntu we have to package the tool > separately from the library so you can have two libraries installed at once. > This is required so when the ABI changes you don't have to update all > dependencies at the same time. Because the translations are shared between the > tool and the library we end up needing three packages libsecret-1-0, > libsecret-tools and libsecret-common (containing the translations). > > As Matthias pointed out in this case we can just ship the translations with the > library and rely on them being installed which I hadn't considered. So from > that point of view there's not a packaging issue here. > > However, I would suggest considering splitting the translations into two > domains anyway. GNOME projects have traditionally lumped all project > translations into one domain probably because autotools makes life harder not > doing that. Translations for libsecret are of a higher priority as the chances > of a random application using libsecret having something go wrong and show an > error message to a user is reasonably high Ideally no messages from libsecret should be displayed to the user. We explicitly state that in the documentation. But regardless, people will do it, so I see your point. > whereas secret-tool is probably only > going to be used by sysadmins/hackers who can probably handle it not being 100% > translated. This is much like a number of projects that have split their schema > property translations into a separate domain since they have different > priorities. I'm happy to try and accommodate the Debian/Ubuntu packaging. Could you submit a patch for libsecret that implements this split?
Ah, I didn't know about gi18n-lib.h. Please ignore me then :) Hmm, the po splitting is even harder than I imagined. So I don't think there'll be a benifit to splitting. Thanks!