I know I can set the Culture to what I want, but shouldn't the current
culture be taken from the regional settings on the web server's
control panel!!!
I'm not sure exactly what you want, but what we do (in Page_Load()) in
our ASP.Net applications - which I believe will give the effect you
want - is this call to a routine we wrote specifically to enable easy
multi-language/multi-date-format/etc:
UIUtilities.setCulture(Request);
Where this is what gets called:
/// <summary>
/// Set the display culture for the current thread to the most
appropriate culture from the user's incoming Http "request" object.
/// </summary>
/// <param name="request"></param>
internal static void setCulture(HttpRequest request)
{
if (request != null)
{
if (request.UserLanguages != null)
{
if (request.UserLanguages.Length > -1)
{
string cultureName =
request.UserLanguages[0];
UIUtilities.setCulture(cultureName);
}
}
// TODO: Set to a (system-wide, or possibly
user-specified) default culture if the browser didn't give us any
clues.
}
}
/// <summary>
/// Set the display culture for the current thread to a particular
named culture.
/// </summary>
/// <param name="cultureName">The name of the culture to be set for
the thread</param>
private static void setCulture(string cultureName)
{
Thread.CurrentThread.CurrentCulture =
CultureInfo.CreateSpecificCulture(cultureName);
Thread.CurrentThread.CurrentUICulture = new
CultureInfo(cultureName);
}
What this does is that the thread that processes the output (and
input) for that user for the page is AUTOMATICALLY set for the
appropriate culture (eg for date input/output) for that user. It uses
a header which is sent automatically by the browser (4.0 and later -
works fine with Firefox/Mozilla too), so the user of your ASP.Net
application doesn't have to separately select a language/culture
preference in the application.
NB: You can change this setting for testing (in IE for example) by
going to Tools/Internet Options/Languages, then adding the language
you want to test and moving it to be the first/top one.
Because it is per-user, rather than being based on a server setting,
it is a lot more flexible as far as being "world-ready".
FWIW we use the same browser header to work in with the
ResourceManager mechanism to provide other-language text in the output
web pages too, simply by doing the following after the call to set the
thread culture to the right one for the user:
ResourceManager resourceManager = new
ResourceManager("AppName.strings", typeof(SampleForm).Assembly);
(then using ctrl.Text = resourceManager.GetString("NameOfItem") as
normal)
The net effect of all this is that a user who wants dates the "right
way" around (I'm an Australian) for output and input validation will
have the page work that way, and someone who prefers MM/DD/YYYY will
in turn have that work for their input/output WITHOUT you having to do
anything hardwired in your code, or forcing users to select a
language/culture preference for your app in their logon details.
ted.h.
you for your service.