Comments on: Localizing MVC for ASP.NET views and master pages http://damieng.com/blog/2008/04/27/localizing-mvc-for-aspnet-views-and-master-pages?utm_source=rss&utm_medium=rss&utm_campaign=localizing-mvc-for-aspnet-views-and-master-pages A .NET developer in silicon valley Fri, 18 May 2012 15:31:00 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Damien Guard http://damieng.com/blog/2008/04/27/localizing-mvc-for-aspnet-views-and-master-pages#comment-9806 Damien Guard Thu, 23 Oct 2008 17:14:47 +0000 http://damieng.com/?p=906#comment-9806 That may well be the case, the article is rather old. I will try to revise it or mark it as obsolete. Thanks, [)amien That may well be the case, the article is rather old. I will try to revise it or mark it as obsolete. Thanks,

[)amien

]]> By: Kevin Rotkiske http://damieng.com/blog/2008/04/27/localizing-mvc-for-aspnet-views-and-master-pages#comment-9804 Kevin Rotkiske Thu, 23 Oct 2008 15:50:29 +0000 http://damieng.com/?p=906#comment-9804 i dont think this is applicable in the preview 5 release. i dont think this is applicable in the preview 5 release.

]]> By: Damien Guard http://damieng.com/blog/2008/04/27/localizing-mvc-for-aspnet-views-and-master-pages#comment-9796 Damien Guard Wed, 22 Oct 2008 20:10:58 +0000 http://damieng.com/?p=906#comment-9796 @Kevin: They are defined and called by the parent class (ViewLocator) [)amien @Kevin: They are defined and called by the parent class (ViewLocator)

[)amien

]]> By: Kevin Rotkiske http://damieng.com/blog/2008/04/27/localizing-mvc-for-aspnet-views-and-master-pages#comment-9795 Kevin Rotkiske Wed, 22 Oct 2008 20:00:44 +0000 http://damieng.com/?p=906#comment-9795 I don't understand how the variables in the constructor could work. they are never called in the code. The ViewLocationFormats and MasterLocationFormats variables are not passed to the other routines and are not properties of the base class. Am I missing something? I don’t understand how the variables in the constructor could work. they are never called in the code. The ViewLocationFormats and MasterLocationFormats variables are not passed to the other routines and are not properties of the base class. Am I missing something?

]]> By: Weekly Links: ASP.NET MVC, Silverlight 2, jQuery, CSS, C#… | Code-Inside Blog International http://damieng.com/blog/2008/04/27/localizing-mvc-for-aspnet-views-and-master-pages#comment-8367 Weekly Links: ASP.NET MVC, Silverlight 2, jQuery, CSS, C#… | Code-Inside Blog International Mon, 28 Apr 2008 19:23:41 +0000 http://damieng.com/?p=906#comment-8367 [...] Localizing MVC for ASP.NET views and master pages [...] [...] Localizing MVC for ASP.NET views and master pages [...]

]]> By: Steve http://damieng.com/blog/2008/04/27/localizing-mvc-for-aspnet-views-and-master-pages#comment-8365 Steve Mon, 28 Apr 2008 14:31:13 +0000 http://damieng.com/?p=906#comment-8365 Ah ok. I think this just reflects differences in the application type & development workflow - the apps I worked on consisted of many hundreds of individual views (complex web-based TP application with a huge variety of transactions & screens) so of course a designer was never going to be involved in designing every individual view, just the templates of each general component & the overall style. Resources like images were just pulled in from a potentially localised folder too. Each view was light but when you have this many of them, writing one per language would be insane, and also if localisation was outsourced, it can be done just by editing text files. If you have a small app where a designer will be touching every single view directly then I can see it would be different. Ah ok. I think this just reflects differences in the application type & development workflow – the apps I worked on consisted of many hundreds of individual views (complex web-based TP application with a huge variety of transactions & screens) so of course a designer was never going to be involved in designing every individual view, just the templates of each general component & the overall style. Resources like images were just pulled in from a potentially localised folder too. Each view was light but when you have this many of them, writing one per language would be insane, and also if localisation was outsourced, it can be done just by editing text files. If you have a small app where a designer will be touching every single view directly then I can see it would be different.

]]> By: Damien Guard http://damieng.com/blog/2008/04/27/localizing-mvc-for-aspnet-views-and-master-pages#comment-8363 Damien Guard Mon, 28 Apr 2008 13:53:39 +0000 http://damieng.com/?p=906#comment-8363 You've just hit the nail on the head "when the content is going to be the same except for the labels / text". Not everything is a input form - think web sites that are mostly content. Devs might be happy with a big resource file for each language and a bunch of almost-empty views but non-devs won't be happy trying to maintain these abstract elements. Is it really worth penalising these guys with their regularly-changing content just to make your life a bit easier in the rarer case that the structure of a view needs to change? Given the use of master pages, user controls and CSS the views themselves can be very lightweight indeed and I'm not convinced that they are complex enough to force designers and translators into working in such a disconnected and disoriented manner. Of course if you're app is all repeated forms, labels and buttons then it's a different story. [)amien You’ve just hit the nail on the head “when the content is going to be the same except for the labels / text”. Not everything is a input form – think web sites that are mostly content.

