Translate only SW6 entity content with value in main language

[mjosef89]

As noted in #47, it is currently not possible to only consider content for entities that have a value in the standard language.

For example, if an article does not have a meta description in the main language, this should neither be considered as missing during validation nor during translation.

This PR contains a first rough approach on how to solve this in the context of Shopware6-Storage without adapting the basic logic of the framework.

Is there any interest in extending the existing storage accordingly, or would it be better to create a separate storage service for this purpose?

[boxblinkracer]

Hi there

thanks again for this
so I tried it (because I didnt really understand the code from the namings to be honest), unfortunately i got some errors like this, so products didnt work anymore

Warning: Undefined array key "product_id" in /src/Bundles/Storage/Shopware6/Service/TranslationLoader.php on line 141

but nevertheless, i think i like the feature
so to say it with my words (please confirm)

The validation (and other processes) of Shopware should only consider fields that are existing and filled in the Shopware default language. This helps merchants and agencies to only focus on the fields that are really in use.
This is an optional feature that limits the fields that are considered

is that right?
if so, isnt that only the filter-feature that does already exist, but with some kind of automatic detection instead of having it in the xml configuration?

[mjosef89]

Hi,

so I tried it (because I didnt really understand the code from the namings to be honest)

I'm not really happy with the naming myself, but I haven't come up with anything better yet

unfortunately i got some errors like this, so products didnt work anymore
Warning: Undefined array key "product_id" in /src/Bundles/Storage/Shopware6/Service/TranslationLoader.php on line 141

Unfortunately I was unable to reproduce this, but I think i found the bug anyway it should now be fixed.
Please make sure that the value of the attribute "mainLocale" in the phpunuhi.xml set has a valid shopware locale, so for example:

<shopware6 entity="product" mainLocale="de-DE"/>

The validation (and other processes) of Shopware should only consider fields that are existing and filled in the Shopware default language. This helps merchants and agencies to only focus on the fields that are really in use.
This is an optional feature that limits the fields that are considered

Exactly. Perhaps an addition: It does not specifically limit the fields, but ensures only consider fields that are existing and filled in the Shopware default language PER PRODUCT.

For example in a Shopware Shop with the default language german

Product A has a name, description, and a meta-title filled in german.
and
Product B has only a name filled in german.

For Product A the fields "name", "description" and "meta-title" are considered/translated for all other languages.
For Product B only the field "name" is considered/translated for all other languages.

This is important for us as we get the german texts from an external leading system, and it's okay for us if a product has no description. Without this customization, however, this would be reported on every execution/validation.

The only important thing for us is that the existing german (default language) texts for entities are translated into all other languages.

if so, isnt that only the filter-feature that does already exist, but with some kind of automatic detection instead of having it in the xml configuration?

The key difference is that the filters apply to the whole set, while my solution works dynamically per product/entity.

For example if I exclude (filter) "description" it will be excluded for every product. But I want to exclude it only for products where it has no value in the shop default language. For this reason it can not be static.

However, the filter logic is of course still useful to exclude something like custom_fields if you never want to translate it.

I hope that was somewhat understandable

[boxblinkracer]

Hi there
ok this makes absolutely sense

i like the feature, although not everyones case, but a valid case

ill give it another shot and then well figure out a good naming :)
but the idea is great thanks for this

[boxblinkracer]

Hi

so the main branch now has an option to provide base=true for a locale
i need this for another feature any

so what is left now, at least with the naming is to create a config to use that dynamic approach
i thought maybe an attribute properties="dynamic|all“ something like this maybe?

[mjosef89]

Hi,

sorry for the late reply, I've been quite busy.

so the main branch now has an option to provide base=true for a locale
i need this for another feature any

so what is left now, at least with the naming is to create a config to use that dynamic approach
i thought maybe an attribute properties="dynamic|all“ something like this maybe?

The attribute property mainLocale I used previously had two functions

• Defining the shopware locale that should be used as source language
• Activate that the translation is only based on the source language

As far as I understand it, the first point should now be represented by the base option.
And you want another property like dynamic|all for the latter?

That's fine with me

However, my solution had previously assumed that mainLocale contains the locale specification that is also used by Shopware. So for example de-DE instead of DE.

If, on the other hand, we assume that we always want to use the source language that is also defined as the main language in the SW instance, we could also use the fixed UUID directly (https://github.com/shopware/shopware/blob/ddb5890daa96a0370db878bf3ec29da647018e49/src/Core/Defaults.php#L17).

However, this of course makes it less flexible and would decouple it from the configuration.