[META] Modernize Locale module

Batches could use #2875279: Update core modules to use the new batch builder

Fantastic collection. Locale has a lot of history ;) I think chipping away at this in manageable pieces is the best strategy. Hopefully we have enough existing test coverage to ensure refactored things still work. Also we need to identify in each case which parts are "API" and therefore need a full-on @deprecated/@trigger_error treatment. Hopefully most are not.

Reparenting constants to this one, since its parent has been fixed for a while.

#2927222: Move cache invalidation to event out of TranslateEditForm::submitForm() has been clarified. I removed this issue as it's parent, but maybe it is still related. No clear cut lines here :D

Moving to 9.4/10

Used to check old issues and found great schema #1189184-200: OOP & PSR-0-ify gettext .po file parsing and generation

Author is Gábor Hojtsy)

While reviewing #3586472: locale_string_is_safe fails on valid safe html I noted that Drupal\Tests\locale\Kernel\LocaleStringIsSafeTest::testLocaleStringIsSafe() can be converted to a Unit test when locale_string_is_safe() is moved from the .module file into a class. I assume it isn't already a Unit test because of the global procedural function calls.

I just checked how many search results there are for each function. I think some of the hook related ones should be grouped:

locale_translatable_language_list 14 results
locale_get_plural 8 results
locale_system_set_config_langcodes 2 results, only tests already replaced

locale_system_update 3 results can move to LocaleHooks protected maybe
locale_system_remove 2 results can move to LocaleHooks protected maybe
locale_js_translate 1 results can move to LocaleHooks protected maybe
locale_form_language_admin_add_form_alter_submit 2 results can move to LocaleHooks
locale_form_language_admin_edit_form_alter_submit 1 result can move to LocaleHooks
locale_system_file_system_settings_submit 0 results already deprecated
locale_translation_status_delete_languages 1 result can move to LocaleHooks

locale_is_translatable 8 results
locale_translation_get_file_history 12 results
locale_translation_update_file_history 3 results
locale_translation_file_history_delete 2 results
locale_translation_get_status 26 results
locale_translation_status_save 5 results
locale_translation_status_delete_projects 2 results only deletes keyvalue
locale_translation_clear_status 3 results only deletes keyvalue and state
locale_translation_use_remote_source 6 results only checks config
locale_string_is_safe 11 results
_locale_refresh_translations 3 results
_locale_refresh_configuration 1 result inline in TranslateEditForm
_locale_strip_quotes 5 results
_locale_parse_js_file 6 results
_locale_invalidate_js 5 results
_locale_rebuild_js 4 results
locale_translation_language_table 1 result inline in TranslationStatusForm

Replying here, re #2660338: Deprecate locale_get_plural and #42:

I think it might be better to focus on locale_get_plural() there. That's a non-trivial case that goes outside of locale module. not sure if that needs to remain postponed, I don't think it directly conflicts with the others too much, but it's been helpful to focus on those issues one-by-one.

Agreed on grouping a bunch of functions that we move to protected methods on the hook service, the system ones and possibly also JS. Plus, several underscored helpers are called through locale_js_translate() that could go in there as well.

Maybe one other issue for everything form related. note: locale_translation_language_table is a callback, agree it can be a static method on the form, not "inline" though. _locale_refresh_configuration() unsure, while that one is only called from the form, it's right next do _locale_refresh_translations(), which has 2 additional calls, might make sense to keep them together.

The leftovers are then I think one or multiple utility service(s), we can split depending on their dependencies for example. locale_translatable_language_list() and locale_is_translatable() are clearly related, locale_translation_use_remote_source() kind of. locale_string_is_safe() and then there's not too much left.

Yes after doing the review of usages I think you're right I'll update the plural issue in a bit.