Open jcfr opened 5 months ago
Furthermore, the updateLanguageItems() function is updated to select the default locale code if the user has not already made a selection.
Could this have the unintended side effect that if the widget is used in the application settings then it writes in some language automatically (as if the user actively selected it)? That would not be nice, because we could not distinguish if the user selected English explicitly (in this case we should use English) or the user simply did not select a language (in this case we may decide in the future to use for example the operating system's language).
Could this have the unintended side effect that if the widget is used in the application settings then it writes in some language automatically (as if the user actively selected it)?
It seems the language combobox is trying to be both a manager and language selector, moving forward we should probably look into introducing an object for dealing with the scanning of a directory, dealing with default vs explicitly selected ...
This should probably be done in future improvements.
With this fix, the test now pass and the behavior reported in https://github.com/Slicer/SlicerLanguagePacks/pull/57 is fixed.
Discovered during the resolution of issues in
ctkLanguageComboBoxTest
, this commit addresses a bug in the normalization and selection of the default language inctkLanguageComboBox
.It introduces the function
normalizeLocaleCode
to ensure that the default locale code is set to its normalized value if valid.Furthermore, the
updateLanguageItems()
function is updated to select the default locale code if the user has not already made a selection.