fix(module:datepicker): fix multiple CultureInfo properties

[anranruye]

🤔 This is a ...

• New feature
• Bug fix
• Site / documentation update
• Demo update
• Component style update
• Bundle size optimization
• Performance optimization
• Refactoring
• Code style optimization
• Test Case
• Branch merge
• Other (about what?)

🔗 Related issue link

fixes #1491

💡 Background and solution

#1480 add CultureInfo property to base input class, but there is already a CultureInfo property for DatePicker.

📝 Changelog

Language	Changelog
🇺🇸 English
🇨🇳 Chinese

☑️ Self Check before Merge

⚠️ Please check all items below before review. ⚠️

• Doc is updated/provided or not needed
• Demo is updated/provided or not needed
• Changelog is provided or not needed

[github-actions]

[codecov-commenter]

Codecov Report

Merging #1492 (70cba0d) into master (47e3e94) will not change coverage.
The diff coverage is 0.00%.

@@          Coverage Diff           @@
##           master   #1492   +/-   ##
======================================
  Coverage    0.00%   0.00%           
======================================
  Files         453     453           
  Lines       28499   28501    +2     
======================================
- Misses      28499   28501    +2     

Impacted Files	Coverage Δ
components/core/Base/AntInputComponentBase.cs	0.00% <0.00%> (ø)
components/date-picker/internal/DatePickerBase.cs	0.00% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 47e3e94...70cba0d. Read the comment docs.

[anddrzejb]

I think I made a mistake here and we should actually use LocaleProvider.CurrentLocale.CurrentCulture.

[anranruye]

My view is just the opposite. LocaleProvider.CurrentLocale.CurrentCulture is wrong. LocaleProvider.CurrentLocale.CurrentCulture returns the cultureInfo wrote in the json file. If the user set a culture("xx-xx") which has no corresponding json file, then _locale.CurrentCulture will fall back to en, but CultureInfo property is xx-xx.

I mean, actually CultureInfo property may be different from Locale.CurrentCulture. If LocaleProvider.CurrentLocale.CurrentCulture is right, then we should also do somethink like:

        public override CultureInfo CultureInfo
        {
            get
            {
                return base.CultureInfo;
            }
            set
            {
                _locale = LocaleProvider.GetLocale(value.Name).DatePicker;
                base.CultureInfo = _locale.CurrentCulture;
            }
        }

which is unreasonable.

[anddrzejb]

I think the problem we have here is that Locale is trying to do the same thing as CultureInfo plus some AntDesign specific stuff. I agree it is still needed, but possibly could be hidden behind CultureInfo and not really exposed to the user. Maybe as an option, through DI, for advanced scenarios. This way CultureInfo could be used as the only definition of culture/locale. Appropriate json would be retrieved based on CultureInfo to cover the AntDesign specific requirements. This way we could skip the double-data entry. Or allow json to "override" CultureInfo if necessary. I think there was an idea to "redo" the whole localization logic, but no one decided to tackle this problem, and this is indeed a problem as it will affect the whole library. @ElderJames what do you think?

[anddrzejb]

I am worried about this a bit. What if a consumer decides to use the same CultureInfo as the default but only changes some minor part, like CurrencySymbol? If I understand this correctly, new CultureInfo will not be picked up...

[anranruye]

I don't quite understand. To change some minor parts, the user can assign a new Locale instance to the Locale property, which will override the CultrueInfo settings. And, I think this is for DatePicker only, so why do you use CurrencySymbol as the example? And, if the user don't want to override the language of only a single component instance, he want to apply a global configuration, I think this should be done at the application startup stage, not at runtime.

[anddrzejb]

Clearly my example was not a perfect one, as obviously you are right - currency has nothing to do with date. And because DatePicker anyway will currently use Locale then whatever user chooses will not have any effect.

As I wrote in my previous comment, I think this separation into Locale & CultureInfo may not be the best choice. But I am not the one to decide here. I do think though a consumer of the lib should have ability to set a different locale for each component. But this could be also achieved by scoping services to a component if we are going to do this through DI.