Translating field labels does not invalidate cache

I can confirm that this is still an issue in Drupal 8.7.8, I'm facing this on user profile, so not views related.

Spend many hours trying to figure out correct cache to flush, but ended up to obviously bad practice of flushing all caches on form submit. Hopefully someone else finds proper solution for this.

as there is no way to know if the translated string is in a node or not so you don't have any other options besides clearing the whole cache. Clearing cache is a time consuming and resource intensive each time a string is translated, so i think this is a desired behavior

I had the same problem and clearing the Plugin-cache translated the field label.

Can we try clearing just the plugin cache?

Trying to clear plugin cache.

Updated patch will resolve test failures.

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

Did not test

Moving to NW for test cases

#29 doesn't work for me when translating taxonomy or node field labels. Technically clearing entity_field.manager cache should do the trick, however it does not unfortunately. Only the combination of clearing render, page cache along with the entity field manager work for me. Though I don't like this workaround, I'm using this as an interim solution for my projects until a proper fix is released.

I have got these in config_translation/src/Form/ConfigTranslationFormBase.php:

\Drupal::service('entity_field.manager')->clearCachedFieldDefinitions();
\Drupal::service('plugin.cache_clearer')->clearCachedDefinitions();
\Drupal::service('cache.render')->invalidateAll();
\Drupal::service('cache.dynamic_page_cache')->invalidateAll();

Attached a patch if anyone wants to use the workaround for now.

Was previously tagged for tests which still needs to happen. Not ready for review.

Fixed CCF in #33.

I got the slightly different results with the test case.
Cache was not invalidated with the services used in #33 or #36

I was able to make it work using following cache invalidation

        \Drupal::service('cache.dynamic_page_cache')->invalidateAll();
        \Drupal::service('cache.render')->invalidateAll();
        \Drupal::service('cache.discovery')->invalidateAll();
        \Drupal::service('cache.page')->invalidateAll();

I feel that invalidating the cache that way isn't a good idea.
Probably we should emit the cache tags related to field_instance config whenever title is visible and invalidate those cache tags.

I tried to do that, however, this wasn't working as expected. Tried using following approach:
- Added a dummy cache tag called "field_config" in view() method of FormatterBase.php class.
$elements['#cache']['tags'][] = 'field_config';

- Later in ConfigTranslationFormBase.php's submit() callback, I tried to invalidate cache tag along with discovery cache. See following snippet.

    Cache::invalidateTags(['field_config']);
    \Drupal::cache('discovery')->invalidate('entity_bundle_field_definitions:node:article:fr');

Since this isn't a generic approach, I haven't added that in the patch. Because all the configurations are not field config etc.
Probably someone more experienced with configuration api/translation API can chime in and throw other ideas.

Meanwhile, I've added a test-only patch so others can validate that when we do further work.
This is failing for me on local.

Keeping this in needs work since the discussion related to approach is required.

I ran into this, and was puzzled that only field labels from one language were getting used in rendered html in Solr. Turning on development mode with drush theme:dev on (new in Drush 13.6) which disables all caching (Drupal+Twig) and refreshing fixed it, and the correct, translated labels were shown, both under the content type, and in the rendered html in Solr.

I would say this is a pretty big deal, so maybe raising the Status level a notch could be considered?

PS. Something else I noticed: If you enter a new value in a Label field and press Enter, it does not save the form, even though there seems to be a page reload, and the value stays the new one. But if you revisit the form, the original value is still there. Perhaps there's an issue for this already, or we need to create one?