Translate-plugin: Changing the default language will cause existing translations to break

[iSaadSalman]

I have setuped by custom plugin using translate plugin and information was entered for both languages. But once I switch the default language from English to Arabic the arabic word are in english and there are no words for english

[Minius-dev]

Yes, its bug i think. In my websites to. I cant change default language later.
I can say, that octobercms it`s very nice system, but there is a problem with translations in some cases... and it would be nice to get some updates from the team

[pbsmultimedia]

+1

[LukeTowers]

Closing as it has been over a month since any activity on this occurred.

[joelamltc]

I used this plugin to get my website to be i18n ready and I love this plugin. However, this is always holding me back.

The situation is I have had created two languages in the backend Chinese and English (default). I saved the translated attributes in the form view. All are working fine but once I switch the default language in the backend config and come back into the form view. I noticed all things gone wrong. All chinese translated attributes became english and english translated attributes are gone.

OctoberCMS build 437
Translate Plugin 1.4.0

[LukeTowers]

@munxar @vannut Are you guys able to see what causes this issue of translations breaking when the default language for a site is changed?

[munxar]

@LukeTowers tl;dr it works as implemented.
I'll try to explain why:
If you use the ModelTranslation behavior it is applied to a model that is related to a database table.
The values stored in this table are assumed to be in default language.
If you add a translatable column via $translatable = [] and only have the default language, basically nothing happens in the rainlab_translate_attributes or rainlab_tranlsate_indexes (translation tables) tables (because the data is in the table itself).
If you add another language as non default and write a translatable value to this model, it will store the data in the translation tables.
If you switch now default language, the data still in the models database tables is now default.
Because there where no entries for the former default language the translations are now missing. there still in the db because if you switch everything back, it works like expected.

long story short, here are two solution that come to my mind:

a) choose your default language before entring data

b) if you have to switch, write a migration script that flips model <-> translated data for this to languages (could be a optional feature in the translate plugin)

c) export your translation data BEFORE switching default, switch default, import data.

hope this is clear, so no real bug, just the normal behavior with model translation.

[joelamltc]

Would it be good if store all translation in the rainlab_translate_attributes table?
Then no matter how you switch it will still can grab the right translations.

[munxar]

@joelamltc it depends on your definition of 'good' :-)
well, I think no, because the plugin is build in a way that you can just add or remove it as pleased.
it doesn't alter data in this process, which is a good thing.
Imho we should instead add a feature to copy translation data from one locale to another.
that would be:
a) optional / non destructive
b) solve the original problem (with a little hand work, but I think its fair because switching the default locale is not something you usually do in a productive environment, do you?!)

[joelamltc]

yea I totally understand.

for b) in production server no, but sometime in development will do. Coz sometimes the client didn't know what language they should default, and I just always default to en, but somehow they want to change it to others. Then, it would be my problems if can't switch or maybe just like you said, do some little handy work to migrate it.

[LukeTowers]

@munxar what do you think about triggering the copying of default lang attributes (i.e. the language swap) when changing the default locale?

[munxar]

@LukeTowers wouldn't do that. Why?

1. We don' t know the side effects of a model save, or what hocks are triggered.
   In the worst case data is lost. You wouldn't expect a data modification by switching the default language, would you?

1. What will happen, if the new default language doesn't have a value, but the db requires one?
   The translated fields don't have have any validation rules or schema. An exchange is not always possible.

[LukeTowers]

Fair enough. How about as a console command instead then?

[munxar]

@LukeTowers I'll try to be more clear:
It's very hard to do, because we need to

1. know all translated model classes
2. iterate over their data and write it as normal translations into the translation tables
3. get the data from the translation tables and write them into the tables (as default)

I have no clue how to solve point 1. point 2. is relatively easy and 3. is technically impossible.

Let's make an example, default language is en and a second language de (german), and we have a table foo_bar_items schema like this:

| id | name |
| --- | --- |
| 1 | hello |
| 2 | world |

our rainlab_translate_attributes table is empty:

| id | locale | model_id | model_type | attribute_data |
| --- | --- | --- | --- | --- |

let's translate the name of the record with id 1 to de (german):

| id | locale | model_id | model_type | attribute_data |
| --- | --- | --- | --- | --- |
| 1 | de | 1 | Foo\Bar\Models\Item | { "name": "hallo" } |

Now let's decide that our default language is german de instead of english en:
But how should we copy the data? Let's be naive and iterate over the rainlab_translate_attributes table and swap the data:

| id | name |
| --- | --- |
| 1 | hallo |
| 2 | world |

| id | locale | model_id | model_type | attribute_data |
| --- | --- | --- | --- | --- |
| 1 | en | 1 | Foo\Bar\Models\Item | { "name": "hello" } |

The translate table contains correct data, but our items table has now languages mixed up which doesn't make sense.
Another question is: What if there is a model without any translations made yet? how do we know about it and fill the rainlab_translate_attributes table?

[LukeTowers]

@munxar you're right, this is technically very difficult to pull off. Could you recommend an addition to the documentation that would warn developers to not go around changing the default language for these reasons?

[mjauvin]

Maybe we could add a confirmation popup when changing the default locale, warning people about this?

[CptMeatball]

So basically there is no solution for this problem (yet)?

A dirty fix would be the make it a part of the front-end component, but that would "break" a site when removing the plugin. It would change languages unexpectedly

@LukeTowers: Warning developers not changing the default language is one step. But developers aren't always in the possibility to make this choice. If the client wants to change the base language and the website is relatively large, nobody's gonna be happy 🤔

@munxar: Regarding your second issue. When a model isn't translated yet to the new language, is should be no issue to duplicate it without changing the actual model data. Say "EN" is my default and I want to switch to "DE", but I haven't translated it yet. It should copy the "EN" to the translations table and let the model data unchanged.

[joelamltc]

Or maybe we can actually consider make translate plugin as part of OctoberCMS, make it translate ready. When user / developer want it, it already there, otherwise, just let it rest inside OctoberCMS when it is not needed.

I am not recommending something, just pure discussion.

[bennothommo]

@joelamltc The Translate plugin is a RainLab plugin, which means it is maintained by the core developers and should be treated as "core" functionality, but it won't be merged into the October CMS core as it really is supposed to be an optional augmentation to an October CMS site. A lot of people only work with one language, and have no need for translations.

[mjauvin]

@daftspunk did you figure out a way to address this?

[zakir1929]

public function boot(){
    if(!$this->app->runningInBackend()) {
        $translator = \RainLab\Translate\Classes\Translator::instance();
        if(!\Session::get(\RainLab\Translate\Classes\Translator::SESSION_LOCALE)){
            $translator->setLocale('en',TRUE);
        }
    }
}

I have to change the default language for front-end only so I have written that code in Plugin.php boot method and it works perfectly !!!

[foxik0169]

Hello,

I think the problem can be solved just by adding one more setting which will be the 'default' frontend language. Similarly to what @zakir1929 did, just as a setting. In the backend, the translations would still work as now (one language is default, and translations are stored in separate table).

Also I think this is a naming problem, cause the 'default' now means two things:

1. Default in the frontend - actually Default language?
2. Language of the non-translated stored content - something more like Source language?

I understand that this might not be totally user-friendly but I guess for developers it makes sense?..

Daniel

[TomeuMut]

Hi, The answer switch locale in BD isn't work for me, someone get different answer for this bug?

[mjauvin]

@TomeuMut did you try what was suggested here:
https://github.com/rainlab/translate-plugin/issues/231#issuecomment-658899574

[TomeuMut]

@mjauvin Yes, but not working... One Idea I think is in folder plugin create a file routes.php and save the values the model in BD and then change de lang...

[TomeuMut]

Hi, I found one solution for this problem, I create two functions.

function saveLang($page){
        /*
        * For Steps, Step 1
        * Get lang Values and get aux lang
        * And Set default lang to aux
        */

        $page->translateContext('ca');
        $attributesCa = $page->toArray();

        $page->translateContext('es');
        $attributesEs = $page->toArray();

        $page->translateContext('en');
        $attributesEn = $page->toArray();
        $page->update($attributesEn)
    }

    function changeLang($page){
        /*
         * Step 3, Set Values in fields lang.
         */
        $page->translateContext('en');
        $attributesEn = $page->toArray();

        $page->translateContext('ca');
        $attributesCa = $page->toArray();

        $page->update($attributesEn);

        $attributesCaUpdated = $page->toArray();

        $page->translateContext('es');
        $attributesEs = $page->toArray();

        $page->update($attributesCa);
        $attributesEs = $page->toArray();
    }

The Step 2 is change default lang manual because make default lang not work with code... and I use the EN for lang aux.

This is a litlle Patch but is something.

[tombien]

We found problem in Static Pages. We have EN and FR languages for example. FR is default. Static Pages makes themes/my-theme/content/static-pages and themes/my-theme/content/static-pages-en. If you switch default language from FR to EN, site is going to break, because folders did not renamed so you have folder with french for default (EN) language and for french you have nothing.
And Static Menus also does not work correct.

This problem is not same as in comments before, but I think switching default language seams to be global problem.

[bennothommo]

@tombien Would you mind creating a separate ticket for this issue, as I believe yours might be a Pages plugin issue instead?