[BUG] Language Management

[sbwalker]

Oqtane Info

Version - All
Render Mode - All
Interactivity - All
Database - All

Describe the bug

The Language table in the database contains fields for Code and Name. When a language is added to a site, the Name field is populated with the value selected by the user from the list of languages. The list of languages is localized based on the user's UI culture. If the user had set their UI culture to French then the value inserted in the Name field would be the French translation of whatever language they chose. If another user later adds another language to the site and their UI culture is English, then the English value of the language chosen would be inserted in the Name field. This results in inconsistencies in the data. In addition, the default language for the site is not stored in the Language table but is added dynamically to the list of languages returned from the API. The name of the default language is based on the current user's UI culture - which again can result in inconsistencies in the data displayed.

Expected Behavior

One option is to ensure the Name in the Language table is stored in a consistent format (ie. using the invariant culture). The other option is to not store the Name in the Language table and use CultureInfo to dynamically retrieve the localized name based on the Code and UI culture of the current user.

Steps To Reproduce

Anything else?

[hishamco]

Can I handle this one?

[sbwalker]

@hishamco do you have insight into why the Name field was included in the Language table?

[sbwalker]

@hishamco there were 2 possible solutions outlined in the issue above. I was hoping to get some more insight into why the Name is stored in the Language table ie. if there is a valid reason for it then it makes sense to retain the Name field - otherwise it makes sense to remove it.

[thabaum]

@sbwalker was the name field used for search?

[sbwalker]

The Language table was introduced before Search was added

[hishamco]

@hishamco there were 2 possible solutions outlined in the issue above. I was hoping to get some more insight into why the Name is stored in the Language table ie. if there is a valid reason for it then it makes sense to retain the Name field - otherwise it makes sense to remove it.

I don't think there's a problem to save the culture name but we should use the native name

[sbwalker]

@hishamco the related PR is difficult to review as the code was reformatted, making it challenging to identify the actual changes. I do not see how it answers the question of whether the Name field in the Languages table is necessary or not. It changes the logic so that the NativeName is stored in the Name field - however it does not contain any logic to deal with prior data which was created previously using DisplayName.... so I guess the assumption is that an admin would need to manually delete their language records in their site and re-add them (so that they are consistent)? I also see that the PR changes the LanguageSwitcher component to use NativeName - which is not the desired behavior (ie. the LanguageSwitcher uses PageState.Languages as its source of data which is localized based on the current users UI culture - which is the correct behavior).

[sbwalker]

After further review, there does not appear to be any valid reason to store the Name value in the database. The Name value should be derived dynamically using CultureInfo, which will take into the account the current user's UI culture.

[sbwalker]

#4741 removes the Name column from the Language table and populates it dynamically using CultureInfo. The result is that the list of languages displayed in the LanguageSwitcher and in Language Management are localized consistently based on the language preference of the user (stored in the culture cookie)