Allow properties of jsonable attributes of a model to be translatable

[multiwebinc]

I think this would be a good idea to allow properties of jsonable attributes to be translatable. This would allow you to translate specific sub-fields of a repeater to be translated. For example:

Model:

class Gallery extends Model
{
    public $implement = ['@RainLab.Translate.Behaviors.TranslatableModel'];

    protected $jsonable = ['images'];

    public $translatable = [
        'images.alt_text',
        'images.description',
    ];
}

Then in the yaml:

tabs:
    fields:
        images:
            type: repeater
            form:
                fields:
                    image:
                        label: Image
                        type: mediafinder
                        mode: image
                        imageHeight: 150
                        imageWidth: 250
                        span: left
                        required: true
                    alt_text:
                        span: right
                    description:
                         type: textarea
                         span: full

If someone could give me some direction on how to even get started, I might be able to get a PR for this.

[LukeTowers]

@bennothommo any thoughts?

[mjauvin]

If I remember correctly, the current architecture does not really make this possible... but I'd LOVE if this was implemented, it would solve so many problems for my use case.

[bennothommo]

I'd say it wouldn't be possible simply because of the lack of IDs in the JSON-able data - you'd essentially have to copy the entire JSON data over for each translation and link it to the main record.

In this scenario, it would be structurally better to use a related model with translatable fields.

[multiwebinc]

@bennothommo Another option I thought of would be to store the translations right in the JSON. Like having fieldName, then fieldName[en], fieldName[es], fieldName[fr], etc.

[bennothommo]

@multiwebinc that could work. We'd have to establish (in the docs, perhaps?) that the developer will need to account for this extra data if they go down this route, and use a larger data format column (like say a BIGTEXT column in their database), but it's certainly within the realm of possibility.

[mjauvin]

yeah, but the beauty of the Translate plugin is that if you disable it, the data is unchanged (all translations are stored in external tables)

…

-- Marc

On Sun., Jan. 30, 2022, 20:56 Ben Thomson, ***@***.***> wrote: @multiwebinc <https://github.com/multiwebinc> that could work. We'd have to establish (in the docs, perhaps?) that the developer will need to account for this extra data if they go down this route, and use a larger data format column (like say a BIGTEXT column in their database), but it's certainly within the realm of possibility. — Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPLTPURPM33XB6UIWIDYJ3UYXT47ANCNFSM5MZVWE7Q> . You are receiving this because you commented.Message ID: ***@***.***>

[multiwebinc]

@bennothommo Presumably for columns that contain JSON, people should be using the JSON type (i.e. $table->json() in their migrations). Assuming Laravel actually uses the JSON data type in the DB, this gives a limit of 1GB for MySQL and 255 MB for PostgreSQL. SQLite is around 1GB for TEXT or BLOB. So it's very unlikely these limits would ever be reached. Of course, it wouldn't hurt to add a note to the docs in case people use TEXT. What happens if the value exceeds the column limit? Is it truncated, or does the query fail?

@mjauvin Good point. I can't really think of a truly elegant way to get around that because of the lack of IDs, but perhaps when the translate plugin has been disabled and someone tries to write to a translatable JSON field, present a confirmation dialog saying something like "The field you are editing is translatable, but the Translate plugin has been disabled or removed. Making changes will remove any translated strings." Maybe also recommending creating a backup, re-enabling the plugin, removing the $translatable property of the model, etc. I would assume that most times people disable the plugin it's because they no longer want to use it, so the translation strings are generally not important anyway.

[mjauvin]

@multiwebinc if the plugin is disabled, you wouldn't be able to inform the user about this, unless you have some exception handling code in wintercms core

[multiwebinc]

@mjauvin Yeah, I was thinking of putting it in the core.

[multiwebinc]

@mjauvin Another idea that just occurred to me is to add something like a backend.plugin.afterRemove hook that will allow plugin developers to display a popup (or plain text message in the CLI) one single time after the plugin is deleted. This could be used to explain what happens to any residual data (such as translations) that are not deleted, any further steps that might be necessary, to display a discount message for people who might want to purchase a pro version of the plugin at a discounted rate, or to display a generic "We're sorry to see you go" type message.

[kubamarkiewicz]

I'd love to see this feature implemented, that would make using jsonable fields on multilingual websites possible.

[mjauvin]

@multiwebinc @kubamarkiewicz I would appreciate it if you guys could test PR #76