Refactor localization for not changing UF locale for each string

[jensschuppe]

This should drastically improve performance for localized remote event forms with many fields/many field options.

Testing should involve a requested locale different from the current default locale (i.e. CiviCRM running in English, requested locale being another language).

This makes use of some code copied from Core's ts() function to make it work with locales other than the current default one.

Since localization might get very slow, this should be cherry-picked for the 1.2.x branch as well.

systopia-reference: 25219

[TychoSchottelius]

Unfortunately, I can't help with the review, but I have carried out a test with the an environmental registration form and can confirm that the form now loads much faster.

[jensschuppe]

Unfortunately, I can't help with the review, but I have carried out a test with the an environmental registration form and can confirm that the form now loads much faster.

Exactly what we needed, thanks for that!

Let's wait for a code review though, as this copies some code from Core's ts() function.

[jensschuppe]

Noting that this approach might cause side effects when using native GetText, as in this case instantiating a new \CRM_Core_I18n object with a locale differing from the globally defined one causes \CRM_Core_I18n::setNativeGettextLocale() be called, which calls

// CRM-11833 Avoid LC_ALL because of LC_NUMERIC and potential DB error.
setlocale(LC_TIME, $locale);
setlocale(LC_MESSAGES, $locale);
setlocale(LC_CTYPE, $locale);

and does not reset afterwards, so within the same request the latest processed locale gets stuck for concurrent translations.

With the PhpGetText this is capsuled in the \CRM_Core_I18n object and should do no harm.

[jensschuppe]

Also, when using a customTranslateFunction setting, this will always translate to the configured locale instead of the requested one, as those functions do not take a specific parameter for the target locale.

[jensschuppe]

Actually, calling \CRM_Core_I18n::setLocale() would still be the correct thing to do, but only once for each CiviRemote Event request instead of for each string …