Open zinigor opened 9 years ago
This issue has been marked as stale. This happened because:
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.
I think that is still very much an issue:
JETPACK__GLOTPRESS_LOCALES_PATH
now refers to jetpack_vendor/automattic/jetpack-compat/lib/locales.php
.JETPACK__GLOTPRESS_LOCALES_PATH
and attempts to fetch a site locale that is compatible with WordPress.com all over the codebase.@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?
When calling
get_locale
Jetpack code often checks for existence of theGL_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: