Eiji
Hi, I’m working on DSL and the last thing that I don’t like is how I’m extracting translations.
I have 2 version of code:
-
My current implementation is based on
Gettext.Extractorprivate API - it’s working without any issues -
An alternative is to use
Gettext.Macros.dpgettext_noop_with_backend/4. It’s also a solution which works very well, but unfortunately it does not allow function generators (other macros,forloops etc.) asGettextmacros requires binary literals.
defmodule MyApp.Example do
use MyLib.DSL, gettext_backend: MyApp.GettextBackend
for data <- ~w[first second third] do
some_dsl data
end
end
I understand that private API is unstable and can be changed at any time, but I have simply no idea about other possible solutions. From now on I can see only 2 ways to fix it:
-
Propose to make
Gettext.Extractora public API - that’s the simplest thing that could be done as it’s only about documenting code i.e. no change in code. -
Propose to support non-literals, so internal
Gettext.Extractorcalls are done withinquote do … endblock instead of directly inside macros.
Both solutions are rather something you consider at the very end. Support for gettext is only optional, so I don’t want to resign from function generators. The whole logic is done only in compile-time, so the generated code is as fast as possible in runtime.
With all above in mind I’m not satisfied in both implementations and I have no idea what to do with that. Did you had a similar problems with gettext when working on DSL? What do you think about making Gettext.Extractor public? Is there any other way to extract translations without above problems?
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
I’d love if
Gettext.Extractorcould become public api. I had asked for that a few months back on a more esoteric usecase and given the usecase the response was negative. This sounds more in line with the libraries goals. But I wonder why you cannot provide binary literals if you’re in a macro context.Eiji
Glad to hear that not only me is looking for this.
This is about said
dataargument insome_dslmacro, see:LostKobrakai
Ah, yeah. You’d cannot work with variables, you need to know the actual strings in your macro.
maennchen
I believe you should be able to use the exposed public APIs in Macros since you can just unquote the variable containing the string.
See Gettext.Macros — gettext v1.0.2
Eiji
I have mentioned it as alternative way in 2nd point and why it’s not an option for me. For now I’m investigating
expoas generatingpotfile sounds like an interesting alternative to current solutions.maennchen
Generally when using macros, you should have access to the literal and not just the variable. Can you share a simplified version of your DSL that shows the issue?
It’s the intention of gettext that this works. If it does not, we’ll need to have a closer look.
Adzz
I’m not sure I fully understand your use case but in a project I work on we extract translations from the .POT file. Seems to work fine, we hand rolled a parser of those files but I think
Expo.PO.parse_file!("priv/gettext/default.pot")probably works fineEiji
Here you go:
Eiji
Wrong way. I think now about generating
.potfile at compile time and then callmix gettext.merge priv/gettext --locale locale. It’s nothing related to parsing.potfile. Sorry if my post was not clear enough.Eiji
Generating a
.potfile usingexpois definitely the best solution. I have a full control over code, I don’t need to worry about private APIs and it’s also a very simple thing to do.