| 10 min | System and Tenant Level Users | | - 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.
|
| 50 min | l10n of back-end error messages | | 5 min- present Julian Ladisch's institution has allotted him some time for UXPROD-371 before the TC (goal: ask for the conclusions reached in STRIPES-750 to be accepted or rejected; Zak Burke )
- present CIRC-1146 (see description, section "Additional information") with the initial proposal for handling l10n on the backend (goal: ask for endorsement of the proposal; Julian Ladisch )
- present FOLIO-3196 (goal: initial TC discussion)
|
| 25 min | System and Tenant Level Users | | - 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.
|
- (i18n of error messages received from APIs); even though it is not highly ranked overall it is crucial to a select audience. 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.
- 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.
- Resolved: there was solid consensus that backend modules should handle l10n of responses given a locale indictor in a request (the HTTP request's Accept-Languages header was mentioned many times though no commitment was made).
|
| 5 min | next week: system/tenant-level user progress | VBar | - check in with TC WRT whether we have resources for the system/tenant level users champion
|
| 10 min | next week: conclusions of the l10n conversation | | - present conclusions of today's meeting, namely: backend should handle localization given a locale indicator in a request. it's tradeoffs all the way down; this was seen as the lowest-effort option.
- Question: can new implementations of existing interfaces reuse translations somehow?
|
| Info item: Inter-App Bibliographic Data Flow Task Force Charge |
| - application inter-operability/data integrity task force is coming soon!
- Draft charge coming out of Exec PC to be presented to PC tomorrow:
|