November Happy Hour will be moved to Thursday December 5th.
AI OnAI Off
Language on product details
The languagename of the SiteContext.Current is always my default langauge (da-DK) no matter what seo url i am using. So its hard for me to pull the correct localized data from the catalog.
Jun 13, 2012 8:40
We have different SEO url on our product for each country. I can identify the problem with using the same url from this thread:
http://world.episerver.com/Modules/Forum/Pages/Thread.aspx?id=51537&epslanguage=en. What is funny about the problem mentioned in this thread is that ecf created the exact same default url for all langauges. But back to the problem at hand:
an example for a specific product we got theese 2 urls:
da-DK: /my-flower-dk.aspx
en-US: /my-flower-en.aspx
If i go to /my-flower-en.aspx SiteContext.Current.LanguageName is always da-DK. I can see from the CatalogContextModule where the SiteContext is set on each request, that it takes langauge from Thread.CurrentThread.CurrentCulture.Name.
So is the urlrewrite for commerce supposded to set Thread.CurrentThread.CurrentCulture depending on the url if it hits a commerce product?
I can see that there is a querystringparameter in rewrited url with the langauge but i do not see it being using anywhere. I could ofcourse just make my own version of CatalogContextModule where i set the langaugename from this parameter. But imho its not the right solution and ecf should take care of this.
Jun 14, 2012 13:19
The short answer is you will be responsible to make sure Thread.CurrentThread.CurrentCulture.Name is set properly or create your own module to properly set the Langauage in the SiteContext. There were some differences in the handling of language between ECF and CMS that are bing addressed with the next release.
Jun 14, 2012 20:37
Ok I will reluctantly accept the fact that we need to fix it ourselves, but please tell me why this works in ClickTalk demosite?
Did something change between R2 SP1 and R2 SP2?
I cannot find the piece of code that actually is responsible for settings the correct languagename in ClickTalk.
Jun 15, 2012 8:09
This is the code from the click 2 talk that changes the language of the page
if (!string.IsNullOrEmpty(Request.QueryString[Business.Commerce.Constants.ParameterEntryCode]))
{
UrlBuilder builder = new UrlBuilder(UriSupport.AbsoluteUrlBySettings(page.LinkURL));
foreach (var key in Request.QueryString.AllKeys)
builder.QueryCollection[key] = Server.UrlEncode(Request.QueryString[key]);
builder.QueryCollection["epslanguage"] = Server.UrlEncode(page.LanguageID);
EPiServer.Global.UrlRewriteProvider.ConvertToExternal(builder, page.PageLink, Encoding.UTF8);
navigateUrl = builder.Uri.AbsoluteUri;
}
The commerce url rewritter needs to be be find the correct page based on the SiteContext.LanguageName. I think the click to talk had the correct culture set in the thread by cms url handling the language that is set in the url.
Jun 15, 2012 9:03
Yes i can see that, but the problem is where and when SiteContext.Current.LanguageName is set...
I have now made a copy of the CatalogContextModule in the ClickTalk demo site, so I was able to debug into it. I can see from reflection that in this module the SiteContext is set. But when I go to a german product details the SiteContext.Current.LanguageName is set to "en-US", but when it reaches the ProductTemplate the SiteContext.Current.LanguageName is now set to "de-DE". So later in the request lifetime cycle the SiteContext.Current.LanguageName is changed and I can't really figure out where.
Imho bad design ...
Jun 15, 2012 9:50
Found it. The Product.aspx in ClickTalk inherits from EPiServer.Business.Commerce.PageBase, where SiteContext.Current.LanguageName is overridden in InitializeCulture.
We didn't inherit from that base class. Now we do ...
Jun 15, 2012 10:56
One more comment on this issue, just for observation.
When you install EPiServer CMS and set for instance Norway as default language - it's code is 'no'. However in ECF you can't specify default langauge just with country code - you have to specify "fully qualified" language code - nb-NO.
When ECF is searching for page in CMS to display product details - it tries to ask CMS for page date based on language code specified in ECF - nb-NO. CMS fails to serve this page - because such a language does not exist at all. As result - the whole routing to product details page ends with yellow screen of death :)
We just added language with full code - nb-NO to CMS, and ECF module/handler is now able to to request the page, receive null as repsonse and proceed with further logic on finding out which page will be used to display product details.
Is this known / by design?
Dec 21, 2012 19:27
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.
On our product listing we have gotten a lot of inspiration from the enoteca website using wcf services and passing on the language name from the episerver CurrentPage.LanguageId.
For the product details page we fetch the product like on the ClickTalk site, where the CurrentUICulture is temporarily switched while getting the catalog entry. In the ClickTalk it uses SiteContext.Current.LangageName to switch the culture. On our product details page its always the default language in the SiteContext. I can see that there is a HttpModule called CatalogContextModule that actually sets the SiteContext using:
SiteContext current = SiteContext.Current;
current.AppPath = HttpContext.Current.Request.ApplicationPath;
current.LanguageName = Thread.CurrentThread.CurrentCulture.Name;
But who is responsible for setting the thread CurrentCulture here? The commerce url rewriter or? I can't really figure out why our site behaves so differently from ClickTalk in this matter.
Sidenote: We decided to build the commerce site from scratch not using either ClickTalk or Enoteca. So it might be some configuration we are missing here?