Fichiers WebForms de localisation et de ressources Mise en œuvre pratique

Question

Je suis en train de chercher à localiser un site Web ASP.NET écrit C# .NET 4.5.1. Maintenant, je connais les fichiers de ressources locaux et les fichiers de ressources globaux, mais je veux avoir une idée plus claire de la façon dont les gens s'y prennent pour la rendre plus pratique car je ne trouve pas particulièrement agréable de créer une ou plusieurs ressources locales fichiers pour chaque page Web. Par exemple, le site contient plus de 100 pages Web .aspx. Pour chaque langue que je dois supporter, je devrai créer un fichier .resx séparé. Ainsi, le soutien anglais, français et allemand pour ma page d'accueil serait ressemble à quelque chose comme ceci:

default.aspx.resx 

default.aspx.fr.resx 

default.aspx.de.resx 

La production de tous ces fichiers va être un dur labeur. Ce que je considère est pourquoi est-ce que je ne peux pas simplement utiliser le fichier de ressource global pour toutes mes pages? Si je préfixer chaque ressource de manière appropriée avec un nom de page et une description textuelle, c'est sûrement un moyen un peu plus facile de gérer la maintenance de la localisation des pages.

Par exemple, mon dossier anglais Global Resource contiendrait:

Default-TitleText - My Web Page Title 

Default-BodyText - This is some example text for the body of my home page. 

Login-TitleText - Enter your login details: 

Login-UsernameText - Username 

Login-PasswordText - Password 

Login-SubmitButton - Login 

User-Default-TitleText - Welcome to your personal page. 

User-Default-Username - Hello {0} 

User-Default-Logout - Click here to logout 

Comme vous pouvez le voir je préfixer la clé de ressource avec le nom de la page et la description du texte. Dans le cas de fichiers dans des sous-répertoires, il suffit de préfixer le nom de la page avec le nom du répertoire (c'est-à-dire User-Default-Logout).

Pour moi, c'est une solution beaucoup plus simple. Oui, le fichier sera assez volumineux mais tout est localisé au même endroit.

Je voulais savoir ce que les autres font réellement et si c'est une idée pratique ou non.

Answer 1

Et qu'en est-il de la localisation pour les différents éléments sur les formulaires. Si vous les rendez localisables, vous ne pourrez pas stocker ces informations dans votre fichier de ressources global.

.NET a hérité du support de la culture, pourquoi ne pas tirer parti de cela. Vous créez simplement vos nouvelles traductions dans un fichier de ressources avec la convention de nommage appropriée et lorsque la culture de l'utilisateur est modifiée, il récupère les ressources appropriées. Vous devrez gérer cela manuellement sinon, quel est le point de survenance de cette surcharge? De plus, les ressources sont compilées dans des assemblys satellites, ce qui signifie que l'ajout d'une nouvelle culture peut signifier simplement le redémarrage d'une application plutôt qu'une recompilation d'application (si les ressources sont éditées en externe et sans avoir à corriger le mappage).

Aussi je risquerais de deviner la plupart des outils là-bas dépendra de ces conventions. J'ai récemment utilisé un outil appelé Babylon.NET (ce n'est pas une prise) et j'ai travaillé avec un transaltor allemand pour une application qui était initialement en anglais. Il était capable d'écrire les traductions appropriées, de les renvoyer à nous et nous pourrions publier les changements si nécessaire. La structure par défaut était un must pour que cet outil fonctionne, je suis sûr que d'autres ont aussi cette dépendance. Le résultat étant que si vous optez pour une façon sur mesure, vous limiterez peut-être vos options sur la ligne.