Trouble Adding Gettext Support to Elixir Library

tugayac

Hey folks ,

I’m one of the maintainers of the Lotus Web library and we had a request to add i18n support for the library. The requester was nice enough to help with a PR here, but I’m having issues getting it to work locally.

If anyone has experience adding Gettext support to libraries, I could use some help understanding the following (posting here because I don’t believe this is a Phoenix-related issue):

Why would Gettext not pick up the correct translations, even though the locale seems to be set correctly in the LiveView process? (see PR comment for details)
Are we adding Gettext support to Lotus Web in the right way, with the goal of allowing users of the library to provide their own translations?
Is there a recommended way of adding Gettext to Elixir libraries? (I couldn’t find any suggestions in the Gettext docs).

Here’s a diff of what I’m trying (also included in the PR discussion) in another Elixir app that uses this branch:

diff --git a/config/config.exs b/config/config.exs
index 5062c76e..32e717e0 100644
--- a/config/config.exs
+++ b/config/config.exs
+config :lotus_web, Lotus.Web.Gettext,
+  priv: "priv/lotus_gettext",
+  locales: ~w(en tr),
+  default_locale: "tr"
+
 import_config "#{config_env()}.exs"
diff --git a/lib/accomplish_web/router.ex b/lib/accomplish_web/router.ex
index 951b8e80..defb9e4c 100644
--- a/lib/accomplish_web/router.ex
+++ b/lib/accomplish_web/router.ex
@@ -48,7 +48,7 @@ defmodule AccomplishWeb.Router do
   scope "/admin", AccomplishWeb.Admin do
     pipe_through :admin
 
-    lotus_dashboard("/lotus")
+    lotus_dashboard("/lotus", on_mount: [{AccomplishWeb.LocaleHook, :default}])
   end
diff --git a/mix.exs b/mix.exs
index ffd13aab..e1e36812 100644
--- a/mix.exs
+++ b/mix.exs
@@ -87,7 +87,7 @@ defmodule Accomplish.MixProject do
-      {:lotus_web, "~> 0.6.2"},
+      {:lotus_web, path: "../lotus_web_branch"},

Here’s the Gettext directory structure in my app:

For reference, default_domain in the PR (for the Lotus Web library) is set to lotus, hence lotus.po.

4 comments

#debugging #gettext

1 302 4

2025-12-03 02:41:31 UTC

First 4 of 4 Posts

derek-zhou

Each of the libraries from the dependency is a OTP application with it’s own priv dir, and priv/gettext dir. So, I am not sure if you can achieve e your goal of “allowing users of the library to provide their own translations”. Translations are supposed to be faithful; so can you just accept the translation upstream?

Post #1

tugayac

Good point, hadn’t considered that , we do set otp_app to Lotus Web when using Gettext.

It sounds like the best course of action is just to include it as part of the library as you suggested I get the feeling we’re trying to use Gettext in a way it wasn’t intended right now.

We could use the dynamic translation features of Gettext, but I do want to keep the compile-time guarantees to avoid breaking translations.

Thanks @derek-zhou

Post #2

LostKobrakai

This is not as simple. Any of your users has lotus_web as a dependency. Their app won’t start compiling before lotus_web has been fully compiled. You could force a dependency cycle and start compiling parts of their app (gettext backend) before the rest of their app, which might be fine, but also depending on their setup could just as much not be fine at all. If you really want you could add a config to your application, which allows to switch out the folder, where .po files are located. That would allow users to change the translations without messing with the compile time ordering of elixir files.

Given the context I’d probably agree with the suggestion to keep the translations as part of the package though. I can see users wanting to have the UI localized, but less so the ask for customizing the localizations beyond what would be useful to all users.

Post #3

tugayac

@LostKobrakai I was referring to using the Gettext functions instead of macros when I said “dynamic translation features of Gettext” (i.e. this section of the Gettext docs), in which case the compile order shouldn’t matter (because translations should be fetched at runtime, but maybe I misunderstand how Gettext works?).

With Gettext macros, yes what you said makes sense

Given the context I’d probably agree with the suggestion to keep the translations as part of the package though. I can see users wanting to have the UI localized, but less so the ask for customizing the localizations beyond what would be useful to all users.

Yep, we decided to go that direction