Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i18n of validations #272

Open
conorriches opened this issue Apr 24, 2024 · 0 comments
Open

i18n of validations #272

conorriches opened this issue Apr 24, 2024 · 0 comments

Comments

@conorriches
Copy link
Member

conorriches commented Apr 24, 2024

Summary

When a frontend application makes a request to the api, we get back error messates/responses in English.
As we seek to translate our sites, we need an approach for i18n and whether the API should contain translations or whether they should live in client applications.

Context

#270 (comment)

Options

Some options:

  1. Translations stay in the client applications
  • We pass back a key which the client application will use to select the right validation error message
  • e.g. cannot_be_blank
  • This keeps translations in one place, and means each application can have its own message e.g. if one application is tailored for children and another isn't.
  1. the API returns error messages translated based on the locale passed in
  • We pass the locale in with out POST requests, and the API returns invalid field messages translated
  • This means we get back translated error messages fairly easily, but the messages will be the same across all clients
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant