Autres langues Deutsch ; English ; Français ; Nederlands ; português brasileiro ; |
}}
Résumé : Il y a souvent une grosse confusion et une mauvaise utilisation des termes I18n et L10n. Ils sont liés, mais n’ont pas la même signification. Ils renvoient à différents niveaux de mise en œuvre et d’expertise, de sorte qu’une bonne compréhension est importante pour voir exactement où un problème, ou un besoin de développement, peut se poser. |
Contents
Que signifient ces acronymes ?
Bien, que signifient ces étranges acronymes ? En fait, ce sont des abréviations composées de la première et de la dernière lettre d’un mot, et entre les deux, il y a le nombre de lettres.
- I18n = Internationalization: i, ensuite 18 lettres, puis n
- L10n = Localization: l, ensuite 10 lettres, puis n
Remarque : En français, le terme localisation, transposition du faux ami anglais localization, est fréquemment utilisé, préférez régionalisation. |
C’est la même chose, non ?
Alors, me direz-vous, l’internationalisation et la régionalisation sont deux choses semblables, à vrai dire ; non.
Il y a beaucoup de malentendus, en partie parce que les concepts sont relativement nouveaux et aussi pour des raisons historiques. Traditionnellement, le support dans les ordinateurs au-delà de l’anglais en tout et pour tout a été fait, au début du moins, sous la forme de plusieurs solutions au cas par cas, qui étaient adaptées seulement à une langue. Vous avez donc régionalisé cet OS pour, par exemple, le français, et cette autre version pour l’espagnol. Ils pourraient bien être incompatibles même si les deux langues peuvent en fait partager un jeu de caractères commun (et assez simple).
Autrement dit, historiquement, L10n a précédé la réflexion sur I18n.
Mais, sur le plan conceptuel, I18n doit passer en premier, car l’internationalisation est le processus qui consiste à s’assurer qu’un logiciel est suffisamment flexible, et, prêt à prendre en charge plusieurs régionalisations potentielles. Aucune langue n’est impliquée dans le processus I18n. Une application peut très bien rester dans une version originale, mais si elle est correctement internationalisée, sa traduction est assez facile (et, surtout, ne nécessite aucun développement ni aucune compétence informatique, seulement la connaissance de la langue cible). L’internationalisation consiste donc à rendre les logiciels « adaptables au contexte régional ».
D’autre part, la régionalisation consiste essentiellement (voir ci-dessous) à traduire dans une langue bien précise et réelle. La régionalisation, en soi, n’exige pas l’internationalisation, cependant si l’application n’a pas d’abord été internationalisée, cela signifie que le processus de régionalisation impliquerait des modifications de très bas niveau dans le code source de l’application, soit, des compétences en développement. Autrefois (dans l’ancien temps, la plupart d’entre vous ne le savent pas, vous avez de la chance), la régionalisation se faisait parfois en éditant simplement le code source et en changeant les chaînes de texte dans la source. Cela mène à deux binaires différents ou plus, c’est-à-dire deux produits différents (ou plus) à supporter, avec des versions différentes, un suivi des bogues, etc. Ils sont parfois même incompatibles entre eux. Et, si vous vouliez porter l’application vers une autre langue, il était nécessaire de tout recommencer (et se résoudre à choisir la version la plus adaptée à vos besoins). De plus, il n’y a jamais eu de vue d’ensemble convenable et généralisable du problème. Si la traduction vers une nouvelle langue avec des besoins spécifiques était requise, celle-ci pourrait bien tout casser parce qu’elle n’avait pas été planifiée.
Donc, L10n sans I18n est mauvais, très mauvais. Espérons que cela soit rare de nos jours, et en particulier dans le monde du logiciel libre. Dans notre monde du logiciel libre, nous avons de très bonnes infrastructures de développement d’internationalisation (framework), intégré au cœur des boîtes à outils les plus courantes (un toolkit est un ensemble d’outils et de modules à partir desquels les développeurs construisent des applications). Ces infrastructures logicielles sont suffisamment génériques pour soutenir et englober tous les systèmes d’écriture utilisés à l’heure actuelle.
Les concepts I18n et L10n sont deux couches différentes. Elles sont interconnectées, mais se situent à différents niveaux. En d’autres termes, cela implique des personnes différentes, avec des compétences à part. C’est important à savoir, car signaler un problème au mauvais niveau n’aidera pas à le résoudre.
I18N
L’internationalisation est le processus par lequel une application est rendue « internationale ». En d’autres termes, permettre la prise en charge de pratiquement n’importe quelle langue ou contexte local au monde.
Cela implique toujours des changements dans le code source, c’est-à-dire que cela implique des développeurs (qui doivent également avoir une bonne connaissance de la problématique I18n). Il y a différents aspects de I18n, certains plus complexes que d’autres :
- la possibilité d’afficher/imprimer du texte
- la prise en charge de toutes les polices de caractères complexes
- la prise en charge de la normalisation des caractères
- la prise en charge de la substitution et du rendu de glyphes (il n’y a pas d’équivalence entre le caractère et le glyphe. Il existe plutôt des séquences de caractères qui peuvent avoir une seule séquence de glyphes dans le cas le plus simple.) pour produire certaines classes de glyphes (dans le cas le plus simple un seul caractère)
- la prise en charge de la réorganisation des glyphes (l’affichage ne suit pas toujours le même ordre que celui logiquement parlé ou écrit).
- la prise en charge du rendu bidirectionnel (de gauche à droite et de droite à gauche)
- capacité à manipuler le texte
- la prise en charge des manipulations de chaînes de texte dans les programmes
- le support pour la sélection de la souris, le copier-coller, etc. notez que vous sélectionnez glyphes à l’écran, mais que le cache sélectionne le texte (caractères) => substitution complexe nécessaire)
- la fourniture d’utilitaires de conversion de jeux de caractères (parce que nous devons faire face à l’héritage de pré-unicode)
- la recherche de texte (grep, etc)
- le tri de texte en fonction de règles complexes
- possibilité de saisir du texte
- la prise en charge de la configuration des claviers
- la prise en charge de la liaison avec des applications de saisie pour les cas complexes où un mappage de clavier ne suffit pas
- capacité à manipuler/présenter date/heure
- le masque/format d’entrée
- la définition du premier jour de la semaine
- la définition du fuseau horaire
- la définition des calendriers non grégoriens
- les fonctions de conversion entre différents formats/calendriers
- possibilité de définir et de gérer les paramètres locaux
- les différentes unités (km/miles °C/°F, etc.), monétaire, etc
- les différentes façons de formater/afficher les chiffres.
L10N
La régionalisation est le fait de rendre une application « régionalisée », c’est-à-dire de travailler dans un contexte local bien précis et adapté à l’utilisateur.
Cela n’implique aucun changement dans le code source. Les développeurs ne sont pas impliqués (enfin, à peine plus, juste pour ajouter le premier crochet. Quand une langue est disponible, un développeur doit la mettre dans une liste, donner accès à l’équipe L10n, etc).
L10n consiste à fournir le contenu pour remplir les contenants que le système i18n a créés.
Les divers aspects sont :
- la traduction de données textuelles exprimable (c’est la plus célèbre)
- fournir des textes précis et uniques (non pas une traduction d’un écrit existant, mais un texte indépendant), le cas échéant
- correcteurs orthographiques (voir ci-dessous)
- disposition du clavier
- méthodes de saisie (voir ci-dessous)
- règles de tri
Comme je l’ai dit (Auteur : Srtxg), ces projets n’impliquent pas de développeurs. Eh bien, dans certains cas, il peut y avoir du développement. Il s’agit de choses très particulières, comme la création d’un nouveau correcteur orthographique, propre à une langue ou à une famille de langues, ou d’un programme de méthode de saisie (mais il existe aussi des correcteurs orthographiques et des méthodes de saisie génériques pour lesquels vous devez uniquement fournir des données L10n.)
Pour faire court
- L10n : Les problèmes de L10n concernent seulement les traducteurs d’une langue donnée. Personne d’autre ne s’en soucie ou ne peut y faire quoi que ce soit. Seuls les traducteurs de cette langue sont en mesure de résoudre le problème.
- I18n : Les problèmes I18n sont un problème dans l’infrastructure I18n. Cela peut concerner de nombreuses langues. Mais les traducteurs ne peuvent rien faire pour y remédier, seuls les développeurs ont la capacité de résoudre le problème.