This question is half translation-related and half-developer related but I am posting it on Localization anyway.

I am aware of the following:
1. Resource files can be used to translate code (which is very necessary since we are using multiple custom-built modules developed in-house)
2. Multi-sites can be used to translate data of module instances (e.g. the HTML content differs so we can read and modify different content)

This is all well and useful. But the provision of translation (culture) switching is exclusively controlled either by two settings:

1. By the default culture setting for all sites, e.g. the globalization tag in web.config -- http://lucasnovae.blogspot.com/2009/03/tutorial-multilingual-mojoportal.html
2. By overrides for a specific site, e.g. site X uses culture Y -- http://www.mojoportal.com/localization.aspx

These features all depend on users having to set their default culture in the browser.
http://www.mojoportal.com/settingbrowserlanguagepreferences.aspx

Although this is "quite" conventional and one can argue it is a standard browser feature, there are some problems:
1. Some users may not have permissions to modify IE/browser settings (due to security policies)
2. Some browsers may be stripped down (e.g. web kiosks)
3. Most users do not dare to change configuration settings (they are not experts or the computer is not theirs)
4. Most users do not know what "browser configuration" is (this is a big one)

There is in fact another convention established which is far more accepted and used globally: on the web site, there are entry links for each languages, and there are language links on every page to switch language. Then, the language will be remembered for this user. And even better, specific users can be greeted in their own language when they return once they have created their own profile. In Hong Kong, for example, it is very conventional for official sites to have cross-links links to three languages: English, Traditional Chinese and Simplified Chinese. That can be done with multiple sites. But as soon as users can create profiles, the system will not remember the culture and they have to click again.

Since we do not want to depend on users having to set some specific bookmark (to adhere to multi-site) or user persistent cookies (there are privacy concerns), the server should be expected to remember and handle everything -- once the users have sign in. Thus, every user profile should remember their culture setting after login, and then redirect to the correct site.

So, what I would like to do is, to first create a custom profile property, which is the culture:
http://www.mojoportal.com/userprofileconfiguration.aspx

