Try our conversational search powered by Generative AI!
AI OnAI Off
Blocks have wrong culture when rendered in contentarea
I think I've seen that the safer way is to not serve pages without a language segment as the first dir part. I assume everything works if you go http://site.localtest.me/no/* and http://site.localtest.me/da/*?
Edited,
Oct 04, 2016 22:06
Hi Johan,
Nope, thanks though. Our problem has a different cause. We've implemented a custom IUpdateCurrentLanguage with some logic that (apparently) shouldn't be there. I opened a support ticket because it looks like that you're not allowed to change the language at all in IUpdateCurrentLanguage.UpdateLanguage, not sure if it's a bug or not:
https://github.com/brianweet/AlloyDemoKit/tree/translation-problem
Will update this topic when I hear back from EPi :)\
Probably should look into another implementation, like the docs state:
"The selection algorithm outlined above is implemented in ContentLanguage.DefaultContentLanguage and can be overridden by inheriting from ContentLanguage and assigning an instance of the new class to the static property Instance onContentLanguage."
http://world.episerver.com/documentation/Items/Developers-Guide/Episerver-CMS/9/Globalization/Determining-languages/
Oct 04, 2016 22:25
So I forgot to update this topic. The response from epi support was:
"December 21, 2016 12:43
Hi Brian,
In the quicksilver case they are only setting the language in case it is null (the language could not be determined by routing), they are not replacing the language determined by routing.
Thanks."
Our code was based on the LanguageService from Quicksilver back then. In dec someone updated Quicksilver to epi 10.1 and changed the functionality in that LanguageService.
https://github.com/episerver/Quicksilver/blob/master/Sources/EPiServer.Reference.Commerce.Site/Features/Market/Services/LanguageService.cs#L37
Anyway, don't change the language if you get a language as input. Only set a language if there's no language set yet (by routing).
Mar 07, 2017 18:51
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
We have a page with two language versions, primary language is Norwegian and secondary is Danish.
I've created translated blocks in a culture specific ContentArea. The blocks do not render the correct language version unless I use a different domain.
So if I use http://site.localtest.me and http://site.localtest.me/da I get Norwegian blocks on both sites.
If I use http://site.localtest.me and http://site.localtest.dk.me and set up the preferred culture in Epi Admin everything works fine.
Weird thing is that if I drag and drop the blocks in the editor, the correct blocks render but after publishing the Norwegian blocks render once again.
The page has a culturespecific image property as well, which is being shown correctly, so it looks like it has something to do with the contentarea.
We do have a custom content area renderer, however the language is already wrong when entering the RenderContentAreaItem method (we override that one).
Anyone experienced any problems like this?
We're using Cms Version 9.12.2.
And the blocks always render in the primary language, not the other way around.
Thanks,
Brian