locale_language_save() introduced in #1215716: Introduce locale_language_save() clears the following caches:
// Kill the static cache in language_list().
drupal_static_reset('language_list');
// Changing the language settings impacts the interface.
cache_clear_all('*', 'cache_page', TRUE);
// Force JavaScript translation file re-creation for the modified language.
_locale_invalidate_js($language->language);
The last two are not desired in the API function and since we have not been able to find a good abstract place for these two to live in locale module, @catch asked me to open a separate issue to continue figure this out. Here it is.
Comments
Comment #1
catchBackground to this is issues like #757484: Optimize node_save() where we tried to decouple API CRUD functions from clearing the page and block caches (for example you might want to add 300 languages at once in an import, then clear the page cache once at the end).
The tricky bit here is the js invalidation, I'm not at all sure which category this falls into.
Also wondered why this is clearing the page cache rather than calling cache_clear_all() (no arguments) to affect cached HTML in the block cache.
Comment #2
gábor hojtsyWhat happens when a language is added or changed can be an intricate question. If I change the name or direction of my language, that would invalidate some page caches (all where this language was used or referenced by name) and some block caches (for language switcher blocks for example where the language is possibly referenced by name). If I only change the order of the languages or the default language, that might invalidate all page caches (it changes order of languages in the language switcher block and might change which language shows up under which URL depending on language negotiation settings). Or it might not change anything at all if I'm not showing a language switcher block and I have a negotiation configuration that uses data independent of the language order (such as session information, which is in itself might not be page cache compatible).
I think its safe to assume that most language changes / additions will need to clear page/block caches under the most common language negotiation configurations and that is probably the closest we have to define what/when is needed to be cleared.
Comment #3
gábor hojtsyTagging for base language system. Also retitling for changed function name.
Comment #4
gábor hojtsyIn fact language_save() will not do that update anymore now that locale (UI translation) and language is separated. The following functions do the cleanup in expectation that it changes pages likely with locale module there.
http://api.drupal.org/api/drupal/core--modules--locale--locale.module/fu...
http://api.drupal.org/api/drupal/core--modules--locale--locale.module/fu...
Moving to the UI translation subspace due to that.
Comment #17
smustgrave commentedBelieve this is no longer needed as language_save() has been removed https://www.drupal.org/node/2336669
If still a valid task though please reopen and update issue summary for D10
Thanks
Comment #18
berdirRe-opening this, the todo to this issue still exists in \Drupal\locale\Hook\LocaleHooks::configurableLanguageInsert() and \Drupal\locale\Hook\LocaleHooks::configurableLanguageUpdate(), the code is still there, it was just moved.
what we should at least do:
* switch to a render cache tag invalidation, much faster (on DB anyway) and covers all render caches. If we even need that. Because at least
* adding a new language should _not_ affect existing caches, except a few things that explicitly list languages like the language switcher?
* merge the two hooks together
* remove the todo if there's really nothing left to do
Comment #19
berdir