Then, I need to somehow hook up to, at least the sign-in event, but also any event that changes the profile (e.g. reconfig) and then override the culture of the current thread automatically so that it uses the profile. Or alternatively, at every single page load, the system must check whether the user has a culture setting (perhaps it can be cached) and then override the thread's culture setting.
(User profile customization reference: http://www.mojoportal.com/userprofileconfiguration.aspx)

Thus,
1. If a user has a custom culture defined, it is used as the first preference
2. If a user does not have a custom profile, it defaults to the culture of the site
3. If the site does not have a profile, it uses the web application's setting

Level 2 and 3 exist but level 1 is missing.

Seems there is no extension point in the system. Would you suggest a custom hack/patch of checking for a custom property in the user profile at page load? This is my first thought, it seems to fit quite properly into the architecture but could also be a nice general feature.

Ok, agree. My question is: how to force a language/culture based on a user's custom profile setting (the MojoPortal profile)?

Sorry but I politely wish to disagree. Please be aware that I am looking on this problem from a developer perspective. It is easy to tell end users with no development skills to create multiple sites and type a lot of text, but as a developer I hate to repeat myself in terms of re-specifying the same layout which is over-redundant when the only thing I want to change is string resources. The problem is aggravated the more cultures you add (you are effectively advocating an expotential growth of "sites" that are spawned for localization purposes the more "fundamental" sites there are) and the less non-string differences there are. In our case, users would be happy with no change in layout or style whatsoever.

Why wouldn't it be nice to let the web site remember the language and culture profile of a user?

There are many use cases I experienced myself, e.g. using web kiosks, using hotel PCs, using a friend's PC, all cases where the browser and OS language is different from the USER. Millions of people are in these situations. Think of logging in to your e-mail account from a hotel PC in France. The browser/OS is French, but you want it to display in English, right? And surely they blocked the browser control panel. There is so much culture-dependant code that must work based on who the user is, e.g. date formatting, time formatting, when listing e-mail messages.

Ultimately the problem is an impedance mismatch between the three models of localization:

1. Database-based (e.g. "sites", "pages" etc)
2. Resource-based (resx)
3. Framework-based (e.g. formatting, currencies)

Even with a good effort, we always end up with half-baked solutions, e.g. an English site displaying French dates or vice versa when these models mix together.

Fundamentally the best solution would be to be able to use resource files in the pages themselves. I really want to fork out a simple hack to the source code to enable this. Specifically, every time there is an opportunity to enter something which becomes HTML, e.g. a page title, or HTML control content, the system should automatically interpret and inject thread culture-aware resource tags which comes from RESX, as in standard .NET practice. The standard tag is: <%$ Resources:MyResource, MyResourceKey%>.

So instead of typing "Home", "News", "Forum", etc. at the header and then copying the whole site, I gradually migrate by replacing english terms with resource tags. There could also be a feature to auto-migrate all static strings to a resource file to get started easily, which could give nice keys, e.g. Page_Control_CamelCaseAbbreviation or something.

OR: alternatively, for every "string" field, you allow culturally sensitive options to be specified, in the database level. E.g. instead of directly storing a string, you store a resource key. Thus, the site needs to have a resource manager.

Then, there would be a hierarchy of preference overrides on the thread culture, e.g. by-profile (not avilable!), by-browser (OK now), by-site (OK now by forced web.config override), or even by-page.

From a coding viewpoint, the portal system should make thread culture the primary way to translate a site and move away from the data-centric orientation on some specific tables. It is the only reliable and fully framework-supported way to ensure that translation is nested down to any level of call depth in any controls. I would consider the database-based approach as a "draft" of a web site before globalizing it. I have tonnes of re-used DLL assemblies across various controls on the page, visited by multiple threads of multiple users. The thread culture is really my only friend in ensuring the correct behavior.

Hello Joe,

Thank you for all suggestions.

Surely we would not accept only translating buttons and labels. The translation should cover all resources of all types and their integration. We are also amending some of the supplied language resource files in mojoPortal for this purpose, if we come up with something useful we may share it. 

The reason why thread culture is quite important is because we use mojoPortal as a "WinForms for ASP.NET", with all of the basics for building a web application, supplemented with advanced web controls, actually, it is a highly unorthodox use of a CMS system but it does save tonnes of time. For text-heavy content, I would agree completely with the approach to split sites (publishing-oriented, documentation-oriented usage) as most of the work is to actually create the content, but in our case, each page on the whole site only contains one single instance of a custom control. Within these controls, everything is resource-file based and carefully crafted for handling any language generically -- far more than "buttons and labels" -- just as in a standard localized WinForms application. So, a mojoPortal page is mainly a metaphor for a "Form" or "Application Window" in WinForms.

Your suggestion to write a custom menu bar is excellent, it would be ideal if it could be populated through some API or specified by means of a general tree editor. The only feature that can build trees now in the mojoPortal system is the page creation, which allows a hierarchy, which is why it is an ideal data source for a menu bar structure. Then, our users can amend the menu themselves in the "application", like participative programming. One could have a skin with menu bars that are generated from the database or so. But it is redundant to store the structure more than once since only the text changes. In the case of this structure, the translation is only about text, really. There is no point in changing the menu structure for any language, no serious application vendor does this anyway (just look at Windows and Office, the localization never changes the structure, only resources, e.g. strings, and their appearance, e.g. right-left, etc), the position of elements is the same in all cultures.

In our case it would seem best to create one site per-language and then force the thread culture for each site.

Your suggestion to use a dropdown list to select a culture based on a cookie would not meet the requirement to remember a user since it will not remember the culture if the user logs in from another machine or the cookie is deleted. The setting should be stored on the server, persistent, per-user, like a roaming profile. Surely if only the thread culture changes and the page content does not, it is half baked, no doubt. But if the dropdown list ensures that, upon re-logon or changed setting, the site can redirect to the start page of another site with the correct culture of the db content, and as long as the site has the correct forced culture setting, all will be well and we can reach 100% localization. So the dropdown list component would have to update the custom profile property and redirect upon change.

For developers who have special requests, you could provide convenient event hooks in the framework, e.g. in the page cycle and data layer, and let developers attach to these. For example, there can be an event hook that reports any string coming from the db "about to be rendered". If any extension registers for it, it can implement anything it wants, like my suggested resource injection, and then return the processed string.

Yes, this helps, the menu bar binding should do the trick. I get the idea of why we need a separate resource file for this. My point about the MojoPortal resources is that we are plugging gaps of missing strings in the official translations of the out-of-box features so it might be of general use.

We already implemented the custom user profile property using the method you stated, works fine. The next challenge is to create a custom HTTP module.  Do you have any general links, tutorials or guidelines or ideally some empty sample template to recommend for doing this in the mojoPortal environment?

Thanks a lot

<add name="UserSettingCultureHelperHttpModule" type="CustomCultureForUser.UserSettingCultureHelperHttpModule, CustomCultureForUser" preCondition="managedHandler" />

I forgot the config for the handler. It has to added in ADDITION to the existing culture handler (not replace the existing)

Thus,
1. If a user has a custom culture defined, it is used as the first preference
2. If a user does not have a custom profile, it defaults to the culture of the site
3. If the site does not have a profile, it uses the web application's setting

Technically, it will first determine the culture in 3. Then it will invoke the mojoportal ihttphandler, which will do 2, thereby possibly overwriting the culture. And then it will run my ihttphandler, possibly overwriting the culture if the user has a setting for it. So in various stages of the request, it may end up with 3 different cultures. In reality this approach just makes the implementation simpler and works perfectly.