Internationalization and Localization
(UXPROD-779)
|
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Internationalization and Localization |
| Type: | Tech Debt | Priority: | P2 |
| Reporter: | Julian Ladisch | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | i18n, translation | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||
| Sprint: | |||||||||||||||||
| Development Team: | None | ||||||||||||||||
| Epic Link: | Internationalization and Localization | ||||||||||||||||
| Description |
|
To translate messages it returns a back-end API needs to know the locale of the client. Example message: "No item with barcode {itemBarcode}exists", for details see https://folio-org.atlassian.net/wiki/display/I18N/How+To+translate+FOLIO Example locale: de Two ways to pass the current locale to a back-end API have been proposed: accept-language HTTP header lineThis is a standard HTTP header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language The FOLIO front-end doesn't use it in favor of a configuration setting for the reasons explained in https://www.w3.org/International/questions/qa-when-lang-neg.en The back-end modules can be extended to use the accept-language HTTP header line to determine the language they need to translate into. lang query parameterFOLIO defines the lang query parameter in the language RAML trait: https://github.com/folio-org/raml/blob/raml1.0/traits/language.raml lang:
description: |
Requested language. Optional. [lang=en]
type: string
required: false
default: en
pattern: "[a-zA-Z]{2}"
It is declared in all RAML resource types: https://github.com/folio-org/raml/tree/raml1.0/rtypes Therefore most back-end APIs already have the (unused) lang parameter in their implementation, for example https://github.com/folio-org/mod-circulation-storage/blob/master/src/main/java/org/folio/rest/impl/ScheduledNoticesAPI.java The trait pattern must be extended to allow for RFC5646=BCP47 language tags that are longer than two letters, FOLIO already have front-end translations with longer tags, for example es_419, es_ES, zh_CN, zh_TW. The pattern change is a non-breaking change. Decision log entryhttps://folio-org.atlassian.net/wiki/display/DD/Localization+parameter+for+back-end |
| Comments |
| Comment by Zak Burke [ 25/Aug/21 ] |
|
Julian Ladisch, this ticket is cross-linked with a decision log entry and has been lingering on my to-do list for some time. Sorry! As noted in the TC's minutes from 2021-06-09, we discussed using the HTTP request's Accept-Language header as the preferred implementation but did not commit to it. My recollection was that there was broad agreement among front-end devs, Tech Council members, and back-end devs that Accept-Language was a good choice. I have updated the Decision Log entry accordingly but left the status "In Progress" until I could confirm this with you. If you agree with the decision, please change the status to "Done". If you disagree with the decision please let me know ASAP. If you agree but think we need to provide additional information, let's plan a meeting but also consider changing the status to "Done" to indicate that the major decision has been made. Thanks! |