Internationalization and Localization
(UXPROD-779)
|
|
| 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: |
|
||||||||||||||||||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||
| 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
In scope
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
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,
|
| 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
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. |
| Comment by attia.alshareef [ 20/Aug/21 ] |
|
Peter Murray, There are 3 PRs added: (https://github.com/folio-org/stripes-smart-components/pull/1114) 2- stripes-core: Adding logic for loading the translations of library-defined controlled vocabularies: 3- ui-inventory: POC for enabling translations of library-defined controlled vocabularies on stripes apps: > 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 ] |
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 ] |
I'm already working on preparing a document that explains what is expected of everyone involved (backend - frontend - translators) to benefit from dynamic translation.
Exactly, all applications that do not make the required changes will work without errors but will not benefit from the dynamic translation.
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. |
| Comment by Marc Johnson [ 23/Aug/21 ] |
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?
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?
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? |