Technologie

Meilleures pratiques pour les connecteurs à grande échelle

Nous définissons une stratégie de connecteur à grande échelle comme étant celle qui produit plus de 5000 unités de travail dans BWX par demande de synchronisation. Une unité de travail dans BWX est une combinaison d'un fichier + d'une étape de flux de travail + d'une paire de langues. Ainsi, un projet avec 5 fichiers, 2 étapes de flux de travail (traduction + révision) et 5 langues donnera lieu à 50 unités de travail.
Gabriel Fairman
2 min
Table des matières

Nous définissons une stratégie de connecteur à grande échelle comme celle qui produit plus de 5000 unités de travail dans BWX par demande de synchronisation. Une unité de travail dans BWX est une combinaison d'un fichier + d'une étape de flux de travail + d'une paire de langues. Ainsi, un projet avec 5 fichiers, 2 étapes de flux de travail (traduction + révision) et 5 langues donnera lieu à 50 unités de travail. Vous pouvez voir à quel point il n'est pas difficile de dépasser les 5000 unités de travail lorsque vous commencez à multiplier ces variables. Il est tentant de vouloir centraliser tout dans un seul projet, mais notre expérience montre qu'avec des connecteurs à grande échelle, regrouper les projets par paire de langues est la meilleure solution. Cela peut sembler simplement une question de façon de définir un projet, mais cela va beaucoup plus loin que cela. Dans cet article, nous allons disséquer l'impact de cette décision en termes de :

  1. Message Brokering
  2. Résolution de problèmes
  3. Atténuation des risques
  4. File d'attente/performance
  5. Potentiel d'automatisation
  6. Facilité de gestion
  7. Scalabilité

Courtage de messages1) La messagerie croît de manière exponentielle avec des connecteurs à grande échelle. Nous avons vu des connecteurs qui créent plus de 1 million de messages par demande de synchronisation. Cela entraîne une activité énorme du serveur et des problèmes de performance qui peuvent être atténués en divisant les projets par locale.Résolution de problèmes2) Cela est directement lié à la réduction des risques. Mais en localisation, nous voyons souvent des problèmes qui sont limités à une locale donnée et comment cela affecte l'analyse, la segmentation et le pré/post-traitement d'un ensemble de fichiers donné. En dissociant les locales, vous pouvez créer des expressions régulières spécifiques à chaque locale, des règles de traitement et de segmentation qui offrent beaucoup plus de flexibilité en ce qui concerne l'architecture globale. Au lieu de travailler de manière restreinte avec des correctifs qui fonctionnent pour tous, vous pouvez itérer en fonction de la locale et finalement atteindre un comportement plus mature et prévisible lorsque vous travaillez en fonction des locales. Atténuation des risques3) En dissociant les projets en une locale par projet, vous atténuerez les risques de gestion car si quelque chose ne va pas dans une locale donnée, cela ne signifie pas que l'ensemble du mécanisme de demande de tirage/livraison est compromis. Vous pouvez isoler et compartimenter naturellement les problèmes. Cela peut ne pas sembler être une chose pendant la SOP, mais lorsque des problèmes inattendus surviennent (et ils surviennent toujours lors de la localisation), vous serez reconnaissant d'avoir construit une maison en briques plutôt qu'une maison en paille. File d'attente/Performance4) Au lieu de mettre en file d'attente 150 000 éléments par exemple, vous pouvez mettre en file d'attente 15 000 éléments dix fois. Encore une fois, cela ne semble pas être une grande différence puisque vous devrez finalement traiter les mêmes 150 000 éléments, mais avoir la flexibilité de les traiter séquentiellement, en parallèle ou de manière opportuniste vous donne beaucoup plus de flexibilité ainsi qu'une bande passante de performance accrue. Potentiel d'automatisation5) Les décisions et les flux de travail des projets seront généralement asymétriques d'une localité à l'autre. La séparation des projets par localité vous offre une flexibilité bien plus grande en termes de potentiel d'automatisation à long terme. Vous pouvez avoir un scénario où vous avez des paramètres entièrement différents ainsi que des ensembles de données lorsque vous séparez par région plutôt que de consolider tous les éléments ensemble. Gestion6) Celui-ci est également contre-intuitif. D'un point de vue de gestion, la consolidation est généralement la meilleure pratique pour une meilleure gouvernance. Mais dans les connecteurs à grande échelle, c'est le contraire. Un projet filtrera naturellement par localisation, permettant à différents chefs de projet de posséder plus facilement différentes parties du projet, réduisant ainsi l'utilisation de filtres pour générer des rapports et créant une plus grande simplicité en ce qui concerne le suivi de ce qui se passe par localisation. Scalabilité7) Avec des connecteurs à grande échelle, vous atteindrez un point où il devient tout simplement ingérable de regrouper toutes les unités de travail dans un seul projet. En les séparant, vous posez les bases d'un programme plus facile à mettre à l'échelle à long terme. N'oubliez pas que les choses se multiplient quand il s'agit d'unités de travail et de messages. En séparant par localisation, vous éliminez l'une des grandes variables de multiplication, ce qui vous permet de vous développer beaucoup plus facilement.ConclusionIl y a une illusion selon laquelle la consolidation est meilleure. Une demande de tirage par projet facilite la vie de tout le monde. Bien que cela soit vrai pour les connecteurs à petite échelle, cela s'effondre pour les connecteurs à grande échelle. Notre objectif est toujours de fournir les solutions les plus élégantes et fiables à nos clients et nous avons constaté encore et encore qu'avec des situations à grande échelle, la division et la conquête sont la voie à suivre.

Consolidation dans un seul projetSéparation par localisationLe projet entier a un statut de 0 ou 1Le statut peut être stratifié par localisationAnalyse, filtrage et cadre RegEx singuliersCadre flexible par localisationFile d'attente à une seule voie par projetFile d'attente et traitement flexibles distribuant naturellement le traitementFiltrage par localisation dans le projetUne étape de filtrage en moinsRègles d'automatisation qui fonctionnent pour tous les casParamètres et données d'automatisation spécifiques à la localisationTous les œufs dans le même panier d'un point de vue des risquesRisque réparti entre les localisationsComplexité pour isoler et résoudre les problèmesUne variable énorme en moins facilitant le dépannage

Libérez la puissance de la glocalisation avec notre système de gestion de traduction.

Libérez la puissance de la

stème de gestion de traduction.

Commencer
Gabriel Fairman
Founder and CEO of Bureau Works, Gabriel Fairman is the father of three and a technologist at heart. Raised in a family that spoke three languages and having picked up another three over the course of his life, he has always been fascinated with the role language plays in identity and the creation of meaning. Gabriel loves to cook, play the guitar, tennis, soccer, and ski. As far as work goes, he enjoys being at the forefront of innovation and mobilizing people and teams together toward a mission. In recognition of his outstanding contributions, Gabriel was honored with the 2023 Innovator of the Year Award at LocWorld Silicon Valley.
Traduisez deux fois plus vite et impeccablement
Commencez
Nos événements en ligne !
Webinaires

Essayez Bureau Works gratuitement pendant 14 jours

Intégration de ChatGPT
Commencer maintenant
Les 14 premiers jours sont gratuits
Assistance de base gratuite