Comment préparer un jeu pour la localisation?

De nombreux projets ne pensent pas à la localisation tant que le jeu n'est pas terminé. La localisation se fait alors comme un hack, et il est évident qu’elle a été ajoutée plus tard. Quelques domaines de préoccupation spécifiques:

• Chaînes de texte (évidemment)
• Clips audio tels que de la musique et / ou des récits
• Texte rendu sur des textures (par exemple une étiquette sur une caisse)
• Texte rendu en images dans des films pré-rendus
• Polices / Jeux de caractères pour différentes langues
• Etc.

Quels sont les bons moyens de se préparer à ces défis dès les premières étapes du développement, de manière à simplifier les choses sans générer trop de coûts dès le départ?

Je ne suis pas un expert, mais voici quelques éléments de base:

Assurez-vous que vos chaînes peuvent gérer plus qu'un simple ASCII

Vous allez avoir besoin de caractères spécifiques qui ne rentrent pas en ASCII et il est préférable que votre classe de cordes ne les écrase pas. UTF-8 est un encodage commun car il est peu encombrant. Quoi que vous fassiez, testez tôt et corrigez-les.

C'est une très bonne idée d'utiliser une classe de cordes réelle et pas seulement char *partout ou vous allez être dans un monde de douleur.

N'oubliez pas vos polices. Assurez-vous que toutes les polices que vous utilisez ont les caractères dont vous avez besoin.

Tirez vos ficelles du code

C'est le plus important. Assurez-vous que vos chaînes de texte sont toutes stockées en dehors du code dans certains fichiers de données que vous pouvez permuter. Mettre en place un pipeline pour cela peut être une corvée rapide, mais vous fera gagner beaucoup de temps plus tard. Vous voudrez une API simple pour qu'à chaque fois que vous avez besoin d'une chaîne dans le code, celle-ci soit aussi simple que:

String text = Locale::getString("some unique identifier");

Ne pas concaténer ou construire de chaînes dans du code

Il est important de ne pas présumer de la façon dont un texte est construit à partir de mots plus petits. Même quelque chose d'aussi anodin que:

String currency = Locale::getCurrencyString() + money.toString();
// creates $123

est un problème car d’autres langues peuvent placer le symbole monétaire après le nombre. Au lieu de cela, utilisez des chaînes de format qui sont elles-mêmes localisées comme:

String format = Locale::get("currency format"); // returns "${0}" in English
String currency = String::Format(format, money.toString());

Ainsi, les localisateurs peuvent réorganiser les mots dans la chaîne de format.

Réduisez au minimum la quantité de texte qui apparaît dans l'art, en particulier la vidéo

Développer des ressources artistiques est une corvée. Vous aurez probablement besoin de le faire au moins un peu pour certains éléments de l'interface utilisateur, mais c'est un problème. Bifurquer FMV est une énorme douleur parce que maintenant vous avez à rendre et à stocker des copies de votre FMV.

Testez dans différentes langues à fond

Dans la plupart des bases de code, il est trop facile de simplement dire printf("Hi there");ou d' loadTexture("someTexture");oublier que celles-ci doivent passer par votre API de localisation. Quelqu'un l'oubliera et vous vous retrouverez avec quelque chose de correct dans votre langue principale mais erroné dans les autres. La seule façon de les trouver est de faire tester vos testeurs dans des langues non principales.

Rendre évident le texte localisé manquant

En règle générale, vous traduisez votre texte tard dans le cycle. Ainsi, la plupart du temps, il n'y aura aucune donnée pour certaines langues. C'est bien parce que cela vous permet d'itérer sur votre contenu sans avoir à refaire constamment la traduction. L'inconvénient est que cela signifie qu'il est facile pour vous de rater des choses et d'oublier de traduire certaines choses.

Une chose peu coûteuse que vous pouvez faire est de faire apparaître très clairement le texte manquant du type "!!! TRADUCTION NÉCESSAIRE POUR ID #blah blah !!!" dans le jeu quand il manque.

Concevez votre interface utilisateur autour de la pire langue possible

Différentes langues ont tendance à avoir des mots plus longs ou plus courts. Une interface utilisateur qui est belle en anglais peut contenir du texte qui dépasse ses limites, qui est rogné ou qui est incorrectement enroulé dans une langue plus longue. Vous devrez apporter des modifications à l'interface utilisateur pour prendre en charge la langue la plus défavorable (ou modifier l'interface utilisateur, mais ce n'est probablement pas ce que vous souhaitez faire.)

Chose embarrassante, l'anglais est souvent la langue la plus courte de celles généralement localisées. Par conséquent, vos concepteurs sont probablement en train de concevoir par inadvertance le meilleur des cas. Faites-leur utiliser un texte très long pour leurs espaces réservés lors de la conception. Supposons qu'un texte donné peut être environ 30% plus long qu'en anglais. Google Translate peut être utile pour obtenir un texte approximatif pour un espace réservé.

Délai budgétaire pour la traduction

La traduction du texte arrive généralement tard lorsque l'équipe est fatiguée et ne s'en soucie pas vraiment. Néanmoins, vous aurez beaucoup de bugs quand cela se produira. Les mots vont au-delà des frontières, les traducteurs vont faire des erreurs, etc. Pour aggraver les choses, le délai d'exécution d'une itération sur du texte peut être long si vous devez envoyer du texte à des personnes à l'étranger et attendre leurs modifications. Allouer du temps pour ce travail.

En plus d’autres suggestions, j’ai déjà fait une chose dans le passé qui aide beaucoup à trouver du texte traduit qui saigne des composants de l’interface utilisateur, c’est d’avoir un mode linguistique spécial pour votre jeu. choisit la version la plus longue de cette chaîne. Ainsi, une fois que toutes les chaînes sont adaptées à ce mode, vous savez que vous avez corrigé tous les fonds perdus dans toutes les langues.

Localiser un jeu correctement est sacrément difficile .

Vous pouvez naviguer sur Internet, lire des articles de blog ou des réponses StackOverflow. vous pouvez apprendre les frameworks i18n traditionnels tels que gettext ; lire des pages Wikipedia sur l' internationalisation et la localisation de jeux ; consultez l'excellent guide des langues de Microsoft - mais la localisation des jeux est en réalité plus difficile que cela. En fait, avec les jeux, c'est probablement plus difficile qu'avec toute autre application ou interface Web. Ceci parce que les jeux sont tellement plus dynamiques, plus dynamiques, plus vivants (du moins, les bons jeux le sont).

Plus précisément, il faudra probablement suivre les étapes suivantes:

Établissez les limites.

Vous souhaitez prendre une décision cruciale pour les langues que vous souhaitez prendre en charge rapidement. Plus votre choix est large, plus les hypothèses sur la manière dont une langue peut se comporter seront brisées. Souvent, ces hypothèses sont si profondément gravées dans notre cerveau que nous ne pouvons même pas imaginer qu’elles peuvent être incorrectes sans que personne ne les indique. Ce qui nous amène au point suivant:

Trouvez les experts pour chaque langue que vous souhaitez soutenir.

Expert signifie une personne qui possède des compétences analytiques suffisantes et une connaissance de la langue, ce qui lui permettrait de vous indiquer les hypothèses qu'un anglophone ne considère pas dans sa propre langue. Ensuite, vous devrez élaborer une stratégie pour contourner ces hypothèses.

A titre d'exemple: dans les langues occidentales, nous justifions le texte d'un paragraphe en insérant un espace supplémentaire entre les mots. En langue arabe, le texte est justifié par l’insertion de caractères kashida dans les mots. Cela pourrait ressembler à ceci .

Autre exemple: en russe, il existe 2 formes plurielles pour la majorité des mots. Ainsi, par exemple, vous traduirez "1 pièce" / "3 pièces" / "5 pièces" par "1 millimètre", "3 millimètres", mais "5 millimètres". La procédure à suivre pour décider de la forme plurielle correcte ressemble à ceci:

function LocalRU::GetPlural(n, form0, form1, form2) {
    return (n%10) == 0 || (n%100) >= 5 && (n%100) <= 20? form0 : 
           (n%10) == 1? form1 : 
           (n%10) <= 4? form2 : form0;
}

Créez un module de traduction tenant compte du contexte.

Vous savez probablement que la traduction dépend toujours du contexte. Et vous savez que le contexte dans un jeu change tout le temps. Que se passe-t-il si nous mettons ces deux déclarations ensemble? En général, vos traductions doivent être aussi dynamiques que votre jeu.

Par exemple, une simple phrase "Je suis d'accord" se traduit en russe par "Я согласен" / "Я согласна" / "Я согласно", en fonction du sexe du locuteur (homme / femme / transgender | queer | questionnement). S'il s'agit de l'une de vos lignes de dialogue, le module de langue devra choisir l'une des traductions possibles au moment de l'exécution, en fonction du sexe de votre personnage (en supposant que vous offriez un tel choix à vos joueurs).

