Meilleures pratiques pour les textes localisés dans les applications multiplates-formes C ++?

Question

Dans le standard C ++ actuel (C ++ 03), il existe trop peu de spécifications concernant la localisation de texte, ce qui rend la vie du développeur C ++ plus difficile que d'habitude lorsqu'il travaille avec des textes localisés (le standard C ++ 0x y contribuera certainement plus tard) ).

En supposant le scénario suivant (tiré de cas réels de développement de jeux PC-Mac):

1. Application réactive (temps réel) : l'application doit minimiser les temps de non-réponse à & "non perceptible &"; ainsi, la rapidité d'exécution est importante.
2. textes localisés : les textes affichés sont localisés dans plus de deux langues, voire davantage - ne vous attendez pas à un nombre fixe de langues, elles devraient être facilement extensibles.
3. langue définie au moment de l'exécution : les textes ne doivent pas être compilés dans l'application (ni avoir une application par langue), vous obtenez les informations sur la langue choisie au lancement de l'application, ce qui implique un chargement de texte. .
4. multiplate-forme : l'application est codée de manière multiplateforme (Windows - Linux / Ubuntu - Mac / OSX), de sorte que le système de texte localisé doit également être multiplateforme.
5. application autonome : l'application fournit tout ce qui est nécessaire pour l'exécuter. il n’utilisera aucune bibliothèque d’environnement et ne demandera pas à l’utilisateur d’installer autre chose que le système d’exploitation (comme la plupart des jeux par exemple).

Quelles sont les meilleures pratiques pour gérer des textes localisés en C ++ dans ce type d'application?

Je me suis penché sur cette dernière année et je ne suis pas sûr que vous devez utiliser std::wstring ou std::basic_string<ABigEnoughType> pour manipuler les textes de l'application. J'ai arrêté mes recherches car je travaillais davantage sur & "Affichage du texte &"; problème (dans le cas de la 3D en temps réel), mais je suppose qu’il existe certaines meilleures pratiques pour gérer les textes localisés en C ++ brut au-delà de cela et & "utiliser Unicode &";.

Donc, toutes les meilleures pratiques, suggestions et informations (multiplate-forme le rend difficile, je pense) sont les bienvenues!

Answer 1

Au sein d’une petite société de jeux vidéo, Black Lantern Studios, j’étais le développeur principal du jeu Lionel Trains DS. Nous avons localisé en anglais, espagnol, français et allemand. Nous connaissions toutes les langues à l’avance, donc les inclure au moment de la compilation était la seule option. (Ils sont gravés dans une ROM, vous voyez)

Je peux vous donner des informations sur certaines des choses que nous avons faites. Nos chaînes ont été chargées dans un tableau au démarrage en fonction de la langue choisie par le lecteur. Chaque langue individuelle est entrée dans un fichier séparé avec toutes les chaînes dans le même ordre. La chaîne 1 était toujours le titre du jeu, la chaîne 2 toujours la première option de menu, etc. Nous avons défini les tableaux d'un enum, car integer l'indexation est très rapide et, dans les jeux, la vitesse est primordiale. (La solution liée dans l'une des autres réponses utilise string des recherches, ce que j'aurais tendance à éviter.) Lors de l'affichage des chaînes, nous avons utilisé une fonction de type printf() pour remplacer les marqueurs par des valeurs. " Le train 3 est la ville de départ 1. "

Passons maintenant aux pièges.

1) L'ordre des phrases est complètement différent entre les langues. " Le train 3 est la ville de départ 1. " traduit en allemand et le dos devient & "; De la ville 1, le train 3 part &"; Si vous utilisez quelque chose comme %0 et que votre chaîne est & "; Train% d part la ville de départ% d. &"; l’Allemand finira par dire & "; De la ville 3, le train 1 partira. &"; ce qui est complètement faux. Nous avons résolu ce problème en forçant la traduction à conserver le même ordre de mots, mais nous nous sommes retrouvés avec un joli allemand cassé. Si je le faisais à nouveau, j'écrirais une fonction qui prend la chaîne et un tableau de valeurs de base zéro à insérer. J'utiliserais ensuite des marqueurs tels que %1 et %2$s, incorporant essentiellement l'index de tableau dans la chaîne. Mise à jour: @Jonathan Leffler a signalé qu'un 2$ conforme à POSIX prend en charge l'utilisation de .h marqueurs de type où la partie .lang indique à <=> de remplir ce marqueur avec le deuxième paramètre supplémentaire. Ce serait assez pratique, tant que c'est assez rapide. Une solution personnalisée est peut-être encore plus rapide, vous devez donc vous en assurer et tester les deux.

2) La longueur des langues varie énormément. Quelque 30 caractères en anglais sont parfois jusqu'à 110 caractères en allemand. Cela signifiait que souvent, cela ne correspondait pas aux écrans sur lesquels nous le mettions. Ceci est probablement moins une préoccupation pour les jeux PC / Mac, mais si vous faites un travail où le texte doit tenir dans une zone définie, vous voudrez peut-être en tenir compte. Pour résoudre ce problème, nous avons supprimé autant d'adjectifs que possible de notre texte pour d'autres langues. Cela a raccourci la phrase, mais en a préservé le sens, même s’il perd un peu de son goût. J'ai par la suite conçu une application que nous pourrions utiliser, qui contiendrait la police et la taille de la boîte et permettrait aux traducteurs de faire leurs propres modifications pour que le texte tienne dans la boîte. Je ne sais pas s'ils l'ont déjà mis en œuvre. Vous pouvez également envisager de faire défiler des zones de texte si vous rencontrez ce problème.

3) En ce qui concerne les plates-formes croisées, nous avons écrit à peu près du C ++ pur pour notre système de localisation. Nous avons écrit des fichiers binaires encodés personnalisés à charger, et un programme personnalisé permettant de convertir un texte de langue CSV en un fichier <=> avec l’enum et le fichier en mappage de langue, ainsi qu'un <=> pour chaque langue. Nous avons surtout utilisé les polices et la <=> fonction propres à la plate-forme. Toutefois, vous aurez quelque chose de bien pour votre développement, ou vous pourrez écrire la vôtre si nécessaire.

Answer 2

GNU Gettext fait tout.

Answer 3

Je suis fortement en désaccord avec la réponse acceptée. Tout d’abord, la partie relative à l’utilisation de recherches de tableaux statiques pour accélérer les recherches de texte indique simplement que la personne effectuant la l'optimisation est très inexpérimentée - Le calcul de la mise en page dudit texte et son rendu utilisent 2 à 4 ordres de grandeur de plus qu'une recherche de hachage. Si quelqu'un souhaite implémenter sa propre bibliothèque de langues, il ne devrait jamais être basé sur des tableaux statiques.

Mais ce n'est pas vraiment pertinent, car écrire votre propre bibliothèque de langues à utiliser dans votre propre jeu est encore pire que l'optimisation prématurée inutile. Il existe de très bonnes raisons de n'écrivez jamais votre propre bibliothèque de localisation :

1. Planifier le temps d'utilisation d'une bibliothèque de localisation est beaucoup plus facile que de planifier le temps nécessaire pour écrire une bibliothèque de localisation. Des bibliothèques de localisation existent, elles fonctionnent et beaucoup de personnes les ont utilisées.

2. La localisation est délicate, vous allez donc vous tromper. Chaque langue ajoute une nouvelle bizarrerie, ce qui signifie que chaque fois que vous ajoutez une nouvelle langue à votre propre bibliothèque de localisation locale, vous devrez changer de code à nouveau pour prendre en compte les irrégularités. Saviez-vous que certaines langues ont plus de 2 formes plurielles, en fonction du nombre d'éléments en question? Plus de 2 genres (plus de 10, même)? De plus, les formats de nombre et de date varient beaucoup selon les langues.

3. Quand votre application aura réussi, vous voudrez ajouter du support pour plus de langues. Langues Personne dans votre équipe ne parle couramment. Engager quelqu'un pour rédiger une traduction sera beaucoup moins cher s'il connaît déjà les outils avec lesquels il travaille.

Une bibliothèque de localisation très connue et complète est GNU Gettext . , qui utilise la GPL, et devrait donc être évité pour les travaux commerciaux. Vous pouvez également utiliser la bibliothèque boost boost.locale. qui fonctionne avec les fichiers Gettext et est libre d'utilisation et de modification pour les projets commerciaux et non commerciaux de tout type.

Answer 4

Autant que je sache, le standard C ++ 0x ne comportera aucune fonctionnalité supplémentaire. J'imagine que le Comité considère que cela concerne les bibliothèques tierces.