Devs might be happy with a big resource file for each language and a bunch of almost-empty views but non-devs won’t be happy trying to maintain these abstract elements. Is it really worth penalising these guys with their regularly-changing content just to make your life a bit easier in the rarer case that the structure of a view needs to change?

Given the use of master pages, user controls and CSS the views themselves can be very lightweight indeed and I’m not convinced that they are complex enough to force designers and translators into working in such a disconnected and disoriented manner.

Of course if you’re app is all repeated forms, labels and buttons then it’s a different story.

[)amien

]]> By: Steve http://damieng.com/blog/2008/04/27/localizing-mvc-for-aspnet-views-and-master-pages#comment-8362 Steve Mon, 28 Apr 2008 13:15:21 +0000 http://damieng.com/?p=906#comment-8362 Can you give some examples of when string replacement doesn't work? I've never had a problem with determining what labels / text mean when they're expressed as resource names rather than explicit text, simply because I just name them after the English description so it's usually pretty obvious. I've been involved in quite large systems that had locale support available like this, but the caveat is that I never actually translated any of the text :) Having the option to was important though. It just seems overkill to have a view page for every language when the content is going to be the same except for the labels / text, seems to violate DRY. I could imagine there being a need for different versions for right-to-left systems or something like that though. Can you give some examples of when string replacement doesn’t work? I’ve never had a problem with determining what labels / text mean when they’re expressed as resource names rather than explicit text, simply because I just name them after the English description so it’s usually pretty obvious. I’ve been involved in quite large systems that had locale support available like this, but the caveat is that I never actually translated any of the text :) Having the option to was important though.

It just seems overkill to have a view page for every language when the content is going to be the same except for the labels / text, seems to violate DRY. I could imagine there being a need for different versions for right-to-left systems or something like that though.

]]> By: Damien Guard http://damieng.com/blog/2008/04/27/localizing-mvc-for-aspnet-views-and-master-pages#comment-8361 Damien Guard Mon, 28 Apr 2008 12:13:44 +0000 http://damieng.com/?p=906#comment-8361 I intentionally spelt it in American format for SEO ;-) You can replace parts of the page using locale-specific resources without any additional support but in my experience this "string replacement" philosophy works to a point when suddenly it just isn't suitable any more. The other problem with that is when you open the page it's quite difficult to know what you're looking at when all the language-specific stuff isn't present. Given that views are supposed to be very simple and that you can use user-controls within them to perform the logic they make good candidates for having their own file-per-language for small sites. [)amien I intentionally spelt it in American format for SEO ;-)

You can replace parts of the page using locale-specific resources without any additional support but in my experience this “string replacement” philosophy works to a point when suddenly it just isn’t suitable any more.

The other problem with that is when you open the page it’s quite difficult to know what you’re looking at when all the language-specific stuff isn’t present.

Given that views are supposed to be very simple and that you can use user-controls within them to perform the logic they make good candidates for having their own file-per-language for small sites.

[)amien

]]> By: Steve http://damieng.com/blog/2008/04/27/localizing-mvc-for-aspnet-views-and-master-pages#comment-8360 Steve Mon, 28 Apr 2008 11:36:16 +0000 http://damieng.com/?p=906#comment-8360 Oh bugger, I spelt it wrong too at the start of my comment. I blame your title ;) Oh bugger, I spelt it wrong too at the start of my comment. I blame your title ;)

]]>