Une fois traduite en japonais, la même phrase aura à nouveau des traductions différentes, selon le niveau de formalité de la relation entre le locuteur et l'auditeur. Ainsi, si vous introduisez dans votre jeu l'idée de réputation, d'amitié ou de degré de supériorité variable (par exemple, votre personnage peut évoluer de recrue à général), vous devrez en tenir compte lors de la formation de la traduction. (En fait, ceci n'est pas spécifique au japonais. Même en anglais, dans l'armée, vous ne dites jamais "Monsieur, oui, monsieur!" À quelqu'un de rang inférieur à vous.)

Avoir un moyen de sauter dans le contexte.

Vos traducteurs devraient avoir la possibilité de voir le contexte dans lequel une phrase particulière apparaît. Parfois, le contexte est évident, parfois, vous devez voir / entendre / expérimenter vous-même pour pouvoir traduire quelque chose correctement.

Même une phrase aussi simple que "Ce livre est bleu". ne peut pas être traduit sans ambiguïté sans que je regarde le livre et que je vois quelle nuance de bleu il est.

Évitez les jeux de mots, les jeux de mots et autres éléments spécifiques à la langue.

Ou peut-être ne pas éviter, mais au moins avoir une stratégie en tête pour quoi faire lorsque le jeu de mots ne peut pas être traduit. Parce que probablement pas.

À tout le moins, vous ne devriez pas créer de quêtes / d'énigmes / d'objets de jeu faisant appel à certains mots ayant une double signification, ou ressemblant à certains autres mots. Parce qu'une fois traduit, vous cassez votre propre jeu. (Par exemple, dans un ancien jeu Fallout2, la quête principale était de trouver l'objet appelé GECK; il y avait également de nombreux monstres "Gecko" autour du jeu. Ils créèrent naturellement de multiples références et quêtes autour de cette similitude de noms, qui fait de bonnes traductions extrêmement difficile).

Courage!

Localiser un jeu est difficile. Mais c'est difficile pour tout le monde. Si vous faites un effort et le faites correctement, les critiques de jeux de votre pays cible ne passeront pas inaperçu. Un jeu avec une bonne traduction se démarque et génère des profits plus importants. Après tout, le texte est tout aussi important pour créer une atmosphère dans le jeu que le graphisme (c’est la raison pour laquelle les anciens RPG basés sur le texte étaient si immersifs).

Wil Shipley est de loin le meilleur guide sur la localisation que j'ai jamais lu. Malheureusement, c'est spécifique à l'iPhone, mais on peut toujours en tirer des informations utiles. En outre, il aborde la localisation des actifs et de l'interface utilisateur, deux des plus grands défis de la localisation de jeux que je peux imaginer.

Toujours, TOUJOURS traiter la langue source comme une langue localisée.

Ainsi, si votre langue source est EN, conservez tous les éléments et chaînes EN dans un dossier EN séparé et extrayez-le.

Tirez les actifs EN de votre pipeline de localisation prévu.

En procédant ainsi, vous pouvez capturer environ 80% des problèmes de localisation et vous préparer à un processus de localisation beaucoup plus simple.

J'ai localisé de nombreux jeux et je mène toujours avec cette pépite.

Je vois de très bons conseils ici!

Je vais essayer de dresser une liste des erreurs les plus courantes pouvant aller de rendre votre localisation plus difficile, voire de ruiner complètement votre jeu:

• Penser à la localisation comme dernière étape du développement d'un jeu
• Ne pas isoler vos chaînes de texte du code source
• Concaténation / sauts de ligne au milieu d'une phrase.
• En supposant que les heures, les dates et les unités ne nécessitent pas de localisation
• Pas assez de matériel de référence pour les traducteurs / Pas de réponses à leurs questions
• En supposant que tout le texte de votre jeu sera en ASCII
• Avoir du texte dans les visuels
• Avoir des boîtes de texte / interface rigides
• En supposant que toutes les langues ont la même longueur que l'anglais
• Utilisation de Google Traduction / traduction automatique
• Ignorer les facteurs culturels
• Ne pas allouer suffisamment de budget pour la localisation

La localisation doit être intégrée au développement le plus tôt possible et gardez-la toujours à l'esprit lors de la conception d'un jeu.

Avec une bonne planification et des études de marché approfondies, vous éviterez beaucoup de problèmes et de dépenses en aval.

Je suis le fondateur d’une société de localisation de jeux et nous avons couvert la préparation d’un jeu pour la localisation il ya quelques mois dans notre blog.

Voici l'infographie qui résume cet article: https://magic.piktochart.com/output/18317297-9-steps-to-cheaper-game-development- with - localization

Le lien vers le post complet qui couvre ces conseils en plus de détails est au bas de celui-ci.