0

I've been working on my first localization project for mvc and have been using the excellent Griffin.MvcContrib to get me started.

I've using the Griffin to handle the language change and the page views, and have a custom provider setup to handle the models and validation through database resources.

The validation is done with FluentValidation like the following:

RuleFor(x => x.Bin)
    .Length(0, 50)
    .WithMessage(localizationService.GetResource("Inspection.Bin.Length"));

Everything seemed to work great until I realized that server side errors were not being translated, only the client side ones. After a lengthy investigation it seems to me the issue is that the thread culture is being set after the server side validation is done - I believe the same thing that was happening in this other post:

MVC3 globalization not set for ModelState.Value.Culture

What I did to get it working so far is just to place the following in the Global.asax file.

protected void Application_BeginRequest(object sender, EventArgs e)
        {
            string CookieName = "GriffinLanguageSwitcher";

            HttpContextBase currentContext = new HttpContextWrapper(HttpContext.Current);

            if (currentContext.Request.Cookies[CookieName] != null)
            {
                Thread.CurrentThread.CurrentCulture =
                    Thread.CurrentThread.CurrentUICulture =
                        new CultureInfo(currentContext.Request.Cookies[CookieName].Value);
            }
        }

It seems to work. I'm not worried about validation when a user switches their language, and it now seems to pickup the current language and translate the server side errors.

But is this an acceptable way of fixing this issue, or should I be doing something else. Thanks.

Community
  • 1
  • 1
TomZomW
  • 531
  • 1
  • 5
  • 15
  • 1
    I noticed this too. I'll probably add a HTTP module which sets the cookie instead. – jgauffin Jan 04 '13 at 10:26
  • Thanks for the reply jgauffin. I did look for some extension method I could call or something to avoid duplicating your code but couldn't find anything.I'm still just learning how to use Asp.net MVC, so I just wanted to be sure what I did wasn't a really bad choice for fixing the problem, or that I wasn't using the Griffin.MvcContrib wrong. If that's the case, I'll leave what I have for now since it works and doesn't seem to break anything, then grab your update at a later date. – TomZomW Jan 04 '13 at 14:49

0 Answers0