U4-6969 - Property label localization in 7.3 always uses en-US locale

Created by Asbjørn Riis-Knudsen 17 Aug 2015, 11:09:39 Updated by Shannon Deminick 16 Sep 2015, 13:25:25

Localizing property editor labels using dictionary strings (using #DictionaryStringName) now works again in 7.3, after being completely broken in 7.2.

However, it does not take the current culture into account at all - it permanently uses en-US culture (or whatever the default culture of the host system is), irrespectively of the culture of the current backend user.

I have tested the latest build from source.

Specifically, the problem seems to be in these lines in UmbracoCultureDictionary.cs: public CultureInfo Culture { get { return _specificCulture ?? System.Threading.Thread.CurrentThread.CurrentUICulture; } }

System.Threading.Thread.CurrentThread.CurrentUICulture is always en-US, even when the culture of the current backoffice user is something different (I used da-DK in my tests).

Fixing this would either require setting CurrentUICulture to the correct value for every request (perhaps via an ActionFilterAttribute?) or initializing the DefaultCultureDictionary using the culture of the currently logged in user.

Comments

Asbjørn Riis-Knudsen 15 Sep 2015, 14:45:37

Any chance of this being fixed for 7.3 final? The issue is still in the latest nightly (build 269). The fix is fairly simple, I think, but I'm unsure exactly which way to approach it.


Asbjørn Riis-Knudsen 15 Sep 2015, 15:04:57

I have submitted a PR here: https://github.com/umbraco/Umbraco-CMS/pull/792 This PR sets the CurrentUICulture property to the logged-in user's current language.


Shannon Deminick 16 Sep 2015, 13:25:22

This is fixed in rev: 779dd26527907a59d246c95fb1f30d0c386f43b7

When we release the Umbraco Identity extensions package, i'll also need to ensure that the Bearer token auth setup correctly sets the thread culture based on the user's culture. I will review all of this again when I updated the Identity Extensions project since it is possible to put this logic directly in the Umbraco.Core.Security.BackOfficeSignInManager.CreateUserIdentityAsync which will be used by all auth providers, however I'm currently unsure as to whether that would have other implications.


Priority: Major

Type: Bug

State: Fixed

Assignee: Shannon Deminick

Difficulty: Normal

Category: Localization

Backwards Compatible: True

Fix Submitted: Pull request

Affected versions: 7.3.0

Due in version: 7.3.0

Sprint:

Story Points:

Cycle: