Language on product details

Member since: 2009

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?

#59434 Jun 08, 2012 15:15
  • Mark Hall
    Member since: 2011

    I am a little confused on what the problem you are facing.  

    #59463 Jun 12, 2012 23:59
  • pme
    Member since: 2009

    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.


    #59468 Jun 13, 2012 8:40
  • pme
    Member since: 2009

    We have different SEO url on our product for each country. I can identify the problem with using the same url from this thread: 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.

    #59525 Jun 14, 2012 13:19
  • Mark Hall
    Member since: 2011

    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.

    #59537 Jun 14, 2012 20:37
  • pme
    Member since: 2009

    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.

    #59544 Jun 15, 2012 8:09
  • Mark Hall
    Member since: 2011

    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.



    #59545 Jun 15, 2012 9:03
  • pme
    Member since: 2009

    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 ...

    #59546 Jun 15, 2012 9:50
  • pme
    Member since: 2009

    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 ...

    #59548 Jun 15, 2012 10:56
  • valdis iljuconoks
    Member since: 2011

    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?

    #64496 Dec 21, 2012 19:27