Question

Je jouais avec les fonctionnalités de localisation intégrées .NET et elles semblent toutes dépendre de la mise des données dans des fichiers resx.

Mais la plupart des systèmes ne peuvent pas compter sur cela car ils sont basés sur une base de données. Alors, comment résolvez-vous ce problème? Existe-t-il une méthode .NET intégrée ou créez-vous une table de traduction en SQL et faites-vous tout manuellement? Et si vous devez le faire sur la majorité de vos sites, n’y a-t-il aucune raison d’utiliser même le mode de resxing pour la localisation?

Un exemple de ceci est que j'ai une liste de FAQ sur mon site, je la garde dans la base de données afin de pouvoir facilement ajouter / supprimer davantage, mais en la mettant dans la base de données, je n'ai aucun moyen valable de traduire ces informations. en plusieurs langues.

Était-ce utile?

La solution

À mon avis, la localisation de contenu dynamique (votre FAQ, par exemple) devrait être effectuée par vous dans votre base de données. En fonction de la manière dont vos questions sont stockées, je créerais probablement un "paramètre régional". colonne et l'utiliser lors de la sélection des questions de la base de données FAQ. Je ne sais pas si cela évoluerait très bien lorsque vous aurez commencé à localiser de nombreux tableaux.

Pour le contenu statique (étiquettes de champ de formulaire, texte statique, icônes, etc., par exemple), vous devriez sans doute utiliser des ressources basées sur des fichiers. Toutefois, si vous le vouliez vraiment, il ne serait pas très difficile de créer une implémentation de fournisseur de ressources personnalisée capable de gérer cela.

Voici quelques liens connexes:

Autres conseils

Pour un élément donné dans votre modèle de données, divisez la partie description en une table localisée avec une colonne d'identificateur de paramètres régionaux (LCID).

Ainsi, la table pour Product ne contiendrait pas la description ou le nom du produit, mais uniquement ses valeurs absolues (ProductId, EAN, NumberInStock, NextStockData, IsActive, IsPublished), etc.

ProductDescription contient alors  ID de produit, nom, description, LCID

Je vis au Canada, le multilinguisme est donc un gros problème. J'ai vu deux approches. La première option consiste à stocker toutes les données localisées pour un enregistrement spécifique dans une table différente, liée à la table d'origine par la clé primaire et aux paramètres régionaux. La deuxième option est similaire à la première, à la différence que pour chaque paramètre régional, il existe une table différente, le paramètre régional servant de suffixe pour le nom de la table.

Option A

Item (ItemID, ...)
ItemLocal (ItemID,LocaleID,....)

Option B

Item (ItemID, ...)
Item_ENUS (ItemID,....)
Item_ENGB (ItemID,....)
Item_FR (ItemID,....)

Une troisième option à laquelle j’avais pensé De récent, ce qui serait vraiment bien si une base de données le supportait nativement serait de stocker les valeurs de tous les locaux dans le même champ. Et si le champ était configuré avec varchar-multilocal, vous devrez y accéder en passant un paramètre pour spécifier la langue. Il n’existe rien de tel que je sache, mais c’est quelque chose qui, à mon avis, rendrait les choses beaucoup plus faciles et beaucoup plus fluides.

Actuellement, la traduction n’est pas quelque chose qui peut être fait automatiquement. Le meilleur moyen est d’amener une personne à traduire et à utiliser les méthodes de Nick pour montrer la langue appropriée.

Nous utilisons une combinaison de fichiers RESX et de l’option A de la réponse de Kibbee. Nous avons créé un outil simple pour gérer les fichiers RESX en ligne: http://blog.lavablast.com/post/ 2008/02 / fichier-RESX-Web-Editor.aspx

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