-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove compile time depedency of Gettext backend module #330
Comments
This comment was marked as outdated.
This comment was marked as outdated.
Actually ignore my last comment. We’re not considering the usage of the translation / given bindings. We’re just optimizing the use case where all bindings were correctly supplied. |
One solution to the problem I can think of:
One problem with that is approach is that the event do not expose the raw arguments (only the arity). It seems like that could be adapted if we wanted to. I did a small POC some time ago that uses a compile tracer for extraction. (Unfortunately I can't locate it anymore.) With a few small changes to the compile tracing I was able to get it running. The reason why I'm thinking about that approach is how elixir handles recompilation: Given the following code, touching defmodule CompileTest do
IO.inspect "Compiling outer"
defmodule CompileTest.Inner do
IO.inspect "Compiling inner"
@external_resource Application.app_dir(:compile_test, "priv/test")
end
end This also applies if the modules are defined next to each other in the same file. |
Compilation tracers do not receive arguments. Plus the macro is important to enforce some properties about the translation. The only way I can think to solve this is to indeed decouple the backend that stores the translations from the front-end and somehow hide this dependency from Elixir - but it is not fully clear how to do so yet. |
Since it is brought up in #389 again, her's my latest thoughts / idea about the topic:
We could achieve this by changing how you get translations into a module. How it looks now: defmodule MyApp.Gettext do
use Gettext, ...
end
defmodule MyApp.Greeter do
import MyApp.Gettext
def say_hello, do: gettext("hello")
end What I propose: defmodule MyApp.Gettext do
use Gettext, ...
end
defmodule MyApp.Greeter do
use Gettext, backend: MyApp.Gettext
def say_hello, do: gettext("hello")
end The "traditional" way could be deprecated and still be supported for a while to make transition simpler. |
Yes, I like this direction! |
Would you send a PR or is this something you would like me to explore? We should update Phoenix generators too once a new version is out. |
In this way the module that uses Gettext (and imports translation funs) wouldn't need to be recompiled if the backend changes? |
Btw I also have bandwidth to work on this. |
This has been bugging me for a long time, so I'd be happy to provide a PR sometime (probably earliest sometime in september). But I'm also very happy to yield to @whatyouhide if you have time right now.
If we do it correctly: yes. Right now the backend provides macros for the translations (needed for the extraction). To use it, it has to be required at least, which will mean compile time depdendencies. Afterwards the backend would only have to provide functions instead of macros. the I have seen some places which used something like this: |
One nice little side effect of this change: It would potentially be feasible to do |
I will give this a try in the next few days and otherwise @maennchen you can pick it up later on 🙃 |
We only need to do this:
where:
and then make sure the backend is not used anywhere at compile-time, then we should be good to go. My only complaint is that
|
Forget about that. On another topic, a small suggestion you may already have in mind, instead of expecting users to type |
This is a Phoenix-generator-related thing though, but yeah good callout! |
Closed! Woohooo! |
Continued discussion of #317 (comment)
Removing the compile time dependency to the gettext backend module could speed up compile performance of larger apps considerably.
This has an even bigger impact when used together with
ex_cldr
which also recompiles if it is linked to the gettext backend. (Settinggettext
in configuration - https://hexdocs.pm/ex_cldr/1.6.4/readme.html#configuration)The text was updated successfully, but these errors were encountered: