Building Blocks
Traductions
Votre propre configuration dans chaque langue que parlent vos équipes. Traduisez une fois les noms de types, les libellés de champs et les statuts de workflow, avec l'IA en premier passage et une langue de référence pour vos traducteurs.
Mis à jour le 25 juil. 2026
Configuration · Building Blocks · 3.8
L’interface de Gfacility existe en plusieurs langues, mais ce que vous nommez ne se traduit pas tout seul. Un type de ticket appelé “Storing”, un champ personnalisé appelé “Kostenplaats”, un statut appelé “Wacht op leverancier” : ce sont vos mots, et un collègue dans un autre pays les voit exactement comme vous les avez tapés.
L’écran Traductions est l’endroit où vous donnez à ces mots une version par langue. C’est un Building Block pour la même raison que les classifications : vous le mettez en place une fois, au centre, et chaque module qui utilise le terme le reprend.
Pourquoi cela compte pour l’entreprise
"Nos collègues polonais ont une liste déroulante en néerlandais"
L'interface était traduite, vos noms de types non. C'est l'écran qui corrige cela.
"Les gens choisissent la mauvaise catégorie"
Un terme que l'on comprend à moitié est un terme que l'on devine. Des catégories devinées ruinent les rapports.
"Un déploiement dans un nouveau pays bloque sur les mots"
Traduisez la configuration existante au lieu de construire un second jeu de types en parallèle.
"Personne ne sait ce qu'il reste à traduire"
Une seule liste, filtrée par langue, montre les manques au lieu de les cacher sur dix écrans.
Ce que vous pouvez traduire
La liste est regroupée par ce à quoi le terme appartient, ce qui permet de traiter une sorte de chose à la fois.
| Colonne | Ce qu'elle vous dit |
|---|---|
| Type | De quelle sorte de fiche vient le terme, ce qui permet de traduire tous les types de tickets en une passe. |
| Champ | Quelle propriété est traduite : le nom, la description, un libellé. |
| Workflow | Pour les statuts, le workflow auquel le statut appartient. Le même mot peut signifier autre chose dans deux workflows. |
Langue source et référence
Choisissez une langue source : celle dans laquelle votre configuration a été construite à l’origine. Elle apparaît à côté de chaque ligne comme référence pour les traducteurs, afin que la personne qui remplit l’allemand lise votre formulation d’origine et non une traduction de traduction.
Ce seul choix est ce qui garde cohérente une installation en cinq langues. Traduisez tout depuis la source, jamais depuis le voisin le plus proche.
Traduire avec l’IA, puis relire
Une action Traduire avec l’IA comble les manques pour vous, avec le modèle utilisé consigné à côté. Traitez-la comme un premier passage, pas comme la réponse finale : elle est bonne sur le vocabulaire courant et mauvaise sur votre jargon interne, les abréviations et tout ce qui est un nom propre déguisé.
Vos modifications restent en attente jusqu’à l’enregistrement : vous pouvez donc traiter un lot puis enregistrer les modifications ou les abandonner d’un bloc.
Import et export
Exportez la liste, confiez-la à une agence de traduction ou à un collègue local, puis réimportez le fichier. L’import fusionne : les traductions existantes sont mises à jour et les manques comblés, un fichier à moitié rempli peut donc être réimporté sans risque et terminé plus tard.
Quelles décisions allez-vous prendre ?
Quelles langues soutenez-vous réellement ?
Chaque langue que vous activez est un engagement d'entretien. Deux bien faites valent mieux que six à moitié.
Qu'est-ce qui reste non traduit ?
Les noms de produits, les noms de bâtiments et les termes juridiques se laissent en général tels quels. Décidez-le une fois et écrivez-le.
Qui valide une langue ?
Un locuteur natif qui connaît aussi le processus. Une traduction correcte du mauvais concept reste fausse.
Quand traduisez-vous ?
Quand la configuration est stable. Traduire des types que vous renommez encore, c'est du travail fait deux fois.