Thank you for the update. The view in question takes at least 3 seconds to gather the information required to translate the look-ups. This is unfortunate, there are no quick solutions with the current look-up translation strategy.
Currently, accessing the base table is mandatory for look-up translation. It is important that the look-ups are correlated with the base table for two reasons:
1. Column-level authorization on the base- and look-up table
The user may not have rights on the columns required to filter the data in the look-up table, either in the base table or the look-up table.
This is a security measure but it is something that could be changed: If you have access to look-up column x, we could automatically assign rights on all look-up filters for column x in both the source and target table. This would provide the UI with all information required to directly access the look-up table of look-up column x to gather translations, fill comboboxes and such.
2. Row-level authorization on the look-up table
The user may not have rights to the records containing the look-up translations. For instance, due to locked prefilters.
When using the look-up translation navigation path (/transl_x), Indicium will not apply row-level authorization on the look-up table. This allows you to obtain translations present in records that you would not be able to access directly via the api on the look-up table. Row-level authorization is applied on the main table to prevent access to arbitrary look-up translations.
There is no good way to work around this. If the UI wants to access the translations directly on the look-up table, there is no row-level authorization on the base table to keep things in check. We would have to choose between either presenting the user with untranslated look-ups when the translation is unavailable due to row-level authorization, or we would allow any arbitrary look-up translations to be obtainable, even when the translation is not in any way related to an accessible base table record.
So what now?
We are currently looking into a strategy where all look-ups are translated with the same request as the base data. This would allow look-up translations to piggy-back on the already executing base data selection while the main table data is still being processed in a safe environment. The correlation with the main table would remain intact.
This means all look-ups are translated in a single http request, together with the main table data.
This will greatly reduce the total duration for all look-up translations when the base table is slow, such as with your view. The drawback is that a single slow look-up may slow down the entire request, whereas separate requests would result in a more responsive UI.