I18n: get_locale calls involve much boilerplate code

[zinigor]

When calling get_locale Jetpack code often checks for existence of the GL_Locales class and requires the file if it's not defined. This code is used in several places and can be abstracted to make everything more DRY:

if ( !class_exists( 'GP_Locales' ) ) {
    if ( !defined( 'JETPACK__GLOTPRESS_LOCALES_PATH' ) || !file_exists( JETPACK__GLOTPRESS_LOCALES_PATH ) ) {
        return false;
    }
    require JETPACK__GLOTPRESS_LOCALES_PATH;
}

[stale]

This issue has been marked as stale. This happened because:

• It has been inactive in the past 6 months.
• It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.

[jeherve]

I think that is still very much an issue:

• JETPACK__GLOTPRESS_LOCALES_PATH now refers to jetpack_vendor/automattic/jetpack-compat/lib/locales.php.
• This file is the only file left in the Compat package, and the only reason for that package to stick around.
• We have references to JETPACK__GLOTPRESS_LOCALES_PATH and attempts to fetch a site locale that is compatible with WordPress.com all over the codebase.
• The mu-wpcom package includes its own way of getting a WordPress.com-compatible locale:

  jetpack/projects/packages/jetpack-mu-wpcom/src/common/index.php

  Lines 11 to 17 in a3e579b

  	/**
  	* Returns ISO 639 conforming locale string.
  	*
  	* @param string $language a language tag to be converted e.g. "en_US".
  	* @return string ISO 639 locale string e.g. "en"
  	*/
  	function get_iso_639_locale( $language ) {

• Folks are interested in getting something like that in JS as well ; see Blogging Prompt: preserve language on answers link #36730.

@zinigor @ice9js Do you think this could be a mini project for Garage? Maybe we could retire the Compat package, and have a proper common class and methods one can use to fetch a site locale, with an option to get a WordPress.com-compatible locale, and use that everywhere.
If we had that, we could pass that locale from PHP to JS here instead of creating a new JS utility.
We could also take that opportunity to update our copy of GP_Locales to include the changes that were added to GlotPress in the past 2 years.

The class and methods should be in a package that's available to the Jetpack plugin, to the mu-wpcom plugin, and others. I don't know if that's worth creating a new package though?