Localization not working

GOSSO
Member since: 2007
 

Upgrade from cms6 to CMS 7.19.2 webforms: In some places on our web, we do translate to local resources like this:

On some pages it does not work at all (always shows in english or always in Swedish, is there a cache?), in some pages it does work in the head.ascx but not in the footer.ascx

In some pages "Translate"-control works, but not the above at the same time

Any idea what to use in Epi 7.5?

#119193 Mar 23, 2015 15:46
  • valdis iljuconoks
    Member since: 2011
     

    Hi,

    What is CurrentUICulture at that moment?

    #119224 Mar 24, 2015 21:39
  • GOSSO
    Member since: 2007
     

    Only if I set in OnInit in masterpage

     var culture = CultureInfo.CreateSpecificCulture(EPiServer.Globalization.ContentLanguage.SpecificCulture.Name);
    
    CultureInfo.DefaultThreadCurrentCulture = culture;
    CultureInfo.DefaultThreadCurrentUICulture = culture;
    
    System.Threading.Thread.CurrentThread.CurrentCulture = culture;
    System.Threading.Thread.CurrentThread.CurrentUICulture = culture;

    then is CurrentCulture and CurrentUICulture changed. But the translations stays to be the default lang (SV in dev and EN in Prod) <-- ?

    I shouldn't need to set the culture, should i? any how it doesn't translate.

    Any help is appriciated. Im not sure this is Epi-related or not.

    #119285 Mar 26, 2015 9:32
  • valdis iljuconoks
    Member since: 2011
     

    What are your globalization settings in web.config?

    #119497 Mar 28, 2015 11:46
  • valdis iljuconoks
    Member since: 2011
     

    What are results for these lines if you paste them into your template?

        EPiServer:Translate: <EPiServer:Translate runat="server" Text="/commerce/login" /><br />
        Literal: <asp:Literal ID="Literal1" runat="server" Text="<%$ Resources: EPiServer, commerce.login %>" /><br />
        LocalizationService: <%= LocalizationService.Current.GetString("/commerce/login") %><br />
        ViewState: <%= ViewState["_language"] %><br />
    

    Can you also paste your <episerver.framework><localization> elment content?

    #119519 Edited, Mar 28, 2015 20:12
  • GOSSO
    Member since: 2007
     

    Week-end work, appreciated!

    None <localization> in <episerver.framework>

    web.config: <globalization culture="en-US" uiCulture="en" requestEncoding="utf-8" responseEncoding="utf-8" resourceProviderFactoryType="EPiServer.Framework.Localization.LocalizationServiceResourceProviderFactory, EPiServer.Framework" />

    output in se-SV:

    EPiServer:Translate: Logga in
    Literal: Log in
    LocalizationService: Logga in
    ViewState: 

    output in en-US:

    EPiServer:Translate: Log in
    Literal: Log in
    LocalizationService: Log in
    ViewState: 
    #119523 Mar 28, 2015 23:13
  • valdis iljuconoks
    Member since: 2011
     

    I'm not sure about 7.19 version I believe that this is the same as in 8.0. If you don't have localization settings configured for EPiServer Framework, localization should not work at all and every line should give you empty string.

    Maybe you have EPiServerFramewotk.config file instead? Try to look for similar fragment:

    <localization fallbackBehavior="Echo, MissingMessage, FallbackCulture" fallbackCulture="en">
      <providers>
        <add virtualPath="~/Resources/LanguageFiles" name="languageFiles" type="EPiServer.Framework.Localization.XmlResources.FileXmlLocalizationProvider, EPiServer.Framework" />
      </providers>
    </localization>
    episerver.framework>

    Looking at web.config <globalization> element as far as I remembered <asp:Literal> (Asp.Net built in localization providers) are dependant on these settings. So it means that Literal should return localization for "en" culture always. Try to set to "auto" and see what happens:

    <globalization culture="auto" uiCulture="auto" requestEncoding="utf-8" responseEncoding="utf-8" resourceProviderFactoryType="EPiServer.Framework.Localization.LocalizationServiceResourceProviderFactory, EPiServer.Framework" />
    #119526 Mar 29, 2015 6:52
  • GOSSO
    Member since: 2007
     

    When i Changed to auto in web.config Literal is always in swedish.

    And the change in EPiServerFramewotk.config didn-t change any.

    This is weird. remember i do set the culture in OnInit in masterpage, i shouldn't do that at all i think, but ...

    when i tried override InitializeCulture() on page it helped. But should i override all my 250 aspx templates? (or in a base class) is that right way?

     protected override void InitializeCulture()
            {
                var culture = CultureInfo.CreateSpecificCulture(EPiServer.Globalization.ContentLanguage.SpecificCulture.TwoLetterISOLanguageName);
    
                CultureInfo.DefaultThreadCurrentCulture = culture;
                CultureInfo.DefaultThreadCurrentUICulture = culture;
    
                System.Threading.Thread.CurrentThread.CurrentCulture = culture;
                System.Threading.Thread.CurrentThread.CurrentUICulture = culture;
    
                base.InitializeCulture();
            }
    #119527 Edited, Mar 29, 2015 14:02
  • valdis iljuconoks
    Member since: 2011
     

    Another question: when you are referring to "Swedish" site, do you mean to access site by address (host name) that is mapped to sweden culture or you access the same site when somehow selected content language is switched to "sv"?

    Answering your initial question: you shouldn't override culture initialization. But if would need - I would definitely go for base class.

    #119528 Mar 29, 2015 14:34
  • GOSSO
    Member since: 2007
     

    No it is on the same top domain, just switching url and cookie value. Any other idea? yes i shouln't have to override culture initialization. hmm

    #119529 Mar 29, 2015 14:55
  • valdis iljuconoks
    Member since: 2011
     

    Do you have strickLanguageRouting attribute on <applicationSettings> element? Which cookie you change and what you do this cookie value if it's your own custom cookie?

    #119591 Mar 30, 2015 17:14
  • GOSSO
    Member since: 2007
     

    No strictLanguageRouting, can-t find it on http://world.episerver.com/Documentation/Items/Developers-Guide/EPiServer-CMS/75/Configuration/Configuring-episerver/

    In web.config, i do have strictLanguageRouting = false, we want it that way.

    yes, we do have our own implementation of cookie, named "holmenlang", in a base class of the page, if that not set, we use browser default.

    #119593 Mar 30, 2015 23:11
  • valdis iljuconoks
    Member since: 2011
     

    I setup similar project structure and behaviour as you have, but can't reproduce your issue.

    Can you try to put Thread.CurrentUICulture and .CurrentCulture in header, body, footer controls to see if there is some code that sets and unsets these cultures without notifying you. I'm speculating here but looks like maybe cookie handling code could manipulate something. Just curious what are culture settings in each phase of page rendering. Because both literal, translate and direct access to localization service should work correctly at the same time.

    #119599 Mar 31, 2015 10:49
  • valdis iljuconoks
    Member since: 2011
     

    Or also you try me drop a project you have (just problematic page(s)) - it's much easier to understand issue in VS than trying to compline case in head ;)

    #119795 Apr 02, 2015 15:12
  • GOSSO
    Member since: 2007
     

    Hey Valdis Iljuconoks

    by changing

    legacy EPiServer.Web.UrlRewriteModule to EPiServer.Web.RoutingUrlRewriteModule

    in web.config  <modules runAllManagedModulesForAllRequests="true">

    AND Removing legacy EPiServer.Web.FriendlyUrlRewriteProvider from UrlRewriter in episerver.config

    It seemes that the localization is now working as it should. I have removed "override InitializeCulture()" too.

    I had a lot of legacy configuration in web.config which cause a lot of problem. I will reevaluate my configs.

    Thanks for all help.

    #120311 Apr 14, 2015 23:05
  • valdis iljuconoks
    Member since: 2011
     

    Hm... interesting. I would recommend to take a look and compare configs from sites created purely in new version. Legacy stuff may just mess air and hard to diagnose..

    #120312 Apr 14, 2015 23:09