Skip to main content
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...
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()
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).

We also experience the same problem so i hope a solution can be provided by Thinkwise.

 

Kind regards

 

Ronald


Updated idea status On the backlogPlanned

This 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?

@Jasper is this something that can be covered as part of this Idea and can be squeezed in the upcoming 2021.2 release, or would it need its own Idea?

 

 

 


Hello @Arie V,

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.


@Jeroen van den Belt I'm not sure my part will be covered in the idea referenced by you (which I also support by the way), but let me add my comment there too. Marking Domain Elements as Inactive should result in the situation in which existing data can still have this Element, but should not be available in the Domain dropdown any longer for new/edited records for ALL users.

But 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.

 


 Created a seperate Idea here: 

 


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)


Updated idea status PlannedCompleted