Computed fields and not translatable fields from paragraphs are being translated

Thanks for the patch...

I cleaned it up to only have the inteded changes..

you got a lot of redirects in there too...

Agg, thanks @spuky, what a mistake!

fixed corrupted patch from #3

The last submitted patch, 6: 3382356-do-not-translate-computed-fields-nor-untranslatable-paragraph-fields-6.patch, failed testing. View results →

this change logically makes sense to me - exclude fields with no storage, exclude computed fields. Per the failed test https://www.drupal.org/pift-ci-job/2816543 → , it looks like some of the automated tests may need to be updated for this change.

We just wondered why untranslatable paragraphs fields suddenly had translated values. In our case it was a field to set custom classes on the paragraph (mb-none) and after tmgmt translation by a user, the class was suddenly "mb-keine" (German).

Setting priority to Major. The patch LGTM, but I think it needs a tmgmt maintainer to take a look to ensure the logic is correct!

We encounter the same issue where untranslatable paragraph fields, such as a field for classes (e.g., m-auto being translated to m-car), are being translated. We use a paragraph called "Settings," which includes several fields for enhancing a parent paragraph by adding classes or animations. This "Settings" paragraph is linked to all other paragraphs via an Entity Reference Revisions field and does not require translation.

The content translation is disabled for the "Settings" paragraph, but this causes it to not function as expected: the fields are being translated. When we enable content translation, the untranslatable fields are no longer translated, and everything works. While this solution works for now, it feels like an unintended workaround rather than the expected behavior.

Stomping into a similar issue (non-translatable field from a paragraph being translated), I'm wondering if the best approach wouldn't simply to apply a filter from the most specific to the less specific granularity.

Regarding computed fields, aren't they available in the translation UI? Then it should be a matter of configuration, rather than hard-coding a specific use case?

I'm posting a patch for reference and RTBC. Haven't had time to test it myself, or even to use it. We just configured our bundle as translatable in my project, so it would pass the code logic and our field got removed from the job item.