@belaustegui: I think lots about it today, but still don’t have a one good way. I read some articles about it today and there are lots of pros and cons for all cases (also for not using jsonb). I will think more about it in other time, but I will probably have more propositions for your API.
Eiji
1
brightball
I like the approach but it might be worth it to create a trans_LANGUAGE column. Committing to multiple languages on a site isn’t a small task and this would separate each translation out into it’s own column.
You’d get a couple of benefits from that approach.
First, with updates. Variable sized columns that can store blobs have to worry about space reallocation on updates which can stress the database a good bit as it grows, especially with any significant update frequency. By having a column-per-language you’ll end up with multiple smaller fields that update less frequently on their own.
Second, if you know the translation that you want to get back, you can request it in the select rather than the entire JSONB for every language. If there are multiple fields for the variation, you’ll be able to easily query the whole set of translations on that row for that language with one field, rather than having to separate it out of the JSONB. It will also speed up parsing the JSONB by keeping the size consistent.
1
belaustegui
I’ve published an article explaining the main changes, improvements and future plans for Trans.
If you want to have a taste of the improvements in Trans 2.0 you should read it!
2
Eiji
@belaustegui: I don’t have so much time, but I simply looked on that article and one point is interesting:
Make translations an embedded schema and create a custom Ecto type.
I was think about it too, especially a configuration that allows to use it like embedded schema or normal association. I think about something like that, because looking for lots of answers, articles and comments I don’t find a clear answer about what is the best way. This is related with data size and what database functions developer would like to use. For simplest scenarios a jsonb is recommend, but it’s not so simply in bigger and/or special projects. I don’t want to copy and paste too much, but I just want to point that it’s not easy to determine best strategy and if someone is going to share a code then I think that it should be as much configurable as possible. What do you think about it?
1
OvermindDL1
belaustegui
This is has currently an idea status only, I have to think about it deeper.
On the one side it will require more work to set up translations, since users should create embedded schemas and specify which data they should contain. On the other side it would make translations safer by letting us specify valid fields, changesets, etc.
Since this would be a big change for Trans, it requires more though and analysis. Some other issues should be fixed before addressing this.
I agree with you that it is not easy to determine the best strategy for content translation management. Currently there are different approaches provided by different libraries than trans such as ecto translate or translecto.
I also think that a library should have a single and clear concern. Users can then choose which approach fits best for their needs and pick the right library for it.
0
belaustegui
!
Eiji
Mostly agree except that situations where 2 libraries could have ~90% of code same. I think in that cases developers prefer configuration over library count and finally if you will implement your plan then it’s easy way to make a configuration for my suggestion, but otherwise not - 2nd library will be better.
0
belaustegui
Hi again! We got a new version of Trans!! 
The version 2.0.1 is a minor release which contains the following main changes:
- Fixed some issues with documentation examples.
- Use Ebert to check code quality.
- Relax the dependency restrictions on
Poison.
You can see the release notes on GitHub.
As usual, any comments, suggestions, issues or pull-requests are more than welcome!
Love 
2
beno
This may be more of a ecto/macro mystery that Trans-specific, but how can I compose queries with the ‘translated’ macro? I am trying to find combinations of translations and have tried the following, which won’t compile:
def find_option(values, locale) do
query = values
|> Enum.reduce(Option, fn {f, val}, query ->
from o in query, where: translated(Option, field(o, ^f), locale) == ^val
end)
# do query...
end
# => find_option(%{name: "NAME", category: "CATEGORY"}, :nl)
gives
** (Ecto.Query.CompileError) `field(field(o, ^f), :translations)` is not a valid query expression.
So the idea is to find Options (having two translated fields) with the same combinations of translated values. I admittedly can have a hard time getting my head around macros and ecto in particular, but how does one do this?
0