From time to time we want to show the translation of domain elements in combined strings. For the time being there isn't really an option to get the translations from the SF (except for some laborious dynamic code), so we tend to translate them hardcoded (eg. case when 1 then 'male'...). To us it would seem to make a lot of sense to have a function that gets the translation like the GUI would show it. So something like dbo.tsf_get_translation @language_id, @object_id (or smth. like that).
Now it would also be great if we could ask the GUI what the current language is set to...
+21- Superhero
- 495 replies
I like the idea, I often need this functionality, to create functionality for value lists which are maintained by end users. Think about product catalogs etc.
For me just a function dbo.tsf_user_language() would help a lot and a similar kind of function that would be useful is dbo.tsf_user_timezone()
For me just a function dbo.tsf_user_language() would help a lot and a similar kind of function that would be useful is dbo.tsf_user_timezone()
Logic will get you from A to B. Imagination will take you everywhere (Albert Einstein)
- Captain
- 110 replies
I would also like to have a function to get the translation of a message from the model, in the current language, with variables (e.g. validation messages - MRP).
- Apprentice
- 8 replies
We also experience the same problem so i hope a solution can be provided by Thinkwise.
Kind regards
Ronald
+12This solution would definitely help us too!
In extension to this idea it would also be great to be able to use the Layout procedure on domain Elements. We often have situations (especially on status fields) were a user is only allowed to use certain element values or to move it from one element to one other element. Now if it were possible to show/hide certain Elements in the Layout procedure we wouldn’t have to work with workarounds like creating two similar Domains and using Layout logic to determine which one to show. Maintaining two (or more) similar Domains with Elements is both risky and ugly.
It would be good enough if somehow the Layout procedure recognizes Domain with Element type of fields and we can write logic on each individual Element within that Domain.
Anyone else seeing the value of this addition?
+9Hello
If I understand you correctly, you are looking for this idea which already exists:
We are working on this already. 2021.2 will be a bit too soon, but we expect to deliver this in the nearby future.
+12But in addition to the above, we often have situations in which a value is only supposed to change from A to B (not directly to C or D), or that a given user is allowed to use only certain status, while another user might be allowed to use more options.
My suggestion is more closely related to this idea (of which I'm not sure it will be covered by the Inactive Domain Elements Idea it was merged to), but instead of a Variant I'm suggesting the ability to use the various Elements in the Layout Procedure, which would allow us to hide specifiek elements based on above use cases.
- 678 replies
In the last releases of Indicium, and soon available in the Windows and Web GUIs, a session variable is added that provides the language of the current user. This makes it possible to automatically generate a function that returns the translation of model objects in the user language.
See this code sample for instructions:
Translating model objects in business logic | Thinkwise Community (thinkwisesoftware.com)
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.