Copy translation from column -> task/report parameter

A great idea that could indeed help out a lot when an entity already has the required translations!

I would also like the option to copy the translation even though the “name” does not exactly match, though this should not be a default action. There are sometimes entities that slightly have their name deviate because over time ideas could change what is a good naming policy or because multiple developers work on a project.

I would suggest to make it even more automatic, so when a a translation object exists for a object type (column, task/report parameter) and then a different object type with the same name is created, it would inherit the translation upon creation (inherit from the last created object type in case the two others exists and deviate). 

This way it adds no extra action to use the same translation, and you still have the option to deviate after creation.

As mentioned earlier, there are two options for this idea:

• Manually apply the translation using tasks

• Automatically apply the translation

Manually apply the translation using tasks

If we implement this idea, we’ll need to consider not just column and task parameters, but also report parameters. Focusing on a report parameter, as an example: how do you decide whether to take the translation from the column or task parameter? Should this result in two separate tasks? One task with more options? Or no options at all, and simply apply the most frequently used translation overall?

Automatically apply the translation

Similar questions arise here. How do you determine whether the translation should come from the column or task parameter? And should approval status be carried over as well? An argument for doing so is that the original translation is already linguistically correct. An argument against is that you might become blind to alternative translations that could be more suitable, which is why you might still want to (have someone) review whether it’s the most appropriate translation for that specific context.

Call to action

How do you think about these considerations and questions? I’ll tag everyone who has been involved in this ticket so far (via replies or votes), but of course others are more than welcome to contribute their thoughts as well.

​@Arjan Sollie, ​@Mark_Plaggenborg, ​@PeterKeeris, ​@Anne Buit, ​@John Lunenburg, ​@Martin, ​@Jochem Pieper, ​@Dick van den Brink, ​@Emmie Baris, ​@Mattijs

​@Jeroen van den Belt ,

I think the manually option would suite me best. In this option I should be able to select from which translation object I am using the translation (task bar, report bar or column), depending on which have already been set. And of course, exclude the option for which I am copying it.

If you would like to go with the automatic option, then use the last set translation.

Regarding approval, I would prefer that it is not approved by default. If for some reason this is not correct, it would appear during the approval phase of the translations.

​@Jeroen van den Belt I can find myself in the reply made by Arjan Sollie.

An automatic option would currently not be very welcome for our situation as the 33 languages (at time of writing) have not always been accurately maintained and there is risk using sources which would not be the best option to also apply on new objects. For one translation the Task parameter is the more complete/accurate, but for another a Column would be the better source.

Hence our desire as well to use Manual task use.

A task to manually to copy a translation from one object to other objects with the same name would be great. Copy the translation to objects which have no translation yet. 

Hi everyone,

We have taken all of your input into account in our discussions about the implementation of this idea. We have come to the following conclusion on how we want to implement this:

1. We want to limit the scope to only copying a column translation to the task/report parameter translation. We believe this already covers the vast majority of the request. In our experience, a column will almost always be present before a report/task parameter. Setting up or expanding the data model is typically the first step in development. And if you want to map a task/report parameter to a column, that column must already exist anyway.
   This prevents the need for multiple tasks, or a single task with additional options, some of which would rarely be used in practice. This keeps the screen more clean.

2. We intend to automatically copy this column translation (so not the tooltip/helptext) immediately after creating or renaming the task/report parameter. There are several arguments in favor of this:

   • In our experience, the name of a task/report parameter is often the same as that of the column. This saves the developer a manual translate action in all such cases by translating it right away. In those cases where the copied translation is not desirable, it can still be adjusted in the built-in review mechanism, as the translation will remain in the "Not yet approved" status. This aligns with the argument previously made by ​@PeterKeeris.

   • It reduces the risk of the translation being forgotten, which would lead to a validation message for the developer—or worse, the end user seeing a technical translation.

We feel confident that this solution offers a good balance: it addresses the need described in the idea, keeps the period during which a task/report parameter remains untranslated as short as possible, and still keeps the user interface clean.

​@Jeroen van den Belt Does this mean that there will be a manual task to achieve this?

The column to task/report parameter will already help a lot, but might I still request that you also consider column to column? We do have quite a number of columns with different names, but would receive the same translation. Ex. “active”, “is_active”, “active_yn”, “is_active_ny”.

Hi ​@Mark_Plaggenborg,

Within the implementation of this idea there will not be a task, and column > column translations will not be in scope.  May I suggest you create a separate idea for this?

That way, we can better map out to what extent there is demand for this from others, and maintain better focus on both topics. Feel free to mention the idea you created in a comment here, so it becomes easier to find for others who might be interested in this as well.

​@Jeroen van den Belt Thanks for the response.

The idea has been created here: