Works as expected, thanks!.
You Can add a item language = "Interface text language selected for page" filter to the views which will solve your issue.
The merge request updates the DaisyUI theme with new functionality:
- Added default styles for navigation, tabs, links, pagers, etc
- A subtheme generator which copies the subtheme into the root theme folder of custom theme folder
- Readme file with an explanation on how to generate the sub theme
- Some small changes here and there
mvdve → changed the visibility of the branch 3412176-improve-overal-functionality to active.
mvdve → changed the visibility of the branch 3412176-improve-overal-functionality to hidden.
Same issue here after upgrading to Drupal 10.0.1.6 from 9. Not sure what the purpose of the include helper method is so i replaced it with a simple include_once for now.
I replaced the commerce.current_locale service for the language_manager service because of the invalid locale codes.
In my case this was invoked:
elseif ($country = $this->currentCountry->getCountry()) {
// Assemble the locale using the resolved country. This can result
// in non-existent combinations such as 'en-RS', it's up to the locale
// consumers (e.g. the number format repository) to perform fallback.
$locale = $langcode . '-' . $country;
}
Which returns invalid codes as described in the comments. Maybe i am missing something but i think this service should only return valid codes or none at all. Using the commerce.current_locale would result in a lot of false negative results with the mapping to the Mollie locales. For example current country is NL, site locale is DE, this would result in de_NL which is invalid. The language_manager service will return the site locale DE which can be mapped to one of the DE Mollie locales.
I don't know if Drupal has functionality for country specific language versions, so de_DE and de_AT for example. I was lazy and picked one country of each language to keep the switch block short. I agree that it would be best to map against the complete locale code, but i don't have these in my Drupal sites. Just double character locale codes.
Yes that's correct, fr_US is not a valid locale code as French is not an official language of the US.
The second issue is that Mollie supports a selection of ISO 15897 codes, see locale in the docs and indeed, the locale variable is used to set the payment interface in the correct language.
Because of the selection of locales on Mollie's end, I mapped the available locales to the drupal interface locale and otherwise Mollie can do it's own thing, not the most generic method but it prevents the request error.
Updated the patch with the correct locale code within the test.