locked
Localization after a response.redirect RRS feed

  • Question

  • User-1524046683 posted

    I am writing an application that has several forms in it.

    Each form has its own local resource for French and English translation for my controls.  I set the language and culture programmatically using the following code:

    protected void SetLocalization(string strLangCult)
    {
    CultureInfo newCulture;

    newCulture =
    new CultureInfo(strLangCult);
    Thread.CurrentThread.CurrentCulture = newCulture;
    Thread.CurrentThread.CurrentUICulture = newCulture;

    }

    Everything works fine for the main page but when I go to another page using Response.Redirect("page2.aspx") I can't seem to set the culture and it defaults back to en_US again.

    I've ensured that both Culture="auto" and UICulture="auto" are removed from the page and I am setting the culture in the same way as I do in the main page (which works). I've even tried saving "newCulture" to my session and pulling it out in the other page and using that to set my culture .... same result ... I always get the default en-US culture EVEN THOUGH  Thread.CurrentThread.CurrentCulture says it is set to fr-FR

    Any ideas?

     

     

    Tuesday, June 19, 2007 1:47 PM

All replies

  • User160031809 posted

    I think you should  set CultureIndInfo in PreInit event, try it

    and here is the link about

     ASP.NET page life cycle :http://msdn.microsoft.com/en-us/library/ms178472.aspx

    Tuesday, June 19, 2007 2:54 PM
  • User-1524046683 posted

    Sorry, I should have stated that I am calling this routine from the Page_PreInit.  I am therefor effectively setting the culture from Page_PreInit

    protected void Page_PreInit(Object sender, EventArgs e)

    {
    .
    .

    SetLocation(strLangCulture);

    .
    .
    }

    I even went so far as to create a brand new form and only put in a label with two resource files (the webform3.aspx.fr-FR.resx and webform3.aspx.resx)

    Within this new form I am ensuring that the fr-FR cultureinfo object is being passed into Thread.CurrentThread.CurrentCulture and Thread.CurrentThread.CurrentUICulture from within the Page_PreInit event and I made certain that there was no automatic culture of language specified in the page directives .... STILL I am getting data from webform3.aspx.resx instead of webform3.aspx.fr-FR.resx. 

    The only thing I can think of is that it has something to do with the fact that I am calling webform3 via a Response.Redirect

    I'm at a loss here.

    Tuesday, June 19, 2007 3:12 PM
  • User1831056148 posted

    Hey did you ever solve this?  I have exact same issue now.  Switching culture on thread works fine.  However, if I introduce a Response.Redirect, I always get en-US.  

    Anyways, if you know the answer, would appreciate a nudge in the right direction.   

    Friday, December 17, 2010 1:10 AM
  • User-519136805 posted

    Hi Joel.holder,

    The call to Response.Redirect forces a new round-trip from the browser to the Web server, which causes the lifecycle of the page to start again after the profile property has been set up with the desired language preference.

    The next thing you have to deal with is programmatically adjusting the culture setting at the appropriate time in the page lifecycle. The proper way to do this in ASP.NET 2.0 is to override a method of the Page class named InitializeCulture. The page lifecycle has been designed to always call InitializeCulture before the page itself or any of its child controls have done any work with localized resources.
    The design of the sample site requires that you add an overridden implementation of InitializeCulture to every page in the site.

    Unfortunately, you can't override the InitializeCulture method at the level of a Master Page because the MasterPage class does not inherit from the Page class. Furthermore, it would be tedious to override the InitializeCulture method separately for every page in a Web site. This would lead to many redundant implementations that would pose a serious maintenance issue.

    A more efficient site-wide approach to initializing culture settings is to create a common Page-derived base class and then have all your .aspx page files inherit from that, and that's what I did in the LitwareWebApp sample site. My Page-derived base class named LitwarePage (see Code snippet) was defined in a source file named LitwarePage, which was added to the App_Code directory so that it is automatically compiled by ASP.NET and made available to other code in the current Web site.

    Imports System.Globalization
    Imports System.Threading
    
    Public Class LitwarePage : Inherits Page
    
        Protected Overrides Sub InitializeCulture()
    
            ‘*** make sure to call base class implementation
            MyBase.InitializeCulture()
    
            ‘*** pull language preference from profile
            Dim LanguagePreference As String = _
                CType(Context.Profile, ProfileCommon).LanguagePreference
    
            ‘*** set the cultures
            If LanguagePreference IsNot Nothing Then
                Me.UICulture = LanguagePreference
                Me.Culture = LanguagePreference
            End If
    
        End Sub
    End Class
    

    Once you've created a Page-derived base class, you can update your .aspx page definitions to derive from it instead of from the standard Page class. For example, you can modify the partial class in default.aspx.vb to look like this.

    Partial Class _Default : Inherits LitwarePage
        '*** page class definition goes here
    End Class
    

    Hope this will helps Laughing

    Monday, December 20, 2010 4:20 AM
  • User-247361238 posted

    try call base.InitializeCulture() after setting ur new culture

    protected void SetLocalization(string strLangCult)
    {
    CultureInfo newCulture;

    newCulture = 
    new CultureInfo(strLangCult);
    Thread.CurrentThread.CurrentCulture = newCulture;
    Thread.CurrentThread.CurrentUICulture = newCulture;
     
    base.InitializeCulture();

    }

    Thursday, December 23, 2010 4:57 AM