Hello. I'm planning out the build of a fairly large multilingual Umbraco site. I want to do the typical 1:1 structure with top-level nodes for each language, but since the site's going to be fairly large, I want to associate each page with the equivalent pages in the other languages, for two reasons:
So I can output a list on each content node in the backoffice, with shortcuts its other language versions.
So I can programmatically find an alternate language version of a page without having to reference the page URL.
Is there a way I can do this without much custom development, but also without relying on a 3rd party plugin?
But they all rely on some programming. I don't know what you mean with "much custom development".
One option is to use the relation service in umbraco. But if you have a lot of (like more than 2) languages, using relations is a bad thing as every page will link to every possible translation
build a custom table and one custom plugin linking all pages together.
Most plugin's are open source, so I would definitly look at the community projects to see if anything suits you.
Thank you. By "not much custom development" I mean that a solution which can be done by someone with only light Razor/C#/Angular experience would be ideal.
I understand what you're saying about the plugins being open source, but we're trying to be very future-proof, so I'm still hesitant to rely on one that is too complex for us to understand/patch if necessary. I guess we could potentially have a 3rd party patch someone else's plugin?
Could you elaborate on why relations are a bad thing for more than 2 languages? We're going to have 6+ languages, but every page linking to the version in every other language sounds good to me, and all the plugins I saw use relations. Why would relations be bad for over 2 languages?
For a custom table, how could that information be accessed from Razor?
I know I have a lot of questions, anything you could elaborate on would be appreciated.
Because you want for every page to link to all the other pages, you will get, for every node:
3 languages = 3 relations
4 languages = 3 +2+ 1 relations
5 languages = 4+3+2+1 relations
6 languages = 5+4+3+2+1 relations.
Ive seen 2 sites, where they tried this. And they failed both on implementing it.
E.g.: try to create a new child node.
plug in into the save event
create a new "child page" for every other language linking to the current page
create the correct links between all the pages
If you have one simple bug, this will get you into infinite loops. And you will end up with millions of relations. (seen it already on a project)
Take into account that the relation api is not cached, so you will have to implement your own caching strategy for front-end rendering. Don't forget you need to get each page from the cache to know which language this is, because that is not saved into the relation itself.
I've always had the idea that the relationApi was not "thread safe". I can't tell how thread-safe it is today. But you should think about what will happen if 2 people save at the same time.
I've walked this road, and it's not is not some "simple c#" story.
What I would do is create a table with 3 properties:
LinkGroupId
PageId
LanguageId
umbracoPath (for future reasons)
The pageId could be unique, making sure the page belongs only in one set of translated pages.
The linkgroupId is a "counter" and the same for every "pageId" which belongs together in a group (we have int's enough).
The languageId allows to generate links on your masterpage without referencing the other pages.
The umbracoPath (optional) allows to fall back to an ancester page if you need to.
The only thing to do, is to create
a simple UmbracoApiController
a simple angular plugin
implement some "helper" to render (and cache) the result (or put the rendering of the language links in a Html.CachedPartial()
I don't trust Vorto because of how dependant a site would be on it. I'm wondering if we should use Polygot, though. A structure with each language node nested under the primary language would nearly eliminate the need for the relations-type stuff. I'm just unsure how dependant a site would be on it, or if it just makes built-in things faster/easier.
I would build on Vorto. Vorto is developed by Matt, a very valued community member, and the code is open source. The package would be candidate to be incorporated into the core IMHO.
Polyglot is used on a project with 27 languages and works pretty well. But isn't the best experience for the user. They are about to rebuild the project with ... guess... Vorto.
I don't know if putting Vorto in the grid is supported in the mean time. But that is only a matter of time.
Whether you build on Polyglot or Vorto these are very valid packages to build on. You won't be the first to do.
I don't understand yet your "aversion" of (these) packages. They are awesome and work very well. Have been battletested. And won't pose problems with other parts of your website.
Thanks for the reply. My aversion to these packages is solely about future-proofing. I would love to use Vorto, but we want to build a website which will work for years to come. It's going to be a large and complex site, and the last thing we want is to build it around a 3rd-party package, and a couple years later, find that the package is no longer supported, and run into issues that would break functionality or prevent us from upgrading the CMS. While I know this was a special case, I saw a lot of packages that never made the transition to v7, so I'm wary of package developers simply giving up or losing interest.
I hadn't considered the fact that open source means we could potentially get fixes applied to a package even if the original developer has abandoned it, but that's still not particularly appealing compared to avoiding the reliance entirely.
Associating translated pages with each other?
Hello. I'm planning out the build of a fairly large multilingual Umbraco site. I want to do the typical 1:1 structure with top-level nodes for each language, but since the site's going to be fairly large, I want to associate each page with the equivalent pages in the other languages, for two reasons:
Is there a way I can do this without much custom development, but also without relying on a 3rd party plugin?
Thanks,
David
There are a lot of options.
But they all rely on some programming. I don't know what you mean with "much custom development".
Most plugin's are open source, so I would definitly look at the community projects to see if anything suits you.
Hi Damiaan,
Thank you. By "not much custom development" I mean that a solution which can be done by someone with only light Razor/C#/Angular experience would be ideal.
I understand what you're saying about the plugins being open source, but we're trying to be very future-proof, so I'm still hesitant to rely on one that is too complex for us to understand/patch if necessary. I guess we could potentially have a 3rd party patch someone else's plugin?
Could you elaborate on why relations are a bad thing for more than 2 languages? We're going to have 6+ languages, but every page linking to the version in every other language sounds good to me, and all the plugins I saw use relations. Why would relations be bad for over 2 languages?
For a custom table, how could that information be accessed from Razor?
I know I have a lot of questions, anything you could elaborate on would be appreciated.
Thanks for your help,
David
Because you want for every page to link to all the other pages, you will get, for every node:
Ive seen 2 sites, where they tried this. And they failed both on implementing it.
E.g.: try to create a new child node.
If you have one simple bug, this will get you into infinite loops. And you will end up with millions of relations. (seen it already on a project)
Take into account that the relation api is not cached, so you will have to implement your own caching strategy for front-end rendering. Don't forget you need to get each page from the cache to know which language this is, because that is not saved into the relation itself.
I've always had the idea that the relationApi was not "thread safe". I can't tell how thread-safe it is today. But you should think about what will happen if 2 people save at the same time.
I've walked this road, and it's not is not some "simple c#" story.
What I would do is create a table with 3 properties:
The pageId could be unique, making sure the page belongs only in one set of translated pages. The linkgroupId is a "counter" and the same for every "pageId" which belongs together in a group (we have int's enough). The languageId allows to generate links on your masterpage without referencing the other pages. The umbracoPath (optional) allows to fall back to an ancester page if you need to.
The only thing to do, is to create
It's on my todolist for at almost 3 years.
Awesome, really appreciate the detailed response.
I don't trust Vorto because of how dependant a site would be on it. I'm wondering if we should use Polygot, though. A structure with each language node nested under the primary language would nearly eliminate the need for the relations-type stuff. I'm just unsure how dependant a site would be on it, or if it just makes built-in things faster/easier.
Do you have any experience with it?
Thanks again,
David
I would build on Vorto. Vorto is developed by Matt, a very valued community member, and the code is open source. The package would be candidate to be incorporated into the core IMHO.
Polyglot is used on a project with 27 languages and works pretty well. But isn't the best experience for the user. They are about to rebuild the project with ... guess... Vorto.
I don't know if putting Vorto in the grid is supported in the mean time. But that is only a matter of time.
Whether you build on Polyglot or Vorto these are very valid packages to build on. You won't be the first to do.
I don't understand yet your "aversion" of (these) packages. They are awesome and work very well. Have been battletested. And won't pose problems with other parts of your website.
Thanks for the reply. My aversion to these packages is solely about future-proofing. I would love to use Vorto, but we want to build a website which will work for years to come. It's going to be a large and complex site, and the last thing we want is to build it around a 3rd-party package, and a couple years later, find that the package is no longer supported, and run into issues that would break functionality or prevent us from upgrading the CMS. While I know this was a special case, I saw a lot of packages that never made the transition to v7, so I'm wary of package developers simply giving up or losing interest.
I hadn't considered the fact that open source means we could potentially get fixes applied to a package even if the original developer has abandoned it, but that's still not particularly appealing compared to avoiding the reliance entirely.
The amount of the packages never upgraded to be compatible with v7 is indeed a very valid argument.
But you know v8 will have breaking changes, whether you depend on these packages or on your own code. :-)
So, I guess you should build your own, share it with the world (and never abondon development). Sounds like an awesome idea. Not? :-D
is working on a reply...