This doesn't seem like a bug to me as much as a misunderstanding of the page lifecycle with master pages. By the time code in your "language changed" event is executed, your controls have already been populated so any programmatic change you do to culture
and cultureui at this point is lost. It's sort of a chicken and egg thing. You need to have your controls to know that the language was changed, but you can't change the language after the controls have been populated. The link above gives a workaround
that works, but is a little convoluted, but the way that's shown in the QuickStarts (http://quickstart.developerfusion.co.uk/QuickStart/aspnet/doc/localization/localization.aspx#langprefs)
seems a little more straightforward.
To summarize what they do in the QuickStart: When language change event is fired, they store the new language preference in Profile, then force a redirect back to the page using Response.Redirect. They have overridden InitializeCulture
in the Page class to check Profile for a preferred language, if it's there, it is used. So, when the user changes languages, the browser actually makes two trips - one to set the new preference via the event, and one to reload the page using the new preference.
How this could be used with Master Pages: Obviously if you're using master pages, you probably don't want to have to overload the InitializeCulture on each and every page. However, the master page is actually a control without an InitializeCulture
override. So, what you could do is subclass Page with maybe a "LocalizedPage" class, override it's InitializeCulture method, then subclass from that in each of your pages. You could have your overridden InitializeCulture method check Profile, Session, Cookies,
or whatever you want to see if there's a user preference. If there is, set your culture and cultureui to it (there's code for that floating around all over the place). In your language change event, you'd just populate the Profile, Session, or whatever and
then force a redirect back to the current page to make the changes visible.
jdcrutchley
Member
252 Points
63 Posts
Re: MasterPages Localization/Globalization & resources issue
Mar 22, 2006 05:00 PM|LINK
This doesn't seem like a bug to me as much as a misunderstanding of the page lifecycle with master pages. By the time code in your "language changed" event is executed, your controls have already been populated so any programmatic change you do to culture and cultureui at this point is lost. It's sort of a chicken and egg thing. You need to have your controls to know that the language was changed, but you can't change the language after the controls have been populated. The link above gives a workaround that works, but is a little convoluted, but the way that's shown in the QuickStarts (http://quickstart.developerfusion.co.uk/QuickStart/aspnet/doc/localization/localization.aspx#langprefs) seems a little more straightforward.
To summarize what they do in the QuickStart: When language change event is fired, they store the new language preference in Profile, then force a redirect back to the page using Response.Redirect. They have overridden InitializeCulture in the Page class to check Profile for a preferred language, if it's there, it is used. So, when the user changes languages, the browser actually makes two trips - one to set the new preference via the event, and one to reload the page using the new preference.
How this could be used with Master Pages: Obviously if you're using master pages, you probably don't want to have to overload the InitializeCulture on each and every page. However, the master page is actually a control without an InitializeCulture override. So, what you could do is subclass Page with maybe a "LocalizedPage" class, override it's InitializeCulture method, then subclass from that in each of your pages. You could have your overridden InitializeCulture method check Profile, Session, Cookies, or whatever you want to see if there's a user preference. If there is, set your culture and cultureui to it (there's code for that floating around all over the place). In your language change event, you'd just populate the Profile, Session, or whatever and then force a redirect back to the current page to make the changes visible.