Bonjour
actuellement le récupération des libellés d’un élément est systématiquement limité par la langue de l’utilisateur.
Nous avons rencontré plusieurs cas où nous souhaiterions avec accès à une autre traduction.
Exemple :
accéder à la traduction d’un objet externe. Actuellement accessible par le getDisplay et qui impose la langue de l’utilisateur “public”. Je sais que @david a proposé des contournements acceptables (cf : Changer le langage d’affichage d’un objet externe
un administrateur voulait contrôler le rendu d’un objet dans toutes les langues possibles sans avoir à changer la langue de son compte à chaque fois.
nous avons un objet “Modification” contenant 30 champs. Cet objet peux être de type “Message” ou “Périmètre” avec 10 champs communs. Dans un tableau commun, on affiche uniquement les 10 champs communs. Le client a voulu une 11e colonne “Description” affichant une concaténation les champs principaux (exemple pour un objet typé “Message”, la description contient le nom du récepteur et le libellé du message, pour un objet typé “Périmètre”, la description contient le nom du périmètre et la date du déploiement). Nous partions sur un champ calculé malheureusement cela était coûteux en temps). Nous sommes donc parti sur un champ calculé au save et enregistré en base. Nous souhaiterions donc créer cette description en fr et en anglais. Nous avons donc besoin d’accéder aux traductions autres que celles de l’utilisateur courant.
Serait-il donc possible de faire évoluer vos méthodes getDisplay et getLabel afin de pouvoir préciser la langue désirée ?
Bonjour David,
je confirme que cette limitation est source de grande frustration pour nos développeurs qui font face à des demandes de nos PO dont l’imagination dépasse les limites - si souvent repoussées - du runtime…
En effet, le fait que ce soit possible au niveau des objets, actions, domaines, etc. est déjà très intéressant (notamment pour pour préparer l’information “à destination” d’un autre utilisateur dotn la langue est différente de la langue de l’utilisateur à l’initiative de l’opération réalisée. Par exemple, préparer une notification traduite dans la langue du destinataire (et pas dans la langue de l’émetteur).
Le cas le plus impactant est de ne pas en disposer sur les ObjectFields, les alertes et les textes statiques (tous impliqués dans la construction de nos notifications)…
Le cas de l’objet externe est en effet très particulier et isolé (et nous avons d’autres solutions sous le coude).
Oui pour l’objet externe c’est pour cela que j’ai proposé un workaround.
Sinon je suis en phase, ce que j’appelle les “items principaux” c’est typiquement les attributs d’objet, listes de valeur, … Il y a des APIs “bas niveau” qui permettent de récupérer les traductions mais ce serait mieux d’avoir ça dans les classes usuelles comme ObjectField, ListOfValues etc. au même niveau que ce qu’il y a dans ObjectDB, Action, etc.
Je note le besoin pour le designer (ou n’importe qui) de changer de langue plus simplement
sans passer par son formulaire User / via mini-profil du header + reload de la page
ou “bouton” directement dans le template editor pour un designer polyglotte
La langue est une simple information de session de l’utilisateur, mais la lanque fait partie de la clé des objets en mémoire pour chaque utilisateur. Leur donner N langues-instances d’objets est faisable mais avec de nombreux impacts sur la mémoire utilisée (x2 si 2 langues dans la même session…alors que seules les traductions changent).
Historiquement les objets communs (field, liste…) sont instanciés par langue, donc fournir l’info d’une autre langue est une requête en base et non l’usage de l’instance en cache. Il faudrait à ce niveau revoir le cache d’objet pour les rendre multi-langues (comme View, Alert…).
j’ai le même besoin de pouvoir changer de langue facilement.
La région a remporté un appel d’offre pour les projets de recherche européen.
Les chercheurs étrangers doivent pouvoir déposer des projets.