Einfach im Code auf die unterschiedlichen Sprachen eingehen ist die billigste und flexibelste Art der Lokalisierung.

Zum Beispiel kann man Images in Dateien ablegen, bei denen die jeweilige Region im Dateinamen enthalten ist, und diese per Code ergänzen. So lässt sich die Sprachumschaltung etwas ansehnlicher gestalten:

   1: <a href="@url"><img src="~/Content/flag_@(currentCulture.Name).gif" height="12" width="20" /> 

   2:     <img src="~/Content/arrow.png" height="12" width="9" /> 

   3:     <img src="~/Content/flag_@(nextCulture.Name).gif" height="12" width="20" /></a>

Mit folgendem Ergebnis (Flaggen oben rechts):

Auch Inhalte lassen sich natürlich einfach per switch unterscheiden:

   1: @switch (UICulture)

   2: {

   3:     case "de-DE":

   4:         <p>Derzeitige Sprache ist: @UICulture</p>

   5:         break;

   6:     default:

   7:         <p>Current culture is: @UICulture</p>

   8:         break;

   9: }

Für kurze Inhalte mag das ausreichend sein, aber sobald es um größere Abschnitte oder gar die gesamte View geht, ist es vermutlich einfacher, separate partial views bereitzustellen. Zum Beispiel für den Hinweistext im blauen Feld (in der Index.cshtml, featured section):

   1: @{ Html.RenderPartial("_Index_featured_" + UICulture); }

Aber Vorsicht: So wie das hier dargestellt ist gibt es kein Fallback, d.h. für alle unterstützten Regionen müssen auch entsprechende partial Views vorhanden sein, sonst gibt es eine Exception. (Wobei es sehr einfach sein sollte, eine Hilfsmethode bereitzustellen, die das Vorhandensein überprüft und ggf. die Standardregion verwendet.)

Dieser imperative Ansatz ist absolut valide und ausreichend für gelegentliche Lokalisierung. Ist das aber eine durchgängige Anforderung, wird man anfangen, nach bessern Lösungen zu suchen.Üblicherweise wird man lokalisierte Views neben die eigentliche View legen wollen, indem man die Region in den Dateinamen aufnimmt (oder mit gleichem Dateinamen in ein Verzeichnisse für die Region). Wie man es auch macht, man sollte dabei nur aufpassen, dass das nicht mit anderen Anforderungen kollidiert, etwa mobile views oder areas. (Es gibt zu viele Anforderungen die sich um den gleichen Lösungsweg streiten.)

Wer diesen Weg weiter verfolgen will: Vlad hat dazu einen Beitrag verfasst. Er verwendet Verzeichnisse für die Region und wertet die aktuelle Region über seine eigene ViewEngine aus. Er tut das für WebForms, aber das Prinzip gilt genauso für Razor.