composability of translations from different packages

[stevengj]

The one thing I've been worried about is how _"..." strings compose within Julia's package system, because they currently use the global textdomain setting.

• One perspective is that most individual packages shouldn't need translations, because they don't provide user interfaces — this is only done at the top application level. So there is only a single translation "domain" for the application.
• However, there are packages that open up user interface windows, like @timholy's ImageView.jl package — shouldn't each such package be able to have its own translations, in its own po directory?

One option is for _"..." to expand to gettext(GETTEXT_DOMAIN, "..."), where GETTEXT_DOMAIN is somehow relative to the current @__MODULE__. e.g. we could require that any module using _"..." defines a constant GETTEXT_DOMAIN to be the domain string.

That is, to use _"..." in a package, you would do something like:

module Foo
using Gettext

const GETTEXT_DOMAIN = "Foo-<uuid>"
function __init__()
    bindtextdomain(GETTEXT_DOMAIN, joinpath(@__DIR__, "..", "po"))
end

# ...
end

at which point _"..." should work, but you would have to explicitly pass GETTEXT_DOMAIN to ngettext etc. I guess we could define an @ngettext macro that does this for you.

The above still seems a little awkward, though. Not sure what the cleanest solution is here?

[stevengj]

Indeed, the GNU gettext manual recommends using a per-library domain for libraries:

For a library, which has its own translation domain, [the declaration of the _ macro] reads like this:

#include <libintl.h>
#define _(String) dgettext (PACKAGE, String)

In other words, dgettext is used instead of gettext. Similarly, the dngettext function should be used in place of the ngettext function.

We could do the same thing by checking whether @__MODULE__ === Main

[ericphanson]

Perhaps if the module doesn’t define a domain it could fallback to a global one?

[stevengj]

I thought about that, but it seems like using the global domain should almost always be an error unless @__MODULE__ === Main … silently falling back to it just seems like an invitation for bugs.

If you want to use the global domain, you can explicitly call gettext(str). Or redefine the _"..." macro.