Thanks i will have to try and see how it goes.
wolfiton
kokolegorille
For the table, I would add a translation table, if You don’t want to embed translation…
create table(:posts) do
add :title, :string
add :content, :string
add :published, :boolean, default: false, null: false
timestamps()
end
create table(:posts_translations) do
add :post_id, references(:posts, on_delete: :delete_all)
add :language_id, references(:languages, on_delete: :nothing)
# Add fields You want to translate
add :title, :string
add :content, :string
timestamps()
end
This is more or less what globalize does.
3
wolfiton
Hmm interesting @kokolegorille but wouldn’t i have more joins to do this way?
Also i have more things that need to have a relations to an article(post):
category
tags
type
0
kokolegorille
Yes, one join to do, but only one, not many…
That is why embedding translation in a json field is a good alternative.
1
wolfiton
Got it the translations are required to be there just once when i select the language the content is displayed.
Thanks @kokolegorille for sharing this database diagram
0
OvermindDL1
I’ve generally seen both a side translation table and an embedded translation thing as crutches for fixing up originally broken designs. Designing the tables with the translation keys from the start is far superior as there is less joining, more efficient indexes, etc…
3
kokolegorille
wolfiton
So the diagram vision is speed vs data duplication?
Wouldn’t you just duplicate the languages_code in @OvermindDL1 database diagram suggestion?
0
OvermindDL1
If it doesn’t need to be translated then just have a default of a blank locale key. ^.^
But really, I’m curious what wouldn’t ever need to be translated?
I don’t see that there’s any duplication at all with my setup? Can you elaborate with an example I’m quite curious?
0
kokolegorille
I am not battling with @OvermindDL1, I respect his opinion a lot 
I just tell how it is done in Ruby, and coming from a multi-languages country (4) I had to solve this kind of problem.
0