Si je souhaite déployer mon logiciel à l'échelle internationale, quelles sont les considérations architecturales à prendre en compte ?

Question

J'envisage de développer des logiciels pour le marché international.

Quelles décisions architecturales dois-je prendre en compte en dehors de la simple conversion du texte d'une langue à l'autre ?

Answer 1

1. Recherchez et comprenez la prise en charge des logiciels localisés par votre plateforme.
2. Travaillez avec les outils de votre plateforme pour répondre à vos besoins.

Nous ne pouvons pas vraiment entrer dans les détails si nous ne savons pas si vous travaillez sur un Mac ou sur un système embarqué pour un micro-ondes.

Answer 2

Il n'y a pas d'information sur le type de projet sur lequel vous travaillez ici mais...

1) Faites en sorte que vos ressources soient facilement accessibles au traducteur. Cela dépend bien sûr de l'environnement dans lequel vous travaillez, mais la plupart d'entre eux disposent d'un moyen propre de le faire. Mettez cela en place dès le début afin d'éviter des projets de conversion massifs en cours de route.

2) Si votre environnement le permet, il serait bon de faire en sorte que l'interface utilisateur dans laquelle les traductions seront contenues puisse être configurée par langue (par exemple, les boîtes de dialogue). De cette manière, le traducteur (ou vous-même) peut adapter le chrome à la langue. Cela permet d'éviter les coupures de texte dans certaines langues qui sont beaucoup plus longues que d'autres. Ou, pire encore, j'ai vu des interfaces utilisateur mises en œuvre de manière à ce qu'il y ait d'énormes espaces entre les contrôles pour tenir compte de ces langues verbeuses (je vous regarde, l'allemand). La mise en œuvre du plus petit dénominateur commun devrait toujours être un signal d'alarme.

Answer 3

Vous n'avez fourni aucune information sur le type de logiciel ou de plate-forme. D'un autre côté, vous semblez vouloir écrire le logiciel, de sorte que vous n'êtes pas déjà pris avec une mauvaise décision.

Ce qui compte le plus, c'est l'affichage, et il faut donc séparer la fonctionnalité de l'affichage du reste. Ne pas, je le répète ne pas , de coder en dur les chaînes de caractères. Elles doivent être conservées dans un tableau de fonctions distinct, avec le contexte le plus complet possible. Ne codifiez pas en dur les dispositions d'affichage, d'autant plus que l'anglais est une langue très laconique dans la plupart des cas, et que la plupart des langues alphabétiques nécessitent généralement plus d'espace pour dire la même chose. Méfiez-vous de la casse, car les majuscules et les minuscules ont des fonctions différentes selon les langues. Veillez à utiliser Unicode pour tout le texte que l'utilisateur est susceptible de voir.

Gardez à l'esprit que les chaînes d'exception doivent être uniformes, si vous les utilisez, et que les messages d'erreur à consigner peuvent être mieux rédigés en anglais (ou dans votre langue maternelle), selon que c'est vous ou les locaux qui les examinent.

Quel que soit le système avec lequel vous travaillez, il est probable qu'il dispose d'une fonction de localisation. Utilisez-la pour tout ce qu'elle gère. Vous ne voulez pas écrire, par exemple, le 9 février comme 2/9/2009 en Grande-Bretagne, parce qu'ils le liront comme le 2 septembre. Les gens comprendront qu'un million s'écrive 1 000 000,0, mais pour certains, il s'agit d'une construction manifestement étrangère, et ils voudront qu'elle s'écrive 1 000 000,0.

Essayez d'éviter d'insérer des chiffres dans les phrases. En anglais, on dirait "1

M

G

I

T

Answer 4

T

L

R

S

• W

• A

• T

I

E