13.4. Client-Side Culture Details
When working with culture on the client side, the culture that is used is the culture that is defined on the server. Therefore, if you have the culture set to en-US on your server, this is the default that is utilized on the client-side operations as well. Consider the example presented in Listing 13-8.
Example 13-8. Viewing dates with a culture setting as set on the server
<%@ Page Language="C#" %>
<%@ Import Namespace="System.Globalization"%>
<script runat="server">
protected void Page_Load(object sender, EventArgs e)
{
Response.Write("Date from the server before setting culture: " +
DateTime.Now + "<br />");
System.Threading.Thread.CurrentThread.CurrentCulture =
new CultureInfo("ru-RU");
Response.Write("Date from the server after setting culture: " +
DateTime.Now);
}</script>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title></title>
<script type="text/javascript">
function pageLoad() {
var date = new Date();
$get('Label1').innerHTML = "Date after setting culture on the client: "
+ date.localeFormat("D");
alert(String.localeFormat("{0:dddd, dd MMMM yyyy hh:mm:ss tt}",
new Date()));
}
</script>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:ScriptManager ID="ScriptManager1" runat="server"
EnableScriptGlobalization="true" />
<span id="Label1"></span>
</div>
</form>
</body>
</html> |
First off, to work with setting the culture on the server, you need to import the System.Globalization namespace. The first thing that the page does from Listing 13-8 is write out the server's date and time to the page using a simple Response.Write() statement. After this, the culture is changed from the server default to a new culture of ru-RU (this is the Russian culture) and then the date and time is again written to the page using the same Response.Write() statement.
Now that the culture of the page has been set to ru-RU, even though it started as en-US (in this case), ru-RU will be the culture that is utilized on the client. This page contains a JavaScript function called pageLoad(), and in this function the Label1 control is populated with the date and for good measure, an alert is thrown with the date and time again.
You will notice that the JavaScript output are also done in Russian using the ru-RU culture as it is set on the server. The result of this is presented here in Figure 13-6.
The only way to make this work is to enable globalization on the client, and this is done through the EnableScriptGlobalization attribute of the ScriptManager server control. In this case, you set the values of both of these attributes to true.
<asp:ScriptManager ID="ScriptManager1" runat="server" EnableScriptGlobalization="true" />
Figure 13-6. Figure 13-6
However, how do you set the culture on the client to what the end user expects? For instance, suppose that the culture on the client is set to fi-FI as is shown earlier in Figure 13-5. It is one thing to set it to a specific culture as shown in the previous example (e.g. ru-RU), and it is possible to provide end users with a drop-down list for setting their language and culture preferences when working with your application. Nevertheless, what if you wanted to grab the culture of the end user without asking them to make any selections? In this case, you use the Request.UserLanguages[] option.
When a request is made to your Web application, the culture options of the requestor are found in the HTTP header. For instance, here is an example HTTP header:
GET /WebSite1/Default.aspx HTTP/1.1 Accept: */* Accept-Language: fi-FI,en-us;q=0.5 UA-CPU: x86 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; Zune 2.5; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Host: localhost.:2972 Connection: Keep-Alive Pragma: no-cache
You will notice that the highlighted line in this header is an ordered list of specific cultures that the end user has configured on their machine. In this case, there are two cultures set. The first one is fi-FI (for Finnish as spoken in Finland), and the second one is en-US (for English as spoken in the United States).
From this, you are able to take first setting in the ordered list and set that as the page's culture. An example of this is presented in Listing 13-9.
Example 13-9. Setting the culture to the client's culture
<%@ Page Language="C#" %>
<%@ Import Namespace="System.Globalization"%>
<script runat="server">
protected void Page_Load(object sender, EventArgs e)
{
Response.Write("Date from the server before setting culture: " +
DateTime.Now + "<br />");
System.Threading.Thread.CurrentThread.CurrentCulture =
new CultureInfo(Request.UserLanguages[0]);
Response.Write("Date from the server after setting culture: " +
DateTime.Now);
}
</script>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title></title>
<script type="text/javascript">
function pageLoad() {
var date = new Date();
$get('Label1').innerHTML = "Date after setting culture on the client: "
+ date.localeFormat("D");
alert(String.localeFormat("{0:dddd, dd MMMM yyyy hh:mm:ss tt}",
new Date()));
}
</script>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:ScriptManager ID="ScriptManager1" runat="server"
EnableScriptGlobalization="true" />
<span id="Label1"></span>
</div>
</form>
</body>
</html> |
In this case, the culture is set to the client's culture as is passed in by the HTTP header. If the previous header example is utilized, then the end result of this request is presented in Figure 13-7 (in my case, my culture is set to en-US).
Figure 13-7. Figure 13-7
