Bonjour, Habr! Je vous présente la traduction du matériel «Technologies de localisation chez Netflix» écrit par l'équipe Netflix sur les processus et programmes de localisation internes conçus spécifiquement pour cela.
Le programme de localisation de Netflix est basé sur trois principes: une linguistique impeccable, une atmosphère harmonieuse dans l'équipe et des technologies avancées.
Nous n'avons pas peur d'expérimenter et d'essayer de nouveaux processus et outils, de s'opposer aux normes généralement acceptées en localisation - grâce à cela, nous sommes arrivés si loin! Travailler chez Netflix signifie être un pionnier.
Dans cet article, nous parlons de deux technologies qui nous mèneront à la domination MONDIALE ... Plus sous la coupe.
Référentiel de chaînes global Netflix
Netflix n'a pas réussi parce que nous créons du contenu de qualité, mais parce que nous livrons ce contenu. La plupart du succès est une interface utilisateur (UI) intuitive, facile à utiliser et localisée. Netflix est disponible sur différentes plateformes: la version Web, Apple iOS, Google Android, Sony PlayStation, Microsoft Xbox, téléviseurs Sony, Panasonic, etc. Chacune de ces plates-formes a ses propres exigences en matière d'internalisation, ce qui constitue un sérieux défi pour notre équipe.
Voici quelques exemples où la localisation de l'interface utilisateur est requise:
- ajouter une nouvelle langue
- ajout de nouvelles fonctionnalités
- modifications des textes et données existants
La traduction de texte pour l'interface utilisateur n'est pas un processus automatisé; pendant la traduction, les responsables de la localisation travaillent avec l'équipe de développement afin de comprendre clairement à quoi appartient telle ou telle ligne, dans quelles langues elle doit être traduite et à quelle heure les fichiers localisés doivent être fournis. Cela devient beaucoup plus compliqué lorsque plusieurs fonctionnalités sont développées en parallèle et exécutées dans différentes branches Git.
Une fois la traduction terminée, l'application est assemblée, testée et placée sur la plateforme. Certains appareils nécessitent une confirmation tierce (par exemple, d'Apple). Tout cela provoque un retard indésirable dans les délais. Les cas de changements d'urgence sont particulièrement désagréables.
Mais que faire si nous rendons le processus de localisation ouvert à toutes les parties prenantes - à la fois pour l'équipe de développement et pour les localisateurs? Que faire si nous n'avons plus besoin de reconstruire les versions à chaque fois que nous apportons des modifications au texte?
Pour résoudre ces problèmes, nous avons développé un référentiel de chaînes d'interface utilisateur global appelé Global String Repository; des chaînes localisées sont stockées ici, qui sont substituées dans l'environnement pour l'exécution de code. Nous avons intégré le Global String Repository dans le processus de localisation, afin qu'ils se complètent.
Global String Repository sépare les packages de localisation et l'espace de noms (espaces réservés). Le package de localisation stocke toutes les données ligne par ligne dans toutes les langues. Les espaces réservés sont des espaces réservés pour les packages sur lesquels l'équipe travaille. Pendant le développement, des espaces réservés standard sont utilisés. Le workflow ressemble à ceci:
- Le développeur apporte des modifications à la version anglaise de la chaîne dans le package (dans l'espace de noms de l'espace réservé)
- Le processus de traduction démarre automatiquement
- Les linguistes terminent la traduction
- Les traducteurs mettent à disposition des kits d'espaces réservés
Lorsque l'intégration avec le référentiel de chaînes global se produit, il existe deux types de comportement d'application:
- Au moment de l'exécution: vous permet d'apporter rapidement des modifications à l'interface utilisateur
- Pendant l'assemblage: utilisation du Global String Repository séparément pour la localisation et des paquets de données avec l'assembly (build)
Le référentiel de chaînes globales permet l'intégration pendant la phase de génération en fournissant un accès aux données localisées via l'API REST.
Nous ouvrons le référentiel de chaînes global via l'API Netflix, de sorte que la même mise à l'échelle et les mêmes exigences s'appliquent à lui que les métadonnées des autres API. Pour les applications qui s'intègrent au moment de l'exécution, c'est une partie critique. Nous avons 60 millions d'utilisateurs qui exécutent Netflix sur différents appareils, le Global String Repository est donc une priorité.
Comme Netflix, le Global String Repository a une architecture de microservices. Microservice est une application Web Java (implémentée dans Apache Cassandra et ElasticSearch) qui est hébergée dans trois régions AWS. Nous collectons des statistiques pour chaque demande d'API.
L'interface Global String Repository est développée sur Node.js, Bootstrap et Backbone et hébergée dans AWS.
Côté utilisateur, le Global String Repository utilise l'API REST pour récupérer des données et propose un client Java avec mise en cache intégrée.
Malgré le fait que nous avons parcouru un long chemin et développons activement le Global String Repository, nous avons quelque chose à rechercher. Voici ce sur quoi nous travaillons actuellement:
- Nous développons la prise en charge des chaînes avec des variables numériques et des chaînes avec des identificateurs de genre
- Nous développons la robustesse de nos solutions techniques
- Amélioration des processus de mise à l'échelle
- Nous prenons en charge l'exportation vers différents formats (Android XML, Microsoft .Resx, etc.)
Le Global String Repository n'est pas lié au domaine commercial Netflix, nous prévoyons donc de le publier en tant que logiciel open source.
Hydra
Netflix - un service mondial qui prend en charge de nombreux paramètres régionaux dans une myriade de combinaisons différentes sur différents appareils / UI; le test manuel n'est pas approprié dans ce cas. Auparavant, l'équipe de localisateurs et de développeurs d'interface utilisateur a tout testé manuellement sur différents appareils - des consoles à iOS et Android; c'est ainsi que nous avons vérifié la conformité de toutes les lignes avec le contexte et l'interface utilisateur (par exemple, s'il y avait un «découpage» du texte).
Mais la philosophie de Netflix est que nous visons l'excellence. Cette approche nous permet de repenser ce que nous faisons. Hydra est donc née.
La tâche d'Hydra est de créer un catalogue de toutes les options possibles pour un écran unique qui montrera exactement l'écran requis (la recherche est effectuée par des filtres, par exemple, vous pouvez sélectionner un appareil et des paramètres régionaux). Par exemple, en tant que spécialiste de la localisation en allemand, vous pouvez configurer le filtrage afin de voir tout le chemin parcouru par les utilisateurs non enregistrés sur la PS3, le site Web et Android. Les mêmes écrans peuvent être visualisés au rythme auquel l'utilisateur les ouvrira sur son appareil.
Travailler avec des écrans dans Hydra
Hydra ne fonctionne pas directement avec les écrans; il sert à les cataloguer et à les afficher. Pour prendre un affichage d'écran du catalogue Hydra, nous utilisons notre modèle d'automatisation d'interface utilisateur. Avec Jenkins CI, les tests pilotés par les données s'exécutent en parallèle dans tous les environnements locaux pris en charge: cela crée des captures d'écran qui sont publiées sur Hydra avec les métadonnées appropriées (nom de page, zone de fonction, plate-forme d'interface utilisateur et une seule pièce critique de métadonnées - une définition unique à l'écran).
Une définition d'écran unique est nécessaire pour compiler un catalogue complet d'écrans sans fausses correspondances. Cela vous permet de comparer un plus grand nombre d'écrans à long terme, car l'image de chaque écran est comparée à elle-même. La définition d'un écran unique diffère de l'interface utilisateur à l'interface utilisateur; pour un navigateur, il s'agit d'une combinaison du nom de la page, du navigateur, de la résolution, de l'environnement local et de l'environnement de développement.
La technologie
Hydra est une application Web AWS à pile complète. Le back-end Java a deux fonctions principales: il traite les captures d'écran entrantes et fournit des données pour le back-end via l'API REST.
Lorsque l'automatisation de l'interface utilisateur envoie l'écran à Hydra, le fichier image lui-même est écrit dans S3, ce qui garantit son stockage infini (plus ou moins), et des métadonnées beaucoup plus petites sont écrites dans la base de données RDS, afin que plus tard, il puisse être demandé via l'API REST. Les points de terminaison REST (points de terminaison REST) affichent les paramètres de chaîne de requête pour les requêtes MySQL.
Par exemple:
REST/v1/lists/distinctList?item=feature&selectors=uigroup,TVUI;area,signupwizard;locale,da-DKCette demande contient des paramètres pour sélectionner les données nécessaires dans la base de données:
select distinct feature where uigroup = 'TVUI' AND area = 'signupwizard' AND locale = 'da-DK'Le front-end JavaScript, qui utilise knockout.js, permet aux utilisateurs de sélectionner des filtres et d'afficher des écrans qui correspondent à ces filtres. Le contenu des filtres, ainsi que les écrans qui correspondent aux filtres sélectionnés, sont fournis par les appels aux points de terminaison REST mentionnés ci-dessus.
Mise à l'échelle de l'application
Après l'installation d'Hydra et le démarrage de l'automatisation, l'ajout de nouveaux paramètres régionaux est aussi simple que l'ajout d'une ligne à un fichier de propriétés existant, qui est envoyée au fournisseur de données du framework testNG. Les écrans avec une nouvelle locale seront affichés avec les builds Jenkins qui fonctionnent.
Et ensuite?
Nous devons implémenter une fonction qui avertira que l'écran a changé. Pour le moment, si la ligne change, il n'y a rien qui en informerait automatiquement. Hydra peut se transformer en une file d'attente plus ou moins fonctionnelle, et les experts en localisation pourront alors se connecter au système et ne voir qu'un ensemble spécifique d'écrans qui ont changé.
Une autre caractéristique est la possibilité de mapper des lignes de touches individuelles sur les écrans que vous souhaitez afficher. Cela permettra au traducteur de modifier la ligne, puis d'effectuer une recherche de clé et de voir les écrans affectés par ce changement; le traducteur verra donc à l'avance comment cette ligne change de contexte.
Nous n'avons pas peur de résoudre des problèmes complexes. Netflix deviendra un service mondial et notre équipe de localisation s'agrandira. Ces défis nous permettent d'attirer les personnes les plus talentueuses et nous créons une équipe qui peut faire ce qui est considéré comme impossible.