-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Language variants (v8) through culture and hostnames #17
Comments
What would it take to implement this kind of functionality? What are the roadblocks? |
Note that #13 suggests manually adding every alternative route to HeadRests mapping. But that doesn't scale... |
Ahh, I think I might have identified the need for this in a previous PR on a different subject, but I think the route handler would need updating to handle the "domain" entries https://github.com/mattbrailsford/umbraco-headrest/blob/develop/src/Our.Umbraco.HeadRest/Web/Routing/HeadRestRouteHandler.cs and possibly the URL provider too https://github.com/mattbrailsford/umbraco-headrest/blob/develop/src/Our.Umbraco.HeadRest/Web/Routing/HeadRestUrlProvider.cs I'd need to look into this to determine exactly what would need to happen, but I don't really have time atm. If someone wants to investigate, I'd happily provide guidance as to whether it sounds like you are on the right path. Otherwise it'll have to wait till I have some time free. |
Thanks for the pointer. I'm going to see if I can make some time. So in the route handler, the
The code then moves on to build an xpath based on the path entered and retrieves the node from that path if it exists. I guess it would be possible to rewrite this method and see if the That would break the |
@jessevdp I think so yes. I think there might be need to look into the core Domain entities where the hostnames are registered and whether we need to do some lookup based on those paths. I seem to remember having to do this for a content finder some time ago, but I can't fully remember what I did. I'll see if I can dig something out later. |
@jessevdp I am currently developing VueJS based community site NC COVID Support that I am looking to shortly port across to use Umbraco as it's back end ( the site's data currently comes from a Google spreadsheet via their JSON API ) I was just looking to see if Matt's package would suit our requirements, I noticed this thread about multilingual usage of the API. I wondered if you had managed to make any progress with this? @mattbrailsford - As always, a great looking package 🥇 Cheers, Chris |
As far as I know, no progress. I was hoping to pick this up as part of an internship I was doing at the time. Never got around to it due to time constraints/priorities. Note that this issue is in regard to Umbraco 8 language variants. You can still achieve an Umbraco 7 like multi-language setup if you like. (Separate content trees.) |
Umbraco 8 introduced Language Variants. The "Adding language variants" section in the "Creating basic site" tutorial on Our Umbraco mentions that hostnames configuration is required to output the language variants of a content node (scroll down to "culture and hostnames" which is boldly printed somewhere in the article 😄). Consider the culture and hostnames configuration below.
After some (limited) experimentation I've concluded that HeadRest does not take the hostname configuration into account. Attempting to access a content item at an alternative URL results in a 404 error. I've tested both, a config in which the alternative URL has a different language, and a config where the alternative URL is in the same language.
I suppose that making HeadRest work with the hostnames config makes it work with language variants as a result. If not inherently, then I think it should be reasonable to add on top. (Note that I'm not familiar enough with the codebase to know for sure.)
The text was updated successfully, but these errors were encountered: