I'm building a multilingual site in V8. All seems well until I want to assign Url's per language.
The way to go right now is to set culture and hostnames like in V7. This is a great solution if you are using url’s like Umbraco.com and Umbraco.nl.
If however you want to use url’s like Umbraco.com/nl or Umbraco.com/en it feels like a extra unnecessary step. Also the text at culture and hostnames tells you not to do it like this.
In V7 this could easily be avoided by having a rootnode with language-nodes under them named with the languagecodes.
e.g.
- Rootnode
- nl
- Over ons
- en
- about us
In the V8 this setup isn’t necessary anymore.
What I propose is to use the setting Umbraco.Core.HideTopLevelNodeFromPath and use the name of the rootnode as the url after the /
If Umbraco works like this the only thing you need to do to add a new language is to add a new language. This makes the workflow easier and therefore more friendly.
The problem with doing it this way is that you miss out on the variants functionality. As you seem to need a central node that uses hostname config to set the culture of the node (the rootnode). If you dont, then you will have to copy pages like before.
The text needs to change since it is confusing, unless I am missing something.
In the past we would use Vorto to do a combination between multi tree and multilingual nodes, now you can use variants to replace both.
The only problem is that Umbraco doesn't allow it right now. Umbraco doesn't know about the setting in web.config when publishing so it states This document is published but its url cannot be routed
If it would know about the setting and publish the node under the /en url it would make setting the culture/hostname completely unnecessary
Does this clarify what I mean?
Edit: Added benefit is that if we start out with /nl and decide we want a belgium site to we could change /nl to /nl-nl and the 301 tracker in Umbraco would do the rest. No need for manual redirects.
In terms of multilingual sites in v8, there's 2 options - multi tree like in v7, or one to one using v8 variants.
Based on the above i assume you are still referring to the multi-tree setup, not variants?
I'm unsure what you mean by
Also the text at culture and hostnames tells you not to do it like this.
The text in that dialog states:
Valid domain names are: "example.com", "www.example.com", "example.com:8080", or "https://www.example.com/". Furthermore also one-level paths in domains are supported, eg. "example.com/en" or "/en".
If you don't explicitly assign a culture to a node then how will Umbraco know what culture is rendering? (which is set on the Current thread culture of those page requests)
Or are you referring to detecting if a root node name matches a valid .NET culture name?
I'm only interested in the variant version of V8. The v7 example was only a reference to the way it was. So forget multiple trees.
I'm unsure what you mean by
Also the text at culture and hostnames tells you not to do it like
this.
The text in that dialog states:
Valid domain names are: "example.com", "www.example.com", "example.com:8080" or "https://www.example.com/". One-level paths in domains are supported, eg. "example.com/en". However, they should be avoided. Better use the culture setting above.
If you don't explicitly assign a culture to a node then how will
Umbraco know what culture is rendering? (which is set on the Current
thread culture of those page requests)
If I add a languag in V8 the content is automaticly added in the dropdown in the contenttree. So can't we use that for rendering purposes?
I'd like to leave everything as is right now with the ability to use the rootnode name as url segment for the language. That feels like the right way.
If the default is set up like this the only time you need to set culture and hostnames is when using "complex domains" (subdomains or tld's) or when you want to use a multi rootnode setup.
I don't believe this statement exists in the latest codebase
However, they should be avoided. Better use the culture setting above.
I think i know what you are talking about...
I'd like to leave everything as is right now with the ability to use the rootnode name as url segment for the language. That feels like the right way.
But I think going down this road will possibly open up a can of worms
What happens if you name 2 or more of your variant names the same? Or use the umbracoName property and you have overlaps? Then you cannot route.
What about when you have multiple root nodes and/or you have a root node that is invariant with variant ones underneath?
I think it could be done, but then it means we are supporting a bit of magic and things stop being consistent when people operate outside of a single root node structure. IMO it would be easier to explain to developers that there is one way to do things instead of multiple ways to do things that only work in some scenarios.
What happens if you name 2 or more of your variant names the same?
When saving and publishing this could be checked if the flag "use rootnodename as segment is on"? I thought It was impossible already so I overlooked this..
I think it could be done, but then it means we are supporting a bit of
magic and things stop being consistent when people operate outside of
a single root node structure. IMO it would be easier to explain to
developers that there is one way to do things instead of multiple ways
to do things that only work in some scenarios.
I am looking for a way to not explain anything at all for the default way of using multilingual sites.
It is very confusing if I select English in the dropdown above the content tree and then select the rootnode and set the culture to dutch. The variations are awesome to work with and then with routing it feels more complicated then needed?
Maybe we should have a conversation at codegarden about this on Friday?
This is not entirely true. A "settings-node" could still be there as a rootnode but it should be separated by type (element type?). If this is impossible it's a deal breaker for lots of people.
I've been trying to get around what's really bothering me in this situation and I think the issue is more of a interface issue.
The language selector above the content tree is kind of misleading. You expect the culture to be there and just have to set the url/url segment somewhere. I especially notice this with my non-umbraco colleagues.
When you add a new language the tree is there and it only needs a url.
So if we rename culture and hostnames to languageurl's (or something similar) and prefill the list with the current cultures it would be more simplified.
The only thing that is left is the issue that the change in url isn't tracked in the redirect url manager.
Multilingual Urls
Hi all,
I'm building a multilingual site in V8. All seems well until I want to assign Url's per language.
The way to go right now is to set culture and hostnames like in V7. This is a great solution if you are using url’s like Umbraco.com and Umbraco.nl.
If however you want to use url’s like Umbraco.com/nl or Umbraco.com/en it feels like a extra unnecessary step. Also the text at culture and hostnames tells you not to do it like this.
In V7 this could easily be avoided by having a rootnode with language-nodes under them named with the languagecodes.
e.g.
In the V8 this setup isn’t necessary anymore.
What I propose is to use the setting Umbraco.Core.HideTopLevelNodeFromPath and use the name of the rootnode as the url after the /
If Umbraco works like this the only thing you need to do to add a new language is to add a new language. This makes the workflow easier and therefore more friendly.
Thanks, Frans
I don't understand your suggestion. Do you mean the existing HideTopLevelNodeFrom path is not working anymore?
https://our.umbraco.com/documentation/Reference/Config/webconfig/#umbracohidetoplevelnodefrompath
The problem with doing it this way is that you miss out on the variants functionality. As you seem to need a central node that uses hostname config to set the culture of the node (the rootnode). If you dont, then you will have to copy pages like before.
The text needs to change since it is confusing, unless I am missing something.
In the past we would use Vorto to do a combination between multi tree and multilingual nodes, now you can use variants to replace both.
@Damiaan: That function is working but Umbraco is ignoring it for Url creation.
I've not been clear in my explanation it seems. What I don't want is the structure of v7 in v8.
What I propose is to use the name of the rootnode as the url for the language. This is possible when you disable HideTopLevelNodeFromPath.
The only problem here is that Umbraco doesn't allow it yet. It just sees a url clash.
So for example:
The dutch and english trees in V8 would look like this:
If you set it up like this and disable the hide rootnode from path the following code returns the correct url's:
http://localhost:4316/nl
http://localhost:4316/en
The only problem is that Umbraco doesn't allow it right now. Umbraco doesn't know about the setting in web.config when publishing so it states This document is published but its url cannot be routed
If it would know about the setting and publish the node under the /en url it would make setting the culture/hostname completely unnecessary
Does this clarify what I mean?
Edit: Added benefit is that if we start out with /nl and decide we want a belgium site to we could change /nl to /nl-nl and the 301 tracker in Umbraco would do the rest. No need for manual redirects.
In terms of multilingual sites in v8, there's 2 options - multi tree like in v7, or one to one using v8 variants.
Based on the above i assume you are still referring to the multi-tree setup, not variants?
I'm unsure what you mean by
The text in that dialog states:
If you don't explicitly assign a culture to a node then how will Umbraco know what culture is rendering? (which is set on the Current thread culture of those page requests)
Or are you referring to detecting if a root node name matches a valid .NET culture name?
I'm only interested in the variant version of V8. The v7 example was only a reference to the way it was. So forget multiple trees.
Valid domain names are: "example.com", "www.example.com", "example.com:8080" or "https://www.example.com/". One-level paths in domains are supported, eg. "example.com/en". However, they should be avoided. Better use the culture setting above.
If I add a languag in V8 the content is automaticly added in the dropdown in the contenttree. So can't we use that for rendering purposes?
I'd like to leave everything as is right now with the ability to use the rootnode name as url segment for the language. That feels like the right way.
If the default is set up like this the only time you need to set culture and hostnames is when using "complex domains" (subdomains or tld's) or when you want to use a multi rootnode setup.
Does this make more sense?
I don't believe this statement exists in the latest codebase
I think i know what you are talking about...
But I think going down this road will possibly open up a can of worms
What happens if you name 2 or more of your variant names the same? Or use the
umbracoNameproperty and you have overlaps? Then you cannot route.What about when you have multiple root nodes and/or you have a root node that is invariant with variant ones underneath?
I think it could be done, but then it means we are supporting a bit of magic and things stop being consistent when people operate outside of a single root node structure. IMO it would be easier to explain to developers that there is one way to do things instead of multiple ways to do things that only work in some scenarios.
When saving and publishing this could be checked if the flag "use rootnodename as segment is on"? I thought It was impossible already so I overlooked this..
I am looking for a way to not explain anything at all for the default way of using multilingual sites. It is very confusing if I select English in the dropdown above the content tree and then select the rootnode and set the culture to dutch. The variations are awesome to work with and then with routing it feels more complicated then needed?
Maybe we should have a conversation at codegarden about this on Friday?
In order for this to work though, there needs to be a specific circumstance:
Then if any of these circumstances change, it will no longer work.
I'm just thinking that this ends up being more difficult to explain than a consistent way that always works which is assigning host names?
That said, maybe the circumstance above is the most common and in most cases they don't change?
That sounds about right.
This is not entirely true. A "settings-node" could still be there as a rootnode but it should be separated by type (element type?). If this is impossible it's a deal breaker for lots of people.
I've been trying to get around what's really bothering me in this situation and I think the issue is more of a interface issue.
The language selector above the content tree is kind of misleading. You expect the culture to be there and just have to set the url/url segment somewhere. I especially notice this with my non-umbraco colleagues. When you add a new language the tree is there and it only needs a url.
So if we rename culture and hostnames to languageurl's (or something similar) and prefill the list with the current cultures it would be more simplified.
The only thing that is left is the issue that the change in url isn't tracked in the redirect url manager.
is working on a reply...