Question

Quelle serait la meilleure pratique pour localiser votre application ASP.NET MVC?

Je voudrais couvrir deux situations:

  • un déploiement d’application dans IIS capable de gérer plusieurs langues
  • déploiement d'une langue / application.

Dans la première situation, devriez-vous utiliser un type de vue tel que ~ / View / EN, ~ / View / FI, ~ / View / SWE ou quelque chose de différent?

Qu'en est-il du second cas, juste de la configuration basée sur une application via Web.config et pointer ces différentes langues vers différentes URL?

Était-ce utile?

La solution

Vous pouvez également jeter un coup d'œil ici ASP.NET Guide complet de localisation de MVC 2 et Validation du modèle ASP.NET MVC 2 avec localisation , ces informations vous aideront si vous travaillez avec ASP.NET MVC 2.

Autres conseils

Vous localiseriez votre application ASP.NET MVC de la même manière que vous le feriez avec une application Web Form ASP.NET classique.

Vous n'utiliseriez pas différentes pages / vues pour chaque langue, mais chaque page prendrait en charge plusieurs langues à l'aide d'assemblages satellites.

Vous pouvez consulter l'entrée de blog de Matt Hawley pour plus d'explications et d'exemples.

Malheureusement, le code d'origine de Matt Hawley ne fonctionne pas dans la version finale d'ASP.NET MVC. Découvrez un article mis à jour: http: / /blog.eworldui.net/post/2008/10/ASPNET-MVC-Localization-via-View-Engines.aspx

En général, le processus de localisation dans le monde VSC / 2008 / ASP.NET MVC n'est pas aussi fluide qu'avec les formulaires Web traditionnels. http://www.guysmithferrier.com/post/2009/05 /Localizing-ASPNET-MVC.aspx

Jetez un coup d’œil au projet MvcStore de Rob Connery. Il fait un screencast montrant une façon de résoudre le problème de la mondialisation.

http://wekeroad.com/2008/04/24/mvcstore -part-5

Je ne suis jamais convaincu de gérer la localisation au sein d'un formulaire, comme le suggère Elijah - les différentes longueurs et directions peuvent conduire à des formes très complexes ou très variables.

Je ne fais que commencer avec MVC, mais si vous utilisiez la méthode de découplage, vous voudriez utiliser le même contrôleur quelle que soit la langue (traiter la langue comme une vue) - cela vous donnerait alors / Controller / Action / langue / formulaire

Il y a un bon tutoriel avec une mise à jour récente sur Comment localiser l'application asp.net mvc couvrant tous les aspects, y compris la localisation DisplayName, la validation, l'utilisation du routage (stockage du nom de culture dans une URL), les problèmes de cache de sortie, etc. Blog Alex Adamyan - Mon clavier pleure doucement

En fait, nous avons opté pour une solution complètement différente en remplaçant la DataAnnotationsMetadaDataProvider . Vous pouvez vous assurer que les valeurs DisplayNameAttribute sont résolues dans la langue correcte. En fait, vous pouvez même vous débarrasser de cet attribut et le résoudre par les noms de champs uniquement si cela peut vous aider.

J'ai écrit cet article il y a longtemps. Il utilise un moteur de vue personnalisé. http://blog.oimae.com/2011/ 02/20 / Cultured-View-Engine-pour-mvc /

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top