Internationalization and Localization (UXPROD-779)

[UXPROD-3148] Translated library-defined controlled vocabularies Created: 29/Jun/21  Updated: 08/Nov/21

Status: Open
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Internationalization and Localization

Type: New Feature Priority: P3
Reporter: Peter Murray Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: i18n, post-v1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File screenshot-1.png    
Issue links:
Cloners
clones UXPROD-515 Translated library-generated controll... Open
Defines
is defined by UX-400 UX Review of KWare's User-Level Local... In Progress
Relates
relates to FOLIO-2802 Recruit translators for library-defin... Open
relates to FOLIO-3258 Add ui-translations/mod-translations ... Closed
relates to UXPROD-3181 Local Translation of FOLIO apps stati... Open
relates to CHAL-196 Ability to customize (for tenant) ite... Closed
relates to UIIN-2216 Ability to customize (for tenant) ite... Closed
Epic Link: Internationalization and Localization
Front End Estimate: Large < 10 days
Front End Estimator: Jakub Skoczen
Back End Estimate: XL < 15 days
Back End Estimator: Jakub Skoczen
Development Team: None
Rank: Chalmers (Impl Aut 2019): R4
Rank: Chicago (MVP Sum 2020): R5
Rank: Cornell (Full Sum 2021): R5
Rank: Duke (Full Sum 2021): R5
Rank: 5Colleges (Full Jul 2021): R5
Rank: FLO (MVP Sum 2020): R5
Rank: GBV (MVP Sum 2020): R2
Rank: hbz (TBD): R2
Rank: Hungary (MVP End 2020): R2
Rank: Lehigh (MVP Summer 2020): R5
Rank: Leipzig (Full TBD): R2
Rank: Leipzig (ERM Aut 2019): R4
Rank: Mainz (Full TBD): R2
Rank: TAMU (MVP Jan 2021): R5
Rank: U of AL (MVP Oct 2020): R4

 Description   

Current situation or problem: Each FOLIO installation has lists of controlled vocabulary terms (for instance, “Formats” and “Resource types” in Inventory, “Patron Groups” and “Refund Reasons” in Users — see FOLIO-2802 Open for a more complete list).  In installations that use more than one language, these terms do not display translated values when the locale of the session is changed.

In scope

  • A mechanism for storing translated strings for controlled vocabulary terms.
  • A mechanism for displaying the translated strings in apps that use the controlled vocabulary tables.
  • A mechanism for translating controlled vocabulary terms in the Settings app.

Out of scope

Use case(s)

As a FOLIO Stripes app user, I want to see strings in my native locale so I can understand the user interface.

As a systems librarian, I want to enter controlled vocabulary in two or more locales so that my users can understand the user interface; some countries, regions or institutions are bilingual or multilingual.

Proposed solution/stories

KnowledgeWare has developed this capability as proposed in UX-400 In Progress .  

  • You can access this in Kware's FOLIO test environment here: http://folio-testing.kwaretech.com/ 
  • Username: kware_test      Password: kware_test                                    Preferred Locale: English

Links to additional info

Questions



 Comments   
Comment by Peter Murray [ 30/Jul/21 ]

https://folio-org.atlassian.net/browse/FOLIO-3258 added Jira to ask the DevOps team to add the `ui-translations`/`mod-translations` apps to the reference builds when they become available.

Massoud: please have your team make the pull requests against the appropriate Stripes repositories and put "UXPROD-3148" in the description of the pull request. I will create the needed Jira issues for the Stripes repositories.

Khalilah Gambrell and Zak Burke: This is a bit unusual in that adding an app will require changes to Stripes, so I'm not entirely clear on what path it should follow. I'm guessing the Stripes-Force team will want to review the changes to the Stripes repositories, but I don't think this change has to go in front of Technical Council. Thoughts?

Related, UXPROD-3149 Open is also a change to Stripes, but is (I think) much less dramatic. It brings the ability for users to change their session locale to the Stripes menu bar. It, too, will be pull requests to the Stripes repositories (but not an added App as I understand it).

Comment by Peter Murray [ 04/Aug/21 ]

attia.alshareef and Massoud Alshareef: One thing to keep in mind as you prepare the Pull Request to Stripes: pull requests to core code must meet a "definition of done". The rationale and discussion of the Definition of Done are in this Google Doc from 2018. Each team creates its own definition that is specific to the needs of the software it is developing (see this page for a link to many of the team's documents). In the case of UXPROD-3148 Open and UXPROD-3149 Open , it probably makes the most sense to look at Stripes-Force's Definition of Done as a model since that team focuses on changes to Stripes.

In particular, there are automated tests that will need to be written and the existing tests will need to pass with the pull request changes. The state of testing is described in the Module Testing Guidelines, and Anton Emelianov is the person who can help with questions on testing. I wanted you to have that need in mind, though, as we plan the timeline between now and when changes to Stripes are due on August 27th for the Kiwi release.

About the "Peer code review is performed" requirement...the Stripes Force team meets on Mondays at (I think) 10:00am Eastern U.S. time. Khalilah invited me to that to talk through these new features from a Product Owner perspective. If you want to join me, I can forward the meeting invitation...and if not I'll report back to you later on Monday. The Stripes Force team will look at the GitHub pull requests to ensure they are in good order with an eye towards long-term maintainability.

One of the other FOLIO development rituals is to present new work during the Sprint Reviews that happen every four weeks. The next sprint review is August 31st at 11am Eastern U.S. time. I understand that is likely an inconvenient time, so if you wanted to pre-record something, I could play it back during the sprint review and answer any questions. See the recording of yesterday's sprint review to see how these presentations typically go.

Comment by Massoud Alshareef [ 07/Aug/21 ]

Thank you Peter Murray for guiding us on how to be in sync with best practices of FOLIO development. Your suggested roadmap toward participating in FOLIO dev community seems very clear, and it will help us sharpening our dev team skills to produce robust and reliable software.
 
Attia will make sure that these guidelines will be followed as required.
 
I will be happy tp participate in the  Next Spring Review on Aug 31, assuming that I will receive a Zoom invitation.
 

Comment by attia.alshareef [ 20/Aug/21 ]

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.

Comment by Peter Murray [ 20/Aug/21 ]

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.

Comment by Marc Johnson [ 20/Aug/21 ]

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?

Comment by attia.alshareef [ 21/Aug/21 ]

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.

Comment by Marc Johnson [ 23/Aug/21 ]

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?

Generated at Fri Feb 09 00:29:43 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.