[Django 4.1+] Make i18n works for LANGUAGE_CODE with a country code

[rsebille]

Hello 👋,

When using a LANGUAGE_CODE with a country code and a supported language (ie: fr-FR) the current implementation of Select2Mixin.i18n_name will return None which means default select2 language, so English.

Not sure if testing against django.VERSION is the way to go but since the property already rely on Django code and that no one reported the current behavior, it seems a good enough way to target the versions with the fix than copying it.

[codingjoe]

Hi @rsebille,

Thank you for your contribution. It's much appreciated. Your patch looks pretty perfect. I'd just with to have a separate test, with a little docstring to avoid future regression. We try to keep the test suite more atomic going forward, and I'd appreciate if you could contribute to that trend as well :)

Best! Joe

[codecov]

Codecov Report

Patch coverage: 75.00% and project coverage change: -2.24 ⚠️

Comparison is base (c309742) 99.27% compared to head (c5dd7dc) 97.03%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #206      +/-   ##
==========================================
- Coverage   99.27%   97.03%   -2.24%     
==========================================
  Files           7        7              
  Lines         276      270       -6     
==========================================
- Hits          274      262      -12     
- Misses          2        8       +6     

Impacted Files	Coverage Δ
django_select2/forms.py	96.93% <75.00%> (-3.07%)	⬇️

... and 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[rsebille]

Hi,

While moving the new test cases into their own functions I saw TestSelect2Mixin.widget_cls and tried to use it, but it doesn't work well for TestHeavySelect2Mixin because of the required parameters (data_view or data_url) of HeavySelect2Widget() .
As it kind of bother me to have the exact same test cases executed multiple times because of the classes inheritance, which also give a false sense of security, I moved everything out and descended into the pytest rabbit hole as it seems easier than starting to touch every tests in the file :).

I looked to the last failed CI jobs but didn't succeed to reproduce in local nor found an obvious link between those and the proposed changes so hopefully it was some temporary hiccups on github side ;).