Translated library-defined controlled vocabularies

@attia.alshareef

The required changes are not entirely dependent on the presence of (ui-translations - mod-translations). from this line, you can see that the default message for each translation key is the same as the string fetched from the backend

I understand that there is a fallback to the data from the owning module.

Ok, I'll rephrase (I'm aware that folks use the term dependency differently): In order to provide translations of property from controlled vocabularies an implementation of the translations interface must be provided, without it, the behaviour is the same as prior to any of these proposed changes

Is that a more reasonable statement?

from this line, you can see the validation about whether mod-translations exists or not.

That line seems to be a HTTP request to GET /translations. How does that validate whether the interface that endpoint is part of is provided or not?

Therefore, I see the necessity of having these units complete the workflow and achieve the desired goal.

Does that mean that you think that both mod-translations and ui-translations need to be part of the official FOLIO distribution before the changes above are made to stripes-core, stripes-smart-components and ui-inventory?

@Peter Murray: 

In the long term, that is probably a more stable way of identifying and translating each string...even if it means that the developers of the UI modules will need to retrofit this into their code. We will need to set up documentation for that.

 I'm already working on preparing a document that explains what is expected of everyone involved (backend - frontend - translators) to benefit from dynamic translation.

Can you verify: if a UI module doesn't have the necessary changes, the only impact is that the dynamic strings can't be translated by the Translations app...otherwise the app would function as it does now? (With no errors?)

Exactly, all applications that do not make the required changes will work without errors but will not benefit from the dynamic translation.

@Marc Johnson:

Do these changes rely on the presence of the Translations App and / or the new modules (mod-translations, ui-translations)?

The required changes are not entirely dependent on the presence of (ui-translations - mod-translations). from this line, you can see that the default message for each translation key is the same as the string fetched from the backend, and from this line, you can see the validation about whether mod-translations exists or not.

But making these changes without the presence of (ui-translations - mod-translations) we will not have a dynamic translation process, not to mention the loss of many features that have been delayed for upcoming versions such as exporting and importing translations, fetching translation from Google ... etc.
Therefore, I see the necessity of having these units complete the workflow and achieve the desired goal.

@Peter Murray @attia.alshareef

In the long term, that is probably a more stable way of identifying and translating each string...even if it means that the developers of the UI modules will need to retrofit this into their code. We will need to set up documentation for that. Can you verify: if a UI module doesn't have the necessary changes, the only impact is that the dynamic strings can't be translated by the Translations app...otherwise the app would function as it does now? (With no errors?)

The statement about these changes being needed to allow translation by the Translations App suggests that they are dependent upon the Translations App. Is that the case?

Do these changes rely on the presence of the Translations App and / or the new modules (mod-translations, ui-translations)?

This line suggests that we are expecting stripes-core to make requests to mod-translations. Have I interpreted this correctly?

Thank you, @attia.alshareef. I see what you mean now about needing to change the declaration of strings in each app:

In the long term, that is probably a more stable way of identifying and translating each string...even if it means that the developers of the UI modules will need to retrofit this into their code. We will need to set up documentation for that. Can you verify: if a UI module doesn't have the necessary changes, the only impact is that the dynamic strings can't be translated by the Translations app...otherwise the app would function as it does now? (With no errors?)

@Zak Burke: I've marked the three pull requests for review. Could you take a look at them, please?

We are getting very close to the cutoff for changes to Stripes for the Kiwi release (due by the end of the week next week) and may need to put this off until the Lotus release, but let's see what happens.

@Peter Murray, There are 3 PRs added:
1- stripes-smart-components: Adding logic for translating the library-defined controlled vocabularies:

(https://github.com/folio-org/stripes-smart-components/pull/1114)

2- stripes-core: Adding logic for loading the translations of library-defined controlled vocabularies:
(https://github.com/folio-org/stripes-core/pull/1107) 

3- ui-inventory: POC for enabling translations of library-defined controlled vocabularies on stripes apps:
(https://github.com/folio-org/ui-inventory/pull/1440)

> I will update the ui-translations docs to explain the complete workflow, thinking, and decisions about the translation work.

>> Sorry for the delay, but time was really not enough for us.