Plusieurs langues dans une application ASP.NET MVC ?

Question

Quelle est la meilleure façon de prendre en charge plusieurs langues pour l'interface d'une application ASP.NET MVC ? J'ai vu des gens utiliser des fichiers de ressources pour d'autres applications. Est-ce encore le meilleur moyen ?

Answer 1

Si vous utilisez les moteurs de vue par défaut, les ressources locales fonctionnent dans les vues. Cependant, si vous avez besoin de saisir des chaînes de ressources dans une action de contrôleur, vous ne pouvez pas obtenir de ressources locales et devez utiliser des ressources globales.

Cela a du sens quand on y pense, car les ressources locales sont locales à une page aspx et dans le contrôleur, vous n'avez même pas sélectionné votre vue.

Answer 2

J'ai trouvé cette ressource pour être très utile

C'est une enveloppe autour de la HttpContext.Current.GetGlobalResourceString et HttpContext.Current.GetLocalResourceString qui vous permet d'appeler les ressources comme ceci...

// default global resource
Html.Resource("GlobalResource, ResourceName")

// global resource with optional arguments for formatting
Html.Resource("GlobalResource, ResourceName", "foo", "bar")

// default local resource
Html.Resource("ResourceName")

// local resource with optional arguments for formatting
Html.Resource("ResourceName", "foo", "bar")

Le seul problème que j'ai trouvé est que les contrôleurs n'ont pas accès aux chaînes de ressources locales.

Answer 3

Oui, les ressources restent le meilleur moyen de prendre en charge plusieurs langues dans l'environnement .NET. Parce qu'elles sont faciles à référencer et encore plus faciles à ajouter de nouvelles langues.

Site.resxSite.en.resxSite.en-US.resxSite.fr.resxetc...

Vous avez donc raison de continuer à utiliser les fichiers de ressources.

Answer 4

Le projet Orchard utilise une méthode raccourcie appelée "T" pour effectuer toutes les traductions de chaînes de caractères dans la page. Vous verrez donc des balises avec un @T("A String to Translate").

J'ai l'intention d'examiner comment cela est mis en œuvre dans les coulisses et de l'utiliser éventuellement dans de futurs projets. Le nom court permet de garder le code plus propre puisqu'il sera utilisé beaucoup .

Ce que j'aime dans cette approche, c'est que la chaîne de caractères d'origine (l'anglais, dans ce cas) reste facilement visible dans le code, et qu'il n'est pas nécessaire de consulter un outil de ressources ou un autre endroit pour décoder ce que la chaîne de caractères réelle devrait être ici.

Voir http://orchardproject.net pour plus d'informations.

Answer 5

Certaines des autres solutions mentionnées comme réponse ne fonctionnent pas pour la version publiée de MVC (elles fonctionnaient avec les versions précédentes d'alpha/beta).

Voici un bon article décrivant une façon d'implémenter la localisation qui sera fortement typée et ne cassera pas les tests unitaires des contrôleurs et des vues : Guide de localisation pour MVC v1