Internationalization and Localization (UXPROD-779)

[UXPROD-372] Enable translation of system menu options Created: 05/Mar/18  Updated: 16/Sep/20  Resolved: 13/May/19

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

Type: New Feature Priority: P3
Reporter: Cate Boerema (Inactive) Assignee: Unassigned
Resolution: Done Votes: 0
Labels: i18n
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Cloners
clones UXPROD-371 Enable translation of validation and ... Open
Relates
relates to UITEN-30 Translate "Yes" and "No" Closed
Epic Link: Internationalization and Localization
Back End Estimate: XL < 15 days
Back End Estimator: Jakub Skoczen
Rank: Chalmers (Impl Aut 2019): R4
Rank: Chicago (MVP Sum 2020): R4
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): R1
Rank: Lehigh (MVP Summer 2020): R5
Rank: Leipzig (Full TBD): R2
Rank: Leipzig (ERM Aut 2019): R4
Rank: TAMU (MVP Jan 2021): R5
Rank: U of AL (MVP Oct 2020): R5

 Description   

Translation of FOLIO system menu options such as status values (active, inactive)

Out of scope for this feature: translation of user-created controlled vocabularies. These kinds of translations, which will need to be added by individual institutions, are only necessary when we have the ability to support >1 language per tenant (see UXPROD-510 Open and UXPROD-515 Open ).



 Comments   
Comment by Cate Boerema (Inactive) [ 03/Sep/18 ]

Removed Q3 2018 release as that applied a long time ago and this feature is definitely not in scope for Q3.

Comment by Cate Boerema (Inactive) [ 10/May/19 ]

Hi Charlotte Whitt, I just removed an example you had added to the description of this feature, as I think it is really a different issue. This feature was intended to cover support for translation of system menu values for example, on the Service point record, "Pickup location" Yes/No and "Hold shelf expiration period" units Minutes/Hours/Days/Weeks/Months

I think your example might be closer to what is described in UXPROD-515 Open

Anyway, here is the example I removed:

Example:
In Inventory we use the RDA lists - Resource type = RDA content. The English version is loaded into the system: https://www.loc.gov/standards/valuelist/rdacontent.html

The German National Library has translated the terms in this value list of RDA content, but the codes are coherent with the English version. The German language list is the official standard used by German libraries: https://wiki.dnb.de/download/attachments/106042227/AH-013.pdf.

Comment by Cate Boerema (Inactive) [ 10/May/19 ]

Jakub Skoczen and Marc Johnson, As I recall, this issue was created long ago when we thought that making system menu values translatable would be more difficult than just doing the UI labels. I just checked with Peter Murray, though, and it seems like we do have support for menu value translations. For example, in the service point record, the Hold shelf expiry period unit (minutes, hours, days, weeks, months) has been translated into Chinese. We did see that the Pickup location (yes, no) was hardcoded but that seems more like an isolated bug than a big missing feature.

Given all that, is it safe to close this feature as done?

Please note, the ability to translate library-defined controlled vocabularies is out of scope for this feature and is covered in UXPROD-515 Open

Comment by Peter Murray [ 10/May/19 ]

The Pickup Location Yes/No is UITEN-30 Closed .

Comment by Jakub Skoczen [ 13/May/19 ]

Cate Boerema Sounds good to me. It should be possible to translate any fixed "vocabulary" this way so if UXPROD-515 Open covers all other cases I think we are fine.

Comment by Marc Johnson [ 13/May/19 ]

Cate Boerema

As I recall, this issue was created long ago when we thought that making system menu values translatable would be more difficult than just doing the UI labels.

I think it depends how deep the translation needs to go.

If there is a mechanism for mapping the translation to the expected value for the API then that might be sufficient.

In the API those kinds of values are all English words, and those are hard to change. We haven't made some of these kinds of options into reference records / controlled vocabularies. In part because the system needs to know to relate behaviour to them.

Does that make sense?

Comment by Cate Boerema (Inactive) [ 13/May/19 ]

Thanks Jakub Skoczen and Marc Johnson. I think I understand that we are able to translate system menu values but the APIs are still in English. I haven't (yet) heard a requirement that the API should be localized. I think I will close this one as done and create a new one when/if that requirement arises.

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