2010-11-30 21 views
0

Quelles sont les étapes à suivre pour développer une application Web multilingue?Étapes de développement d'une application Web multinivale

Devrais-je stocker les textes et les ressources de la base de données ou devrais-je utiliser des fichiers de propriétés ou des fichiers de ressources?

Je comprends que je dois utiliser CurrentCulture avec C# seul avec CultureFormat etc.

Je voulais vous connaître les opinions sur les étapes pour construire une application web multilingue.

N'a pas besoin d'être spécifique à la langue. Je suis juste à la recherche d'étapes pour construire ça.

Répondre

2

Les mécanismes spécifiques sont différents selon la plateforme sur laquelle vous développez.

Comme un ensemble sommaire des éléments de travail:

  1. Séparation code de contenu. Généralement, les ressources sont compilées en assemblées à l'aide de fichiers de ressources (en point net) ou stockées dans des fichiers de propriétés (en Java, bien qu'il existe d'autres options), ou à un autre endroit, et référencés par ID. Si vous souhaitez que les coûts de localisation soient raisonnables, vous devez éviter les changements d'ID entre les versions, car la plupart des outils de localisation traiteront les nouveaux ID comme un nouveau contenu.
  2. Identification des zones de l'application qui émettent des hypothèses sur les paramètres régionaux de l'utilisateur, en particulier la date/l'heure, la devise, le formatage des nombres ou l'entrée.
  3. Créer un mécanisme pour le contenu CSS spécifique aux paramètres régionaux; toutes les polices ne fonctionnent pas pour toutes les langues, et toutes les tailles de police ne sont pas bonnes pour toutes les langues. Ne vous peignez pas dans un coin de forcer le texte thaïlandais à être affiché en 8 pt. En outre, la directionnalité du texte va être droite-à-gauche pour au moins deux langues.
  4. Concevez le contenu de votre page pour reflow ou redimensionner raisonnablement lorsque plus ou moins de contenu que prévu est présent. De nombreuses langues augmentent de 50 à 80% en anglais pour les chaînes courtes et de 30 à 40% pour les parties plus longues (c'est une règle grossière, pas une loi).
  5. Identifiez les présomptions culturelles faites par vos concepteurs d'interface utilisateur, et essayez de les rendre plus neutres, ou, si vous avez de l'argent et de la santé mentale à brûler, localisable. Les boîtes aux lettres ne se ressemblent pas partout, les gestes de la main ne sont pas universels, et quelque chose qui est mignon ou intelligent ou qui repose sur un jeu de mots visuel ne se passera pas nécessairement bien.
  6. Choisissez les encodages appropriés pour les langues prises en charge. Il est maintenant raisonnable d'utiliser UTF-8 pour tout le contenu envoyé aux navigateurs Web, quelle que soit la langue.
  7. Choisissez le classement approprié pour vos bases de données ou activez les autres classements, si vous gérez le contenu dans plusieurs langues dans vos bases de données. L'insensibilité à la casse fonctionne différemment dans de nombreuses langues qu'en anglais, et l'insensibilité à l'accentuation est acceptable dans certaines langues et généralement inappropriée dans d'autres.
  8. Ne supposez pas que les mots sont délimités par des espaces ou que les phrases sont délimitées par la ponctuation, si vous essayez de soutenir la recherche.

Éviter:

  1. Le stockage du contenu local dans les bases de données, à moins qu'il ya vraiment, vraiment, une bonne raison. Et puis, détrompez-vous.Si le contenu est assez dynamique et que les représentants de chaque région doivent le personnaliser, il peut être raisonnable de stocker certaines catégories de contenu avec un ID de paramètres régionaux associé.
  2. Essayer d'être intelligent avec la concaténation de chaînes. Aussi, essayez de ne pas supposer que les règles sur la pluralisation ou le travail de comptage sont les mêmes pour toutes les cultures. Assurez-vous au moins que l'ordre des chaînes (et des contrôles) peut être spécifié avec des chaînes de format typiques de votre plate-forme, ou bien documenté dans votre kit de localisation si vous choisissez de lancer le vôtre pour une raison quelconque.
  3. En supposant que les bogues de code puissent être corrigés par les localisateurs. Ce n'est généralement pas raisonnable, au moins si vous voulez livrer votre produit dans un délai raisonnable à un coût raisonnable; c'est parfois même pas possible.
+0

Bonne réponse. Je ne suis pas d'accord avec vous pour stocker du contenu sur la base de données. Je ne suis pas vraiment sûr de .net mais quand vous faites un changement sur un fichier de ressources et que vous compilez soit sur un assembly satellite, soit sur un assembly, l'application devra recharger, etc. Si c'est un portail ou un CMS, je pense sens d'utiliser la base de données pour stocker le contenu localisé que les fichiers de ressources ou de propriétés. Qu'est-ce que tu penses? – DarthVader

+0

C'est essentiellement ce que j'ai dit; Si votre contenu est dynamique, il peut être raisonnable de marquer le contenu d'une base de données avec un ID de paramètres régionaux. Cependant, j'ai vu "tout" contenu d'interface utilisateur stocké dans une base de données, même les menus et les éléments qui ne devaient pas être modifiés dynamiquement, ce qui conduit à une utilisation assez importante des ressources pour quelque chose qui ne devrait pas changer autrement que lorsque L'application est mise à jour. – JasonTrue

+0

sonne bien.Merci. – DarthVader