2021-06-09 Meeting Notes

Craig McNally

• System and tenant level users are becoming an increasingly urgent problem. There was a recent discussion at Tech Leads. See also the spike FOLIO-2551 and Decision Log entry.
• this appeared on an architecture blueprint but never got a champion to move it forward, but is increasingly an issue for teams needing role-users, or users to handle async processing, but we're heading for a hot mess if we don't choose a platform-level solution. 
• goal: find a champion to formulate a proposal and move forward with a specific design
• VBar to check with solution architects to see if there is capacity and interest; or conscript members from TC, or ask PC for resources to create a spike and assign it to a team.

Zak Burke, Julian Ladisch

• Julian Ladisch's institution has allotted him some time for UXPROD-371 (i18n of error messages received from APIs); even though it is not highly ranked overall it is crucial to a select audience (all non-English-language organisations). The translators are blocked because the back-end strings are not on FOLIO's translation platform https://lokalise.com/. His initial foray led to STRIPES-750, which some front-end devs discussed, concluding that backend modules should be responsible for providing localized text in their responses given an Accept-Languages header in the requests they receive. 

• where is this info being consumed, e.g. data in logs? Conclusion: we are talking about data in responses only (for which a tenant's/HTTP request's locale may be assessed): The consumer of a log (i.e. the hosting provider) may prefer a different locale than the consumer of the response; hence, the log locale should not  be configured based on the request's locale.
• From FE perspective, Stripes is not the only possible consumer of messages, i18n of messages should not be replicated across all possible consumers (see comments in CIRC-1146)
• Do we need a solutions architect and champion here too? 
• If we do translation on the backend, then clients cannot vary the content of the message unless the error schema is used and populated (code = translation key, parameters = variables to fill in) as shown in CIRC-1146.
• Markup may be an issue here, i.e. cannot (should not?) provide markup in messages returned from the backend. Given the backend doesn't know about its consumer, folks agreed responses should not contain markup of any sort. While this can be portrayed as a weakness of server-side l10n, it was noted that this is no different than the present situation WRT display of API response values.
• One effect of all translations on the BE: long translations cannot be modified by the client, Stripes might want to display a message as a bulleted list, command-line client might want to be a single string, shorter. This applies to the English string as well.
• Resolved: there was solid consensus that backend modules should handle l10n of responses given a locale indicator in a request (the HTTP request's Accept-Languages header was mentioned many times though no commitment was made as FOLIO-3196 was no discussed). 

• check in with TC WRT whether we have resources for the system/tenant level users champion

Zak Burke, Julian Ladisch