U4-3753 - Language = null on contentService.GetById() when setting only language and not domain

Created by Yiannis Vavouranakis 28 Nov 2013, 13:37:25 Updated by Stephan 14 Jul 2015, 11:01:25

Relates to: U4-4190

ContentService.GetById(NodeId).Language always returns null if no domain has been set, regardless of whether a language has been set on the node or its parents.

Comments

Damiaan Peeters 28 Nov 2013, 13:50:46

Discussed here: http://our.umbraco.org/forum/developers/api-questions/43257-Language-=-null-on-contentServiceGetById()


Yiannis Vavouranakis 16 Jan 2014, 08:56:40

Is it possible for someone to check if 7.x is also affected by this?


Chris Foot 05 Sep 2014, 12:38:38

Annoyingly, it's still broken in 7.1.4

This makes local debugging virtually impossible since you can't use localhost as the domain (and you'd have to change the domain between local and live anyway!).


Yiannis Vavouranakis 05 Feb 2015, 16:25:45

Aww, this isn't getting any love at all...

I wish I had the knowledge to go in and fix it myself.


Daniel Bardi 25 Feb 2015, 04:15:58

Why is this still an issue? IContent.Language is always null regardless of language settings. Still an issue in 7.2.1


Daniel Bardi 25 Feb 2015, 04:19:22

http://issues.umbraco.org/issue/U4-4190


Daniel Bardi 25 Feb 2015, 08:38:45

I went digging in the code and it does appear that language is supposed be saved with the content versions, but is always saved as null. The language field is nullable, but is always null.


Yiannis Vavouranakis 25 Feb 2015, 09:11:37

However, within umbraco, you still see the value you have chosen (i.e. when opening "cultures and hostnames" on the node, you still see the previously chosen culture). So I guess it's not null everywhere.


Stephan 02 Mar 2015, 10:21:49

I think the answer is... IContent.Language is something that has been written as a proof-of-concept for 1-to-1 multilingual support, and never wired to work with domains and cultures - if it does, that would be by accident. So it entirely makes sense that it does not work and it's not simply a "bug" - it was never meant to work, really.

Let me check to make sure that's true.


Jeffrey Schoemaker 02 Mar 2015, 10:25:08

in that case: What would be appropriate way to get the language of a node (not the current node) that hasn't got a domain assigned?


Stephan 02 Mar 2015, 10:36:05

It's not just "give me the culture for that node" but "give me the culture for that node, ''assuming I am browsing that domain''" - since the culture may depend on the domain you're browsing (eg in a 1-to-1 scenario). The methods you want to use are in Umbraco.Web.Routing.DomainHelper - unfortunately most of them are internal.

So I guess that this issue is: create a public method on DomainHelper to get the culture of a node, eg GetNodeCulture(int nodeId, Uri current). Will try to have a look at it.


Stephan 03 Mar 2015, 12:03:06

Work-in-progress. Should consist of extension methods on both IContent and IPublishedContent so it is possible to do:

CultureInfo culture = content.GetCulture();

And, in case of multi-domains, or 1-to-1...

CultureInfo c1 = content.GetCulture(new Uri("http://example.fr")); // returns fr-FR CultureInfo c2 = content.GetCulture(new Uri("http://example.de")); // returns de-DE


Jeffrey Schoemaker 03 Mar 2015, 12:12:27

That looks good!

Just to make sure; we have some sites that uses one domain (www.foobar.com) and the language of the topnode is set to English. A subnode of that site (www.foobar.com/nl) is set to Dutch, but does not have another domain.

So the result should look like:

CultureInfo c1 = content.GetCulture(new Uri("http://foobar.com")); // returns en-US CultureInfo c2 = content.GetCulture(new Uri("http://foobar.com/nl")); // returns nl-NL

===== Correction after re-reading =====

In that case we just could use content.GetCulture() on that node and that would return nl-NL. We don't have to input the domain because that isn't set.


Stephan 03 Mar 2015, 12:47:44

Assuming you have

  • domain "www.foobar.com" with culture "en-US" set on the root node
  • culture "nl-NL" (no domain) set on a sub node

Then

contentInEnglishBranch.GetCulture() == "en-US" contentInDutchBranch.GetCulture() == "nl-NL"

Basically how it works is: we walk up the tree from the content to the first content having a domain, and pick that domain's culture. Then we walk the tree from here back down to the content, and update the culture for every content that has a culture set.

Using GetCulture(something) would be used when the domain makes a difference, ie if you have example.com and example.de on the same content, with different languages.


Timo 03 Mar 2015, 13:55:36

Hi Stephan,

Could you confirm that the following example would work as well?

/home - domain www.foobar.com with culture "en-US" /home/contact - no culture set, so culture is "en-US" /home/nl - culture set to nl-NL, so culture is "nl-NL" '''/home/nl/contact - no culture set, so culture is "nl-NL"'''

In your explanation the last situation might be forgotten (a node that has a parent node with an explicit culture but no domain defined).


Stephan 05 Mar 2015, 09:52:16

For /home/nl/contact... we'd walk up to /home and find domain www.foobar.com with culture en-US, then down to /home/nl/contact, and because in the way there's /home/nl with culture nl-NL, we'd change culture to nl-NL - so yes, /home/nl/contact culture would be nl-NL.

Want to have a look at commit 99598ec0609b3676aee40301b587344867e7ddd3 in branch 7.3.0? Should be OK.


Stephan 05 Mar 2015, 09:52:47

(note to self: would be easy to backport to 7.2.next)


Damiaan Peeters 09 Mar 2015, 21:23:06

A backport would be interesting :-)


Jeffrey Schoemaker 10 Mar 2015, 13:10:20

Hi Stephan,

looks good to me. A backport would be interesting indeed.


Stephan 12 Mar 2015, 14:06:08

As per Shan's suggestion, I have created a unit-testable version of the method. Also, have backported the whole thing to dev-v7. So it should be in the next 7.2.x. Considering the issue fixed.


Stephan 14 Jul 2015, 11:01:22

Will be in 7.2.7


Priority: Task - Pri 1

Type: Bug

State: Fixed

Assignee: Stephan

Difficulty: Normal

Category: Localization

Backwards Compatible: True

Fix Submitted:

Affected versions: 6.1.6, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.2.1, 7.2.2

Due in version: 7.2.7

Sprint:

Story Points:

Cycle: