luyadev / luya-module-admin

Administration base module for all LUYA admin modules
https://luya.io
MIT License
48 stars 56 forks source link

Convert field values when toggling i18n mode #13

Open luya-bot opened 6 years ago

luya-bot commented 6 years ago

This issue has originally been reported by @rolandschaub at https://github.com/luyadev/luya/issues/1328. Moved here by @nadar.


What steps will reproduce the problem?

When turning i18n mode on or off for a field, already existing values are lost.

What is the expected result?

The values should be converted to new format (using default language values as default).

denyadzi commented 5 years ago

Hi, @nadar . I also faced this issue and looking forward fixing it. But calling for your advice.

At first sight this can be fixed by letting I18n::decode to do the thing (assign the scalar passed to it to array with the current language as the key). Can there be any traps in such aproach?

The second approach I think of is to throw an exception from I18n::decode when the value failed to Json::decode. This would narrow its responsibility to just decoding. And creating the right i18n-value may be done with the separate function in the I18n class. All the code using I18n::decode then should try - catch and may use that new function to obtain the right i18n value. With such approach the following would fail $this->assertSame(I18n::decode('{"en": "", "de": ""}'), I18n::decode('scalarValue'))

UPDATE: actually, both of them aim to fail that assertion. Currently it passes

nadar commented 5 years ago

hi @denyadzi thanks for taking time to think about solutions, in the original issue i mentioned to create a command you can run to fix those values in database (https://github.com/luyadev/luya/issues/1328#issuecomment-349353563). This is what you are trying to achieve?

Because i think it would be easy to have command you can run to encode/decode i18n fields - maybe also fix not existing language keys/changed language keys.

what do you think?

maybe sth. like this:

./vendor/bin/luya admin/language-converter/to-json my_table_name column_name

and the opposite case:

./vendor/bin/luya admin/language-converter/from-json my_table_name column_name

cause i think this is something which should be done by a command, as its also a very dangerous task you might lose all the data if something went wrong. Maybe this should also generate a csv into the runtime folder with the old table values.