U4-6307 - Incorrect culture assigned to user (missing region code)

Created by Nicholas Westby 21 Feb 2015, 02:39:59 Updated by Nicholas Westby 02 Jun 2015, 21:24:33

Relates to: U4-6398

Relates to: U4-6665

Wall of 404 Errors After Upgrading to 7.2.2

When I view an Archetype data type in the developer section, I get a wall of errors: !errors.png!

Didn't seem to be getting a 404 on the old site (or notification errors indicating such).

Reason: The region code part of the CultureInfo was not being included for users that were not assigned to en-US. en-US was the only language file that is named with the region code, all others are named with only the country code which was used to assign the culture to the user (since that is what is stored in the db for them). This change came about by accident due to the implementation of the new ILocalizedTextService. The main issue is that the language files that are named with 2 letters (country code only) are actually assigned with a 4 letter (including region code) based on the contents of their file.

6 Attachments

Comments

Sebastiaan Janssen 24 Feb 2015, 16:16:06

I just upgraded a fresh install of Umbraco + Fanoe Starter kit + Archetype and it went perfectly. Are you sure you didn't accidentally remove files from App_Plugins/Archetype?


Nicholas Westby 24 Feb 2015, 17:08:13

@sebastiaan It likely has to do with some culture configuration. Notice that the 404 mentions "en.js", yet that file does not exist. What does exist is "en-us.js". Maybe you are using a different culture? Seems to me this is some problem with localization. !langs.png!


Sebastiaan Janssen 24 Feb 2015, 17:51:21

I tried with UK and US english and had not problems.. not sure what your problem could be but I'd check with the Archetype guys first, they know how they're looking up their language files.


Nicholas Westby 24 Feb 2015, 19:22:13

OK, I asked them about it. We'll see what they say. https://our.umbraco.org/projects/backoffice-extensions/archetype/sound-off!/61678-Archetype-Shows-404-Errors-with-Umbraco-722


Nicholas Westby 24 Feb 2015, 19:27:05

@sebastiaan FYI, I just reproduced this issue on a site I just created this morning (by coincidence... I wasn't actually trying to reproduce this). Umbraco 7.2.2 and Archetype 1.7. I also installed Polyglot, Contour, and [https://github.com/rhythmagency/rhythm.umbraco.extensions Rhythm Umbraco Extensions].


Nicholas Westby 24 Feb 2015, 21:30:28

@sebastiaan Did you actually create a datatype based on Archetype? I just reproduced this by creating a fresh Umbraco 7.2.2 website, then installed Archetype, then created a datatype based on Archetype. At that forum thread I linked to above, somebody else was also able to reproduce it.


Sebastiaan Janssen 24 Feb 2015, 21:38:13

How else would I try it?


Nicholas Westby 24 Feb 2015, 22:39:47

I thought you might be testing it by simply installing Archetype rather than creating a datatype from Archetype, though it appears you went an extra step and actually created a property from that Archetype datatype. So, in theory, you'd have seen the error. To clarify, the error occurs when creating the data type: !full-view.png!

Note that I chose to bypass the starter kit during the install. I have seen the error on both SQL Server installs and SQL Server CE installs.


Lee Kelleher 25 Feb 2015, 13:39:15

Just to add in on this, I hit the same error after upgrading Umbraco from v7.1.9 to v7.2.2.

My guess is that the default culture for a back-office user has changed from "en-GB" to generic "en"?

My solution was to make a copy of the "en-gb.js" language file (renaming it to "en.js").


Sebastiaan Janssen 25 Feb 2015, 14:12:12

I just can't understand why I'm getting en-GB for both System.Threading.Thread.CurrentThread.CurrentCulture; and System.Threading.Thread.CurrentThread.CurrentUICulture;. And when I update my language to US english, those calls both result in en-US. Maybe Archetype is looking up the culture in a different way?


Sebastiaan Janssen 25 Feb 2015, 14:12:42

(in other words, no we didn't change the default culture)


Lee Kelleher 25 Feb 2015, 14:21:46

@sebastiaan - hmmm, very strange!

For reference, Archetype is getting the culture from user.locale (via the userService.getCurrentUser() call): https://github.com/imulus/Archetype/blob/master/app/services/localization.js#L27


Sebastiaan Janssen 25 Feb 2015, 15:53:36

Okay, so I finally found the error.. This is the related change:

https://github.com/umbraco/Umbraco-CMS/commit/db087a9e788e3239e746760f9097787502785149#diff-71f7a320723758678ce16133bc4774b8L47

Previously we would load the Culture from the en.xml file, the en.xml file has culture set to en-GB. After this change we just look in the database (duh, why would you not, we're querying it already anyway!). However.. we store just "en" in the database.. * facepalm *

In fact the only language that we store (almost) "properly" as a culture is en_us (note the underscore, not a dash.. :/ )

I'm not sure what the right thing to do is here, I suspect this will lead to more culture related problems now that it doesn't have a proper culture. However, this is part of a larger change to support backoffice translations much better then before so I also don't know what the impact is of going back to the old way of getting the locale.

Assigned to Shannon for feedback.


Shannon Deminick 06 Mar 2015, 03:25:33

Argh, this is very annoying. The change seb mentions was made after trying to decipher the nonsensical way that cultures are stored and looked up for users. The reason the language is stored just as two letters for most languages is because that is how the language files for Umbraco are stored. It's also worth noting that the culture of just 2 letters is totally valid, so CultureInfo.GetCultureInfo("en") absolutely works. What is really silly is that we then just store the 2 letter in the db, but then store the 4 letter inside of the language files but the languages files are just 2 letters.... obviously none of this is ideal :P

Now, i need to figure out how to un-wind some of this mess and make the new Api's support it too.


Shannon Deminick 06 Mar 2015, 05:02:00

This is fixed in rev: 0932c980e90ea66a083e3346577217bdf4cf1674


Nicholas Westby 28 May 2015, 23:35:43

@Shandem I think I'm experiencing this in Umbraco 7.2.5 (upgraded from 7.0.4, I think). Before I submit another YouTrack issue, is there some database table I can look in to confirm the issue? Here's what I see every time I'm at the login screen:

!login.png!


Shannon Deminick 02 Jun 2015, 19:26:41

@Knickerbocker Are you seeing JS errors? I cannot replicate this. Ctrl + f5 ?


Nicholas Westby 02 Jun 2015, 21:24:33

@Shandem This issue was separate and has been fixed (TLDR: my project had a model binder forcing nulls to be empty strings): http://issues.umbraco.org/issue/U4-6665


Priority: Major

Type: Bug

State: Fixed

Assignee: Shannon Deminick

Difficulty: Normal

Category:

Backwards Compatible: True

Fix Submitted:

Affected versions: 7.2.2

Due in version: 7.2.3

Sprint:

Story Points:

Cycle: