Improve WPML compatibility for XLIFF-based features

mbmjertan commented 2 years ago

Describe your feature request

WPML has certain features such as their Advanced Translation Editor, automatic translations and third-party translation service integrations which depend on it extracting content into XLIFF files which are then sent for processing to OnTheGoSystems or third parties.

As you can imagine, WPML has trouble with extracting content from Eightshift blocks. During discussions with WPML about improving our compatibility with these features, they referred me to a chapter in their documentation on language configuration files about the ability to provide configuration for translation of block attributes

This looks like it could solve our issues with WPML compatibility and improve our editors' UX, but we should research what is the best way to do this with Eightshift.

Describe the solution you'd like

I'm not sure at this point what would be the best solution.

Ideally, we'd find a way to automatically generate WPML language configuration files by adding a translatable key to block/component manifests. However, I'm not sure that'll be possible due to component composition, or performant. I might be mistaken, though: I haven't done too much exploration on this.

Otherwise, I think that we could add WPML support in two ways:

add WPML config files to projects manually, writing down translatable attributes for all blocks (sounds like a chore)
add a WPML config file to projects, listing all blocks there (we could do that automatically) with a regular expression so that all ...Content attributes are translateable by default.

Please let me know your opinions on this.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in this repo.

No

Please confirm that you have searched in our documentation and couldn't find the answer.

No

dingo-d commented 2 years ago

I tried playing locally with the XML config file, butcouldn't get it to work no matter what I tried.

For instance, I tried globally setting

<wpml-config>

    <gutenberg-blocks>
        <gutenberg-block type="eightshift-boilerplate" translate="1">
            <key name="*Content" />
        </gutenberg-block>
    </gutenberg-blocks>

</wpml-config>

and for the paragraph only

<wpml-config>

    <gutenberg-blocks>
        <gutenberg-block type="eightshift-boilerplate/paragraph" translate="1">
            <key name="*Content" />
        </gutenberg-block>
    </gutenberg-blocks>

</wpml-config>

But neither of those helped to show the attribute in the advanced translation editor or the exported XLIFF files.

We could add a 'translatable' key in the manifest for every attribute we'd like to be translatable (like you mention), and then parse the manifest to create some sort of config file (which would be cached - we could check the md5 of the file to check if the file was changed so that we can update it later on during the build process I guess).

The problem is, that I didn't find any public API that can be used so that the attributes are correctly passed to the Advanced Translation Editor.

I'm either missing something, or they didn't provide this at all.

mbmjertan commented 2 years ago

Interestingly enough, it works if I add this (for example, it might work with more precisely defined key names as well) in WPML -> Settings in wp-admin, but not if I add it to the wpml-config.xml file:

<wpml-config>
    <gutenberg-blocks>
        <gutenberg-block type="eightshift-boilerplate/card" translate="1">
            <key name="*" />
        </gutenberg-block>
    </gutenberg-blocks>
</wpml-config>

Screenshot 2022-09-26 at 17 10 42

It might be that the file doesn't get parsed often, but is cached somewhere, and that our initial testing with files didn't account for that.

infinum / eightshift-frontend-libs