Le consortium Unicode annonce ICU4X 1.0, sa nouvelle bibliothèque d'internationalisation hautes performances
Le consortium Unicode annonce ICU4X 1.0, sa nouvelle bibliothèque d'internationalisation hautes performances.
Elle est écrite en Rust, avec des wrappers C++ et JavaScript officiels disponibles
International Components for Unicode (ICU) est un projet open source de bibliothèques C/C++ et Java matures pour la prise en charge d'Unicode, l'internationalisation des logiciels et la mondialisation des logiciels. ICU est largement portable sur de nombreux systèmes d'exploitation et environnements. Il donne aux applications les mêmes résultats sur toutes les plateformes et entre les logiciels C, C++ et Java. Le projet ICU est un comité technique du Consortium Unicode et sponsorisé, soutenu et utilisé par IBM et de nombreuses autres sociétés.
Pour la petite histoire, après l'intégration de Taligent à IBM au début de 1996, Sun Microsystems a décidé que le nouveau langage Java devrait mieux prendre en charge l'internationalisation. Étant donné que Taligent avait de l'expérience avec ces technologies et était géographiquement proche, son groupe Texte et international a été invité à contribuer aux classes internationales dans le kit de développement Java dans le cadre des API d'internationalisation du JDK 1.1. Une grande partie de ce code existe toujours dans les packages java.text et java.util. D'autres fonctionnalités d'internationalisation ont été ajoutées avec chaque version ultérieure de Java.
Les classes d'internationalisation Java ont ensuite été portées en C++ et C dans le cadre d'une bibliothèque connue sous le nom d'ICU4C ("ICU for C"). Le projet ICU fournit également ICU4J ("ICU for Java"), qui ajoute des fonctionnalités non présentes dans les bibliothèques Java standard. ICU4C et ICU4J sont très similaires, mais pas identiques ; par exemple, ICU4C inclut une API d'expression régulière, contrairement à ICU4J. Les deux frameworks ont été améliorés au fil du temps pour prendre en charge de nouvelles installations et de nouvelles fonctionnalités d'Unicode et de Common Locale Data Repository (CLDR).
ICU est sorti en tant que projet open source en 1999 sous le nom d'IBM Classes for Unicode. Il a ensuite été renommé International Components For Unicode. En mai 2016, le projet ICU a rejoint le consortium Unicode en tant que comité technique ICU-TC, et les sources de la bibliothèque sont désormais distribuées sous la licence Unicode.
Annonce de ICU4X 1.0
ICU a annoncé la disponibilité de la version ICU4X 1.0.
Voici ce que l'équipe dit à propos d'ICU4X :Envoyé par ICU
- Léger: ICU4X est la première bibliothèque d'Unicode à prendre en charge le découpage de données statiques et le chargement de données dynamiques. Avec ICU4X, les clients peuvent inspecter leur code compilé pour créer facilement de petits packs de données de paramètres régionaux optimisés, puis charger ces packs de données à la volée, permettant aux applications de s'adapter à plus de langues que jamais auparavant. Même lorsque la plateforme i18n est disponible, ICU4X convient comme polyfill pour ajouter des fonctionnalités ou des langues supplémentaires. Il le fait en utilisant très peu de RAM et de processeur, ce qui contribue à prolonger la durée de vie de la batterie des appareils.
- Portable : ICU4X prend en charge plusieurs langages de programmation prêts à l'emploi. ICU4X peut être utilisé nativement dans le langage de programmation Rust, avec des wrappers officiels en C++ via l'interface de fonction étrangère (FFI) et JavaScript via WebAssembly. Plus de langages de programmation peuvent être ajoutés en écrivant des plugins, sans avoir besoin de toucher à la logique de base i18n. ICU4X permet également de mettre à jour les fichiers de données indépendamment du code, ce qui facilite le déploiement des mises à jour Unicode.
- Sécurisé: le système de type et le modèle de propriété de Rust garantissent la sécurité de la mémoire et la sécurité des threads, empêchant ainsi de grandes classes de bogues et de vulnérabilités.
Pourquoi ICU4X ?
Vous vous demandez peut-être encore ce qui a poussé le Consortium Unicode à choisir une nouvelle bibliothèque basée sur Rust comme solution à ces problèmes ?
Le consortium Unicode publie également les bibliothèques ICU4C et ICU4J, i18n écrites pour C/C++ et Java. Pourquoi écrire une nouvelle bibliothèque à partir de rien ? Cela n'augmenterait-il pas le fardeau de la maintenance continue ? Pourquoi ne pas plutôt concentrer nos efforts sur l'amélioration de l'ICU4C et/ou de l'ICU4J ?
ICU4X résout un problème différent pour différents types de clients. ICU4X ne cherche pas à remplacer ICU4C ou ICU4J ; il cherche plutôt à remplacer le grand nombre de bibliothèques i18n non Unicode, souvent non entretenues et souvent incomplètes qui ont été écrites pour apporter i18n à de nouveaux langages de programmation et à des environnements à ressources limitées. ICU4X est un produit qui a longtemps disparu du portefeuille d'Unicode.
Dès le début, l'équipe a évalué si les objectifs d'ICU4X auraient pu être atteints en refactorisant ICU4C ou ICU4J. Elle a trouvé que:
- ICU4C a déjà traversé une période d'optimisation pour l'agitation des arbres et la taille des données. Malgré ces efforts, nous continuons d'avoir des parties prenantes qui disent que l'ICU4C est trop grand pour leur environnement aux ressources limitées. Obtenir de nouvelles améliorations dans ICU4C reviendrait à réécrire une grande partie de la base de code d'ICU4C, ce qui devrait être fait de manière à préserver la rétrocompatibilité. Ce serait un grand effort d'ingénierie avec un résultat final incertain. De plus, l'écriture d'une nouvelle bibliothèque nous permet d'optimiser davantage pour les environnements natifs UTF-8 modernes.
- À l'exception de JavaScript via j2cl, Java n'est pas un langage source approprié pour la portabilité dans des environnements à faibles ressources comme les appareils portables. De plus, ICU4J comporte de nombreuses parties interdépendantes qui nécessiteraient beaucoup d'efforts pour être amenées à un état où elles pourraient être une source j2cl viable.
- Certaines de nos parties prenantes (Firefox et Fuchsia) sont attirées par la sécurité de la mémoire de Rust. Comme la plupart des projets C++ complexes, ICU4C a eu sa part de CVE, principalement liés à la sécurité de la mémoire. Bien que les outils de diagnostic C++ s'améliorent, Rust a des garanties très solides qui sont impossibles dans d'autres piles logicielles.
Pour toutes ces raisons, l'équipe a décidé qu'une bibliothèque basée sur Rust était le meilleur choix à long terme.
Pourquoi utiliser ICU4X alors qu'il y a i18n dans la plateforme ?
Beaucoup des mêmes personnes qui travaillent sur ICU4X travaillent également pour rendre i18n disponible dans la plateforme (navigateur, système d'exploitation mobile, etc.) via des API telles que l'objet ECMAScript Intl, android.icu et d'autres bibliothèques natives pour smartphone. ICU4X complète les solutions basées sur la plateforme en tant que polyfill idéal :
- Certaines fonctionnalités de la plateforme i18n prennent 5 ans ou plus pour obtenir une disponibilité suffisamment large pour être utilisées dans les applications côté client. ICU4X peut combler l'écart.
- ICU4X peut permettre aux clients d'ajouter plus de paramètres régionaux que ceux disponibles sur la plateforme.
- Certains clients préfèrent un comportement identique de leur application sur plusieurs appareils. ICU4X peut leur donner ce niveau de cohérence.
- Finalement, nous espérons qu'ICU4X soutiendra les implémentations de plateforme dans ECMAScript et ailleurs, offrant une cohérence maximale lorsque ICU4X est également utilisé comme polyfill.
Pourquoi des données enfichables ?
L'un des écarts les plus visibles entre ICU4X et ICU4C et ICU4J est un argument de fournisseur de données explicite sur la plupart des fonctions constructeur. Le fournisseur de données ICU4X prend en charge les cas d'utilisation suivants :
- Fichiers de données lisibles par les versions plus anciennes et plus récentes du code.
- Fichiers de données pouvant être échangés lors de l'exécution, ce qui facilite la mise à niveau des versions de base de données Unicode, CLDR ou de fuseau horaire. L'échange de nouvelles données peut être effectué au moment de l'exécution sans qu'il soit nécessaire de redémarrer l'application ou d'effacer les caches internes.
- Sources de données multiples. Par exemple, certaines données peuvent être intégrées à l'application, certaines peuvent provenir du système d'exploitation et certaines peuvent provenir d'un service HTTP.
- Caches de données personnalisables. Nous reconnaissons qu'il n'y a pas d'approche unique pour la mise en cache, nous permettons donc au client de configurer son pipeline de données avec le type de cache approprié.
- Replis et superpositions de données entièrement configurables. Les champs individuels des données ICU4X peuvent être remplacés de manière sélective lors de l'exécution.
Source : Unicode
Et vous ?
Que pensez-vous de ce projet ?
Voir aussi :
Répondre avec citation
Partager