Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

navigator.language value is not reflected in CultureInfo.CurrentCulture #118

Closed
vgribok opened this Issue · 4 comments

3 participants

@vgribok

Using 0.7.3.

I switched OS locale to Russian, restarted Chrome and it dutifully switched its UI to Russian. I used Chrome Debugger to check values of navigator.language and it's not matching CurrentCulture. I am not sure if it's by design, by it's not intuitive. Using System.Html.Navigator is a fallback.

@nikhilk
Owner

Your server has to read the HTTP_ACCEPT_LANG as a result of the OS/browser switch and respond accordingly by including russian culture info (which isn't included out-of-the-box with script# as of right now ... in otherwords, its has globalization support, but doesn't have localization) that overwrites current culture.

If that isn't done, current culture remains pointed at the neutral culture.

@nikhilk nikhilk closed this
@vgribok

It does not seem logical to require a round trip to the server for a piece of data that is already available on the client. I'd think this is a minor one, but it's not a non-issue and IMO should not have been closed.

@mattclay

Script# only includes the invariant culture "out of the box", which is en-US. If you want other culture(s) available on the client, you'll need to create JavaScript file(s) to provide them.

You can download the T4 template I use to export .NET culture information here: http://www.box.net/shared/rfbm9dpjtt8t9yvs9ziq

This template generates whatever cultures you want into a single file. If used as-is, you'll need to switch cultures on the client by assigning the relevant culture from the T4 output to CultureInfo.CurrentCulture. If you load a single culture file when your page loads, you won't need another round-trip to the server and you can switch cultures at runtime. The downside is that you have to send all cultures to all clients, so you may want to download individual culture files on demand and let the browser cache them.

There are various ways to set the culture once you have culture data. I use a class in an import library to write CurrentCulture since the property is get only.

using System.Globalization;
using System.Runtime.CompilerServices;

namespace Iris
{
    [ScriptNamespace("ss")]
    [Imported]
    [ScriptName("CultureInfo")]
    public static class IrisCultureInfo
    {
        [PreserveCase]
        [IntrinsicProperty]
        public static CultureInfo CurrentCulture { get; set; }
    }
}

Feel free to modify and use the template and code however you'd like.

@nikhilk
Owner

As Matt described, there isn't a need for a roundtrip. The server should include the script when the page is requested to override the default CurrentCulture value.

Here is why the server is involved ... first because you really don't want to download information for all cultures down to the client from a size perspective. Secondly you might on the server want to have a whitelist of supported cultures... and consequently it is the job of the server to find the best matching culture given the HTTP_ACCEPT_LANG value and the list of supported cultures.

The logical place to fit this functionality (at least for out-of-box experience) into would be in the script# server framework (that works for asp.net mvc apps) ... part of https://github.com/nikhilk/scriptsharp/tree/master/src/Runtime/Server ... for non-asp.net scenarios, the idea would be to provide small scripts for different cultures, and allow app developers to include as they see-fit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.