Using main table for default application locale

[bhenscamp]

Hi,
I would like to re open this old issue from dimsav/laravel-translatable#367

In my company we decided to integrate laravel-translatable, but in already existing model, so the best way for us was to keep default language in main table.

I forked laravel-translatable and made necessary changes to answer this issue.
Find here the branch https://github.com/bhenscamp/laravel-translatable/tree/develop
If ok, i'll make PR for it.

Feel free to report any suggestion

Thank you

[Gummibeer]

Hey,
thanks for reaching out. In short: I don't want this in this package.

Why:
Whichever key you use, fallback locale, dedicated locale or whatever: it's a config which can be changed - over time in project but also on runtime.
So in theory these "translations" aren't assigned to any locale but only picked as last option.
This column duplication is also against data normalisation which is one of the goals of this package, why we don't use JSON columns for example.
It's also easy to migrate - the moment you add this package to existing data just create thee new table, pick the existing data, copy it into the new table with the given locale and drop the old columns.
This is a simple single migration and it will prevent future problems.
And last but not least it's another complexity/condition that has to be maintained in the future - and exactly this complexity I try to reduce with the coming strategies #129 .

I'm sorry for rejecting it - but two data sources will never be a feature this package will support.

For history and if someone is interested how you've solved it here are thee two commits:

• bhenscamp@03ce816
• bhenscamp@7b04a10

But I highly recommend you to migrate your data instead of altering the package in it's fundamental logic.

[bhenscamp]

Hello,

Thank you very much to take time to answer me. I perfectly understand your point of view. We'll be thinking of them before final décision with my teammates.

find Below our concerns :

• Our website is mainly dedicated to one country, we add english for people who passing by.
• It's not so easy to migrate when you add translation on existing model, more over when it's not though as translatable (ok it's our fault :))
• Regarding performance we have some complex queries in Back office (only one language, the default), made with query builder, so with default language in base model, able us to not overcharge queries with another join.
• on all database translation model pattern I could study, about 50% keep main language in base model
• We have some tables that are lists like id | name (translatable), so it's non sense for us to have a table with only id.

Thank you again

[Gummibeer]

@bhenscamp if you haven't found already I want to link https://github.com/spatie/laravel-translatable .
They follow a different approach - JSON columns on the main model/table. By using MySQL 5.7 or even Postgres you will still have good query performance. Postgres with JSONB will come with JSON performance queries on steroids (indices on JSON subkeys).
Possibly this is an option for your case. But at the end you will have to decide and think about the different options.
I know the spatie guys and also this package pretty good and it's a solid option.