Conversation
support@swissspidy : So the official WooCommerce PayPal gateway plugin uses a default ( en_US ) locale when a _formal locale is used because it wouldn’t be in the list of locales supported by PayPal (see https://github.com/woocommerce/woocommerce-gateway-paypal-express-checkout/blob/1ef80595138d580c41b2deefe6f6d597196e3757/includes/class-wc-gateway-ppec-settings.php#L24 and https://developer.paypal.com/docs/api/reference/locale-codes/#supported-locale-codes ). The reason for this is that PayPal only has a de_DE (which is formal). Some kind of locale mapping could be added to plugin code, but then one can argue this kind of “locale-resolution” would rather fit into WordPress Core. In the end, one may not actually want to have some locales automatically mapped to other ones. So as one possible solution your plugin comes in very handy: The user can already add locales in a preferred order using your plugin. Using the woocommerce_paypal_express_checkout_paypal_locale filter your plugin can easily use the next supported locale selected by the user. The only issue I see here is that _supported_locales is a protected property of WC_Gateway_PPEC_Settings class, so your plugin is not easily able to check whether the locale is actually supported by PayPal. There may be other ways in the future, but using something like your plugin to define an order preferred locales seems to be a very elegant and simple approach. The related issue on GitHub: https://github.com/woocommerce/woocommerce-gateway-paypal-express-checkout/issues/480#issuecomment-534773825 This topic was modified 6 years, 8 months ago by strarsis . This topic was modified 6 years, 8 months ago by strarsis . This topic was modified 6 years, 8 months ago by strarsis .
Thanks for raising this @strarsis . I do not want to have any plugin-specific functionality in the code base. Why? The goal is to eventually merge the Preferred Languages plugin into WordPress core itself. As such, it cannot contain code that deals with these kind of things. Also, this use case is not exactly what this plugin has been built for. I would strongly suggest the developers of that plugin to just remove the _formal suffix for de_DE to fix that issue.
Thanks for raising this @strarsis . I do not want to have any plugin-specific functionality in the code base. Why? The goal is to eventually merge the Preferred Languages plugin into WordPress core itself. As such, it cannot contain code that deals with these kind of things. Also, this use case is not exactly what this plugin has been built for. I would strongly suggest the developers of that plugin to just remove the _formal suffix for de_DE to fix that issue.