Quels sont les avantages d'utiliser la localisation .resx pour une application ASP.NET MVC?

Question

Ce site contient un certain nombre de questions sur comment accéder aux fichiers RESX dans une application ASP.NET MVC et aux meilleures pratiques de les utiliser.

Cependant, après avoir lu (pour la première fois, je pourrais ajouter) le MSDN article sur les ressources Je me demande s'il est même avantageux d'utiliser des fichiers RESX puisque je ne vais pas utiliser les contrôles du serveur. Il y a toutes ces discussions sur la localisation "implicite" et "explicite", mais je ne vais pas en profiter avec MVC.

Finalement, mon application aura besoin de ressources chaîne pour les boutons et les éléments de menu, ainsi que d’éléments HTML beaucoup plus longs pour un contenu plus long. J'aimerais utiliser un CMS pour les éléments plus longs, car je suis sûr de ne pas vouloir les insérer dans un fichier RESX.

Existe-t-il des raisons impérieuses d'utiliser ou non les ressources ASP.NET dans une nouvelle application? Je vais supposer que toutes les améliorations futures de MVC ou de RESX fonctionneront ensemble, mais pour l'instant, je ne fais qu'obtenir un IDictionary glorifié, à ma connaissance.

Devrais-je continuer avec RESX ou regarder ailleurs? Devrais-je même envisager un CMS pour le type de ressources pour lequel RESX est conçu?

Toutes les leçons apprises seraient appréciées.

Answer 1

L’infrastructure RESX présente quelques avantages:

• vous n'avez pas à charger les ressources par langue appropriées. Une fois les paramètres régionaux du thread établis, le CLr se charge de trouver l’assembly approprié et de charger les ressources.
• il est facile de transférer les ressources spécifiques aux paramètres régionaux pour les localisations à des tiers.
• il existe un mécanisme de secours par défaut pour les ressources non localisées.

L’approche RESX présente également un inconvénient particulier:

• il est difficile de prendre en charge le modèle de traduction dans lequel les utilisateurs traduisent vos ressources pour vous.

Je voudrais élaborer un peu sur ce dernier point. Prenons par exemple le modèle de traduction Facebook. Facebook dispose d'un moyen assez simple permettant aux utilisateurs de fournir et de voter des traductions de diverses ressources. Si ceux-ci sont stockés dans une base de données, il serait possible de les utiliser après le processus éditorial approprié sans reconstruire ni redéployer l'application. Avec le modèle RESX, les assemblys de ressources devront être reconstruits et redéployés, ce qui pourrait avoir un coût suffisamment élevé en fonction du processus de déploiement.

Ainsi, avant de décider du processus de localisation à utiliser, j’examinerais le choix de la personne qui effectuera la localisation et le processus de déploiement des ressources localisées une fois que l’application principale est déjà déployée.

MODIFIER: j'ai oublié de mentionner que ces considérations sont orthogonales au choix du framework ASP.NET (MVC ou WebForms).

Answer 2

Je dirais & "oui &", les fichiers resx sont toujours une bonne option pour les nouvelles applications. Je ne pense pas que ASP.NET MVC en particulier change quoi que ce soit à propos du stockage de vos chaînes.

Ce qui est génial avec l'utilisation des ressources, c'est

• ils sont assez faciles à gérer
• localiser votre site est une tâche beaucoup plus facile que sans ressources (et je souligne beaucoup plus beaucoup )
• vous pouvez remplacer le magasin de ressources à tout moment, car les ressources utilisent le modèle de fournisseur. Vous pouvez remplacer les fichiers resx pour les entrées de base de données sans modifier l’implémentation de votre site.

Je recommande les fichiers de ressources pour les " chaînes de site " qui sont différentes des gros blocs de données que vous pouvez éditer fréquemment. Donc, pour une recommandation complète, utilisez des fichiers de ressources (resx to start) pour les boutons, les étiquettes, etc., et un CMS pour le contenu charnu.

Answer 3

Si vous envisagez d'utiliser Resx sans utiliser les contrôles serveur comme dans MVC, pourquoi ne pas étendre les méthodes de l'assistance MVC afin de pouvoir créer des étiquettes et du texte localisés? Ensuite, appelez simplement le texte de ressource dans la méthode d'assistance.

par exemple. '<% = Html.CultureLabel (" ResouceId & ")% >'

ou '<% = Html.CultureButton (& "Nom &"; & "ResouceId &"; HtmlButtonType.Button)% >'

Juste une pensée.

Gérer la globalisation d'un site est également beaucoup plus facile avec resx pour le texte.