Hello,
I have a column in a table with a translation object created for this column.
If I open the table in Windows it displays the correct name for the column. If I open the same screen in a mobile app it doesn't show the correct name but shows the original field name. All the other fields are translated well. I don't use a tab variant for this table. Is there an option to add the translation object for the mobile app as well?
Page 1 / 1
Hi Rémon, if I'm not mistaken, the translations on mobile are case sensitive.
Is it possible that's the problem?
Is it possible that's the problem?
No that's not the problem, it just shows the value as if there's no translation object.
it shows [fieldname]:
it shows [fieldname]:
In addition to Jop's answer: you can use the Correct foreign key casings tasks on a project version to correct any casing issues in the model.
Thanks Jasper and Jop!! Spent about an hour yesterday trying to solve this.
And what if the column isn't a foreign key? Does this task also work?
And shouldn't this be a validation?
This task is one of the more arcane parts of the Software Factory. It doesn't have anything to do with foreign keys columns.
The task is used to correct foreign keys between objects in the model itself. Perhaps we should have called it Harmonize model casing or something.
For instance, if you have a table named 'Customer' and it is changed to 'customer', various model entities might still refer to it as 'Customer'. For example, a list bar item could be referring to the table using the ID 'Customer'. Or a translation object could still use 'Customer' as key instead of 'customer'.
Generally, this is not a problem because SQL Server has a case-insensitive collation by default and the Windows and Web GUI's approach the loaded model case-insensitive as well.
The Mobile GUI and (to a lesser extent) Universal have more trouble with this as they use JavaScript under the hood which is case-sensitive by default.
This is the reason a translation might not be able to load, because the Mobile GUI is looking for a translation for 'customer' where the translation object uses the key 'Customer'.
If you were to synchronize the model to an IAM database with a case-sensitive collation or if you were to change the Software Factory database collation to be case-sensitive, you'd run into problems as well. So don't do this!
When you run the task, all foreign keys of a model object will be updated to the casing of the primary key. This is quite a heavy process as it will have to scan and cast all model object IDs to a case-sensitive collation. This is also the reason we do not have a validation for this, it would take a lot of time to run this validation.
The task can repair almost all incorrectly cased foreign keys. One exception is the translation objects. One translation object can represent multiple model objects. For instance, when you have a column 'customer_id' and a column 'Customer_id' it cannot repair this situation. At that point, the task will inform the developer of this discrepancy. You'll have to harmonize your column ID casing and retry.
I hope this explains things a bit.
The task is used to correct foreign keys between objects in the model itself. Perhaps we should have called it Harmonize model casing or something.
For instance, if you have a table named 'Customer' and it is changed to 'customer', various model entities might still refer to it as 'Customer'. For example, a list bar item could be referring to the table using the ID 'Customer'. Or a translation object could still use 'Customer' as key instead of 'customer'.
Generally, this is not a problem because SQL Server has a case-insensitive collation by default and the Windows and Web GUI's approach the loaded model case-insensitive as well.
The Mobile GUI and (to a lesser extent) Universal have more trouble with this as they use JavaScript under the hood which is case-sensitive by default.
This is the reason a translation might not be able to load, because the Mobile GUI is looking for a translation for 'customer' where the translation object uses the key 'Customer'.
If you were to synchronize the model to an IAM database with a case-sensitive collation or if you were to change the Software Factory database collation to be case-sensitive, you'd run into problems as well. So don't do this!
When you run the task, all foreign keys of a model object will be updated to the casing of the primary key. This is quite a heavy process as it will have to scan and cast all model object IDs to a case-sensitive collation. This is also the reason we do not have a validation for this, it would take a lot of time to run this validation.
The task can repair almost all incorrectly cased foreign keys. One exception is the translation objects. One translation object can represent multiple model objects. For instance, when you have a column 'customer_id' and a column 'Customer_id' it cannot repair this situation. At that point, the task will inform the developer of this discrepancy. You'll have to harmonize your column ID casing and retry.
I hope this explains things a bit.
Thanks for the detailed explanation Anne! I think it would be good to rename the task, because I never knew this was available in the SF, and wouldn't have guessed is does what it does based on the name.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.