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


13

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.


3
L10N-> localisation ... utilisons un anglais correct ici, d'accord?
Tour

11
@Rook - C'est une abréviation courante de l'industrie et elle est contenue dans 'The American Heritage® Abbreviations Dictionary'.
Jimmy Collins

5
@Rook Et c'est orthographié Localisation aussi;)
Rowland Shaw

2
@Jimmy C - Pas chez Black, pas chez Longman, pas chez Oxford, pas chez Merrian ... (et croyez-le ou non, j'ai pris la peine de tous les vérifier juste pour être sûr). Mais clairement, c'est juste moche et ne ressemble pas à un mot (pas sûr sur celui-ci, mais je suis assez fort sur le fait que les mots n'ont pas de chiffres).
Tour

4
@Rook: C'est une abréviation de nombre. Même i18n pour "internationalisation" et g11n pour "mondialisation". Sont-ils moches? Peut-être peut-être pas. Le fait est qu'ils sont couramment utilisés.
Andy

Réponses:


9

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é .


Vrai. Mais pour les projets personnels, je n'en ai pas. Juste anglais.

6

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.

4
Vraiment? quels outils permettent cela?
David Weiser

Qu'en est-il des choses comme le texte dans les images et l'utilisation de chaînes comme (par exemple) «Your High School» dans des formes qui peuvent ne pas être comprises dans certains pays? Un développeur doit toujours être conscient des différences culturelles.
Jimmy Collins

Dans Visual Studio, j'utilise un outil de DevExpress nommé CodeRush. Il existe également un autre outil que j'utilise pour traduire une application entière à la fois: Easy Localizer: foss.kharkov.ua/products/easy_localizer/index.htm (je les ajouterai pour référence dans ma réponse)

4
de bons outils, mais il y a plus que cela - les dispositions d'écran, par exemple, peuvent devoir changer en raison de différentes longueurs d'étiquette; les valeurs de recherche de base de données devront être traduites; etc.
Steven A. Lowe

@Steven & JimmyC: pas de balles d'argent ici. Juste de bons outils qui suppriment le plus de complexité. Veuillez noter que j'ai remarqué un modèle avec des années de travail sur des applications localisées: vous ne pouvez pas savoir à l'avance la taille d'un mot ou d'une phrase donnée dans les langues que vous ne connaissez pas. Croyez-moi, ils peuvent avoir des tailles très différentes. Vous ajustez vos interfaces et mises en page lors de vos tests.

4

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.


+1 pour s'en tenir aux bases et à votre point sur Unicode. En outre, vous faites un bon point sur «beaucoup plus de choses que la simple sélection de texte». Cela est particulièrement vrai lors de la localisation d'applications pour des langues écrites de droite à gauche (comme l'arabe ou l'hébreu), où toute l'interface utilisateur doit être mise en miroir.
Jimmy Collins

Du point de vue de l'utilisabilité, la simple mise en miroir de l'interface utilisateur n'est peut-être pas la meilleure option. Vous devrez peut-être réorganiser certains éléments pour respecter les conventions locales et réduire la courbe d'apprentissage pour vos utilisateurs. Les projets d'internationalisation / localisation sérieux doivent tenir compte de l'impact sur les utilisateurs dans ce lieu. S'ils ne le font pas, l'application ne recevra tout simplement pas l'adoption que les spécialistes du marketing espéraient.
Berin Loritsch

3

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.


2

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.


1

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.


2
Vous n'êtes pas sûr que ce soit la meilleure approche - que se passe-t-il si vous recevez des demandes pour certaines langues qui peuvent être gênantes, peut-être certaines langues à double octet comme le japonais, le coréen, etc.?
Jimmy Collins

1
Jimmy C: Actuellement, pour le type de projet sur lequel je travaille, le support des langues européennes comme l'anglais, l'allemand, le français, l'espagnol, le polonais, etc. est suffisant. Je ne connais pas assez le japonais et les autres langues "gênantes" (par exemple, écrire des instructions, etc.) pour faire toutes les préparations nécessaires dans le logiciel; et cela n'a aucun sens de dépenser beaucoup de temps et d'argent pour quelque chose qui n'arrivera probablement jamais de toute façon. BTW, le double octet n'est pas notre problème, nous utilisons Unicode partout: D
user281377

Il est logique que ce scénario, je suppose.
Jimmy Collins

Vous n'avez vraiment pas besoin d'en savoir beaucoup sur l'arabe et le japonais pour vous préparer à l'internationalisation. Il existe des directives générales qui sont généralement assez bonnes. Si vous prenez en charge plusieurs langues européennes et utilisez Unicode, vous êtes probablement la plupart du temps là-bas.
David Thornley

1

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.


Il est vrai que les nouvelles technologies de plate-forme ont été conçues en tenant compte de la localisation. D'après mon expérience avec iOS, c'est une procédure assez simple pour localiser ces types d'applications.
Jimmy Collins

1

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.