Vous développez avec la localisation en tête?

Lorsque vous travaillez sur un projet logiciel ou un site Web, développez-vous en tenant compte de la localisation?

Par cela, je veux dire par exemple

• Externaliser toutes les chaînes, y compris les messages d'erreur.
• Ne pas utiliser d'images contenant du texte.
• Concevoir votre interface utilisateur en pensant à l'expansion du texte.
• Utiliser la pseudo-traduction pour tester vos interfaces utilisateur au début du processus.
• etc.

Sur les projets sur lesquels vous travaillez, ceux-ci sont-ils dans la catégorie «agréable à avoir» et laissent l'équipe de localisation se soucier du reste, ou avez-vous une préparation à la localisation intégrée dans votre processus de développement? Je suis intéressé de savoir comment les développeurs voient la localisation en général.

Je travaille pour une grande entreprise du Fortune 500 et nous commençons toujours par la localisation en tête. Nos projets sont généralement uniquement pour les États-Unis, mais trop de fois au fil des ans, nous allons écrire une application pour un client, puis quelqu'un d'autre la verra et dira "hé, ce serait un ajustement parfait pour le pays X". La prochaine chose que vous savez, c'est que vous parcourez le code en ajoutant la localisation. Il ne faut vraiment plus de temps pour créer l'application avec elle depuis le début, alors nous le faisons. De plus, l'avantage supplémentaire est que lorsqu'un client vient chez nous et demande que son application soit en (choisissez votre langue), nous lui remettons un fichier et lui demandons de le faire traduire en (choisissez votre langue) et nous avons terminé .

Je pense que c'était important il y a 10 ans. La technologie récente a résolu le problème .

Je vis dans un pays où il y a 3 langues nationales et une seule d'entre elles est minoritaire.

Pour comprendre les problèmes qui pourraient survenir à cause de cela, c'est comme si la partie ouest des États-Unis parlait une langue (très) différente de la partie est. Pensez que dans le centre du pays, la population est un peu fusionnée et vous devez donc utiliser les deux langues partout.

Avoir 4 langues dans les applications de bureau et les sites Web était et est toujours très courant (3 langues nationales + anglais). C'est parfois une obligation.

J'étais conscient de la localisation car j'ai été conditionné par mon environnement. Alors oui, il y a quelques années, je m'en inquiétais.

Maintenant, je ne me soucie plus beaucoup de la localisation car les derniers outils IDE vous permettent de convertir très facilement n'importe quelle application statique en une application entièrement localisée.

Outils que j'utilise avec Visual Studio .NET:

• CodeRush , un plugin Visual Studio qui vous permet de déplacer des textes codés en dur dans des fichiers de ressources.
• Easy Localizer , extrayez des étiquettes dans un fichier Excel dans lequel vous ajoutez toutes les langues supplémentaires, puis fusionnez-les dans vos fichiers de ressources.

La plupart de mes clients n'ont besoin que d'une seule langue, et en fait spécifient cette langue. Par conséquent, nous ne passons pas de temps à localiser l'application. Cependant, cela ne signifie pas que nous pouvons ignorer complètement les autres langues. Nous nous en tenons donc aux bases:

• Utilisez Unicode partout. C'est 2k10, il n'y a aucune excuse pour ne pas le faire.
• Conception pour une certaine élasticité dans la disposition. Même avec tout l'anglais, différentes polices ont des empreintes d'écran très différentes à la même taille de point.
• Gardez les fonctions d'application / la modélisation des données hors de la couche de vue

Personnellement, quand une langue de localisation potentielle est fondamentalement différente de celle dans laquelle l'application a été conçue, il se passe beaucoup plus que la simple sélection de texte. Bien que le remplacement de texte aide et permette à une entreprise d'obtenir une implémentation "rapide et sale" dans un nouvel emplacement relativement plus tôt - cela ne résout pas les différences fondamentales dans la façon dont les utilisateurs dans l'autre langue pensent.

J'ai étudié le japonais, et bien que je ne puisse me considérer que comme un débutant de rang dans cette langue, je sais assez qu'il y a des concepts pour lesquels il n'y a pas de traduction directe. Il existe différentes idées de ce qui rend quelque chose utilisable. Bien que les grands concepts majeurs puissent être similaires, ce sont les détails qui font vraiment la différence pour les utilisateurs.

Afin de vraiment répondre aux besoins d'une culture très différente, vous avez besoin d'un tout nouveau visage pour votre application. C'est pourquoi la séparation modèle / vue / contrôleur devient encore plus importante. Tant que l'application fonctionne de la même manière, la partie vue peut être complètement remplacée. Lorsque cela se produit, quelqu'un prévoit de payer de l'argent réel pour s'attaquer correctement au problème.

Nous l'avons fait selon les besoins: les informations destinées aux clients sont désormais entièrement conçues avec i18n, car nous avons élargi nos marchés, et certaines informations internes sont désormais compatibles avec i18n, de sorte que les employés qui l'utilisent n'ont pas besoin de parler anglais.

Nous l'avons donc fait au besoin, en tant que startup.

Sonne que les gens prennent des efforts l10n assez à la légère. Surtout lorsque vous utilisez l'anglais comme langue d'origine, il est facile d'ignorer le fait que d'autres langues nécessitent normalement 30 à 40% d'espace supplémentaire pour le texte. Cela oblige les traducteurs à utiliser des abréviations difficiles à comprendre, ce qui est bien sûr mauvais pour l'expérience utilisateur.

Habituellement, j'ajoute l'internationalisation plus tard quand j'en ai besoin, même si je sais depuis le début que j'en aurai besoin. Avec les langues que j'utilise, ce n'est pas très difficile de le faire dans une phase distincte, et je peux garder un aspect encombrant hors des premières phases constructives.

J'écris des applications Android et la localisation est assez simple en utilisant des fichiers de chaîne de style java. Effort presque nul pour une internationalisation complète sur toutes les langues Android.

Réponse: oui. Bien que dans l'environnement où je travaille (Python / Zope / Plone), il est très facile de localiser les chaînes par la suite, donc je l'ignore si ce n'est pas une exigence dès le départ.

Mais je stocke du texte dans des objets Unicode, etc.

Donc oui. Je m'assure que mes applications sont raisonnablement faciles à localiser et même si elles ne sont pas localisées, elles fonctionneront dans un contexte international. Ne pas le faire est une erreur, car l'effort requis est faible et le bénéfice est grand.