Overriding package gettext translations

Is it possible in elixir with gettext to override the translation of the sub packages?
Like how you where able to override each of the translations from your ruby gems in the yml files.
Looking for if it is possible to add some custom translations without having to fork the hex.

2 Likes

The package should not provide its own backend, instead, it should provide the translations which you will include on your own backends. So I would recommend proposing a change to the package.

4 Likes

This is what I was about to reply on this topic: I agree that a good solution is to provide a configurable Gettext backend for libraries that use Gettext.

2 Likes

This is what I was about to reply on this topic: I agree that a good solution is to provide a configurable Gettext backend for libraries that use Gettext.

@whatyouhide are you aware of any packages that already do that? It would be great to have an example.

I’m curious how does it work in practice, e.g. instead:

import MyPackage.Gettext
gettext("foo")

we’d do:

Gettext.gettext(Application.get_env(:mypackage, :gettext_backed), "foo")
# perhaps write a wrapper for extra convenience

Is this right? This looses compile-time features, but I suppose compile-time features aren’t appropriate for a package anyway as we can’t really recompile the package.

2 Likes

As example currently came to this with the package Timex into mind it has translations but wouldn’t mind having some app specific translations for AM and PM. Most of the other translations would preferably use the default translations.

2 Likes

You nailed it, yeah. The example looks like what I had in mind, with the minor tweak

Gettext.gettext(Application.get_env(:my_app, :gettext_backend, MyApp.DefaultBackend), "foo")

with a default (maybe English-only) Gettext backend, as José mentioned.

3 Likes

You wouldn’t necessarily lose compile-time features though, the Application configs are known at compile-time.

2 Likes

You wouldn’t necessarily lose compile-time features though, the Application configs are known at compile-time.

By compile-time features I specifically meant gettext’s ability to extract msgids from code, which I thought was only available when doing import MyApp.Gettext. Come to think of it, the difference between compile-time and runtime was with regards to msgid being a compile-time string or not, so perhaps extracting would still work with Application.get_env(...). Will investigate

2 Likes

Extracting only works if you use Gettext macros, not functions. When you write Gettext.gettext(backend, msgid), you’re not calling a Gettext macro but a Gettext function. This means that you won’t get compile-time extraction of strings (mix gettext.extract) regardless of the msgid being a compile-time string or not.

You wouldn’t necessarily lose compile-time features though, the Application configs are known at compile-time.

They are known at compile time but the Application.get_env/3 call is executed at runtime, so what you wrote doesn’t really apply here.

2 Likes

True, though it could introspect the Config though?

2 Likes

I’m not sure what you mean. We can inspect the config at compile-time, yes, but Gettext.gettext/2 runs at runtime (since it’s a function) so if you use that there is no way we extract translations, even if you use a backend and string literals such as Gettext.gettext(MyApp.Gettext, "foo"). If you didn’t mean this, I’m not sure I’m following anymore, sorry :slight_smile:

1 Like

Guess from the discussion on how to do it no hex has really used such a system yet for translations?

1 Like

I don’t know of any package on Hex that implements Gettext support this way, nope.

1 Like

I meant for pulling static strings to-be-translated out of code. :slight_smile:

1 Like