This project is read-only.

Culture and UICulture Problem

Mar 31, 2009 at 7:00 AM
Hello guys,
I'm trying to support multi-language in my site. Everything works fine before I try to get resource from a global resx file. 
First of all, I set en-GB as my prefered browser language and then accessed the site root node, Culture/UICulture is set to en-GB correctly. However, if I go to a page under any language roots, the Culture/UICulture will be set to "zh-CN". Is it a bug or designed to be like this?
Any help would be appreciated.
Mar 31, 2009 at 7:03 PM
Take a look at this code

It runs on every request and sets the culture to the current branch language.

So, yes. It's designed to work that way. Does it cause problems?
Mar 31, 2009 at 9:28 PM
Thank you for help.
"So, yes. It's designed to work that way. Does it cause problems?"

Yes because I need to get some globalization strings from resx files in the aspx page, and the incorrect culture/uiculture lead to incorrect globalization strings.
Hmm, I'm not very clear why don't N2 set the culture/uiculture automatically? Because when the user is viewing for example an en-GB page, he/she should see everything in en-GB. Besides, my browser prefered language has been set to en-GB, the server should think that this is an en-GB client requesting for a page, and then set culture/uiculture to en-GB automatically (which happens correctly when I access the site root). However, culture property of pages under any language root will be set to "zh-CN" (I guess it's done by N2), it's weird. Because it is a en-GB client accessing the page, where do we get this zh-CN culture?

"Take a look at this code"
Thanks, this works. Just wondering how does it work? Does it mean that N2 will search in the assembly and get every class that implements IPageModifier, Then execute them automatically?
Apr 1, 2009 at 7:00 PM
Yes, the code is executed automatically.

To be more specific. What really happens is that the templates project implements a "plugin initializer" that is invoked on startup. This in turn defines a TemplatePageModifier which is resolved by the TemplatePage base class. The TemplatePageModifier that contains a list of "modifiers" and the langueage modifier among them.

I'm not convinced that this is weird. I think it makes sense to change the culture to the same language of the branch since the rest of the content is translated into that language.
Apr 2, 2009 at 4:59 AM
Yes it makes sense to change the culture to the same language of the branch. That's exactly what I want. Sorry I should have explained it more clearly:
I have 2 language roots, zh-CN and en-GB, and several pages under each root.
1. When I access the root of the language roots, the culture is set depends on the client prefered language. This is correct.
2. When I access pages under zh-CN root, the culture is set to zh-CN, this is also right.
3. When I access pages under en-GB root, and my client side prefered language is set to en-GB, the page's culture is still set to zh-CN. This is what I think weird.