We have moved to GitHub Issues
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.
Is it possible for someone to check if 7.x is also affected by this?
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!).
Aww, this isn't getting any love at all...
I wish I had the knowledge to go in and fix it myself.
Why is this still an issue? IContent.Language is always null regardless of language settings. Still an issue in 7.2.1
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.
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.
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.
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?
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.
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
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.
Assuming you have
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.
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).
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.
(note to self: would be easy to backport to 7.2.next)
A backport would be interesting :-)
looks good to me. A backport would be interesting indeed.
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.
Will be in 7.2.7
Priority: Task - Pri 1
Backwards Compatible: True
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