In a perfect world you name every column correctly in the first try. However, more often than not software needs to be revised and columns need to be renamed. The only options I now know of to rename a column is to create an expression column or rename the actual column on the data model to create a new translation subject. Both have some disadvantages and feel very redundant for just a simple column rename action.
What would help is the option to create an alternative translation object for a specific object (for example a column). Or choose a different existing translation object.
Page 1 / 1
Hi Erwin,
Can you provide some examples where columns with the same ID should have different translations?
Can you provide some examples where columns with the same ID should have different translations?
Two Real life Examples:
example 1:
On an inventory transactions screen you can change the current stock level. The transaction unit of measurement is not necessarily the same as the stock keeping unit of measurement (example the stock keeping unit is gram but the transaction unit is kilogram). To store the information for this there are 2 columns, transaction quantity and inventory quantity.
The problem with the naming is that inventory quantity suggest this column is giving you information about the total amount of inventory. In reality it is the transaction quantity corrected against the stock keeping unit of measurement.
During development the name inventory_quantity probably made sense, however now it does not. And then you are left with the only feasible option: to make a new expression column just to rename this one column. Renaming the column and changing every trigger, stored procedure, view, task, parameter etc. is not a feasible option.
example 2:
on a pick list screen there are a number of lines with items to pick. For each line there is a column quantity_needed. This is the amount needed to pick for this particular line (or article/item). However, it is also possible to process the picking list in parts(not every item has been picked entirely example: you need 100 items but only 50 have been picked so far). Doing this means the quantity needed (50) will be lower then the original quantity needed (100).
So when only processing pick lists that are completely done the name quantity needed makes sense. But with the option to process a pick list partially the name is a bit ambiguous. The name suggests it is the original amount, but in actually it is the amount still needed (original amount - already shipped amount).
Also in this case, when only processing complete pick lists the name quantity needed makes sense, but with the added option of processing lists partially the name is no longer correct. As with example 1 renaming the column would mean changing every trigger, stored procedure, view, task, parameter etc. so for this another expression column needs to be created.
example 1:
On an inventory transactions screen you can change the current stock level. The transaction unit of measurement is not necessarily the same as the stock keeping unit of measurement (example the stock keeping unit is gram but the transaction unit is kilogram). To store the information for this there are 2 columns, transaction quantity and inventory quantity.
The problem with the naming is that inventory quantity suggest this column is giving you information about the total amount of inventory. In reality it is the transaction quantity corrected against the stock keeping unit of measurement.
During development the name inventory_quantity probably made sense, however now it does not. And then you are left with the only feasible option: to make a new expression column just to rename this one column. Renaming the column and changing every trigger, stored procedure, view, task, parameter etc. is not a feasible option.
example 2:
on a pick list screen there are a number of lines with items to pick. For each line there is a column quantity_needed. This is the amount needed to pick for this particular line (or article/item). However, it is also possible to process the picking list in parts(not every item has been picked entirely example: you need 100 items but only 50 have been picked so far). Doing this means the quantity needed (50) will be lower then the original quantity needed (100).
So when only processing pick lists that are completely done the name quantity needed makes sense. But with the option to process a pick list partially the name is a bit ambiguous. The name suggests it is the original amount, but in actually it is the amount still needed (original amount - already shipped amount).
Also in this case, when only processing complete pick lists the name quantity needed makes sense, but with the added option of processing lists partially the name is no longer correct. As with example 1 renaming the column would mean changing every trigger, stored procedure, view, task, parameter etc. so for this another expression column needs to be created.
Just wanted to post this idea as well. For columns for example, you could have a checkbox: use_alt_translation. This would create an entry in the translations, something like tablename.columname, that you can translate differently for a specific table.
I see that this is on the backlog.
I would like to ask how far the plans are for this feature?
I see that this is on the backlog.
I would like to ask how far the plans are for this feature?
Hi Mark,
The 2023.2 is about to be finished up and is set to be released in June. This idea has not been discussed further at this exact moment, but considering the amount of votes and the diversity between voters, I’ll make sure it will be discussed when we gather ideas for the 2024.1 version of the platform.
Hi Mark,
Thanks, I would really appreciate it.
I see that this is on the backlog.
I would like to ask how far the plans are for this feature?
Hi Mark,
The 2023.2 is about to be finished up and is set to be released in June. This idea has not been discussed further at this exact moment, but considering the amount of votes and the diversity between voters, I’ll make sure it will be discussed when we gather ideas for the 2024.1 version of the platform.
Hi Mark,
We’ve once again ran into a scenario we’re this idea would really help us out. Any updates on the priority of this issue on the backlog? 
Hi
great idea! I would like to add to this idea as well.
I would suggest having a checkbox like we have on variants to translate the object separately. Because when you create a variant columns also could get different meaning. So i would like to get a checkbox on column level in a variant for example to change the translation for that column in that variant.
Other implementations could also be in task variants where a parameter would get a bit of a different meaning.
Hi
Any updates on the priority of this issue on the backlog?
Not at the moment. We do see it's a very popular idea with currently 18 unique company votes. I do also like the idea so I'll take it into account for the 2025.1 
Just wanted to post this idea as well. For columns for example, you could have a checkbox: use_alt_translation. This would create an entry in the translations, something like tablename.columname, that you can translate differently for a specific table.
This would a great solution
We are currently experiencing a issue where this idea would help a lot. Would love to see this happen in 2025.1 .
On the backlog→Working on it!
This is planned to be resolved with the Roadmap 2025 H1 efforts.
Working on it!→Next release
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.