Translations in the backend

[BacLuc]

Design Translations Backend

For what we need translations in the backend

• Email bodies
• Email Titles
• Validation and other error messages

Current Situation

• Email Bodies: implemented, but self made, not symfony translations
• Email Titles: not translated
• Validation and other messages: not translated

Variants

1. Translate Messages in Frontend with the code Property

common/locales/de.json:

 "api" : {
    "bef8e338-6ae5-4caf-b8e2-50e7b0579e69": "Diese Liste muss mindestens 1 element haben"
  } 

Positive:

• Uses existing mechanism
• correct language is known in the frontend
• only one set of translation files is used (the one from the frontend)
• Because the translation key is a uuid, it will most likely not be changed for a existing message, and most likely not collide
• Text can be adapted in the frontend according to the context

Negative:

• The api is not human friendly readable
• Parameters are not known (the 1)
• we need to translate the existing Constraints. (But that may be scripted)

2. Translate the messages in the backend

Positive:

• No logic in the frontend, it can grab the message as is
• We can use the existing translations for the existing constraints

Negative:

• The backend my not yet know the language it has to translate to (register form, accept invitation, login)
• we need additional translation files in the backend

3. Translate Messages in Frontend with speaking translation key and separated parameters

Because when we have to extend the behaviour, i would use speaking translation keys.

{
  "type" : "https://tools.ietf.org/html/rfc2616#section-10",
  "title" : "An error occurred",
  "detail" : "periods: This collection should contain 1 element or more.",
  "violations" : [
    {
      "propertyPath": "periods",
      "message": "This collection should contain 1 element or more.",
      "code": "bef8e338-6ae5-4caf-b8e2-50e7b0579e69",
      "i18nkey": "api.validation.collection.min-elements",
      "parameters": {
        "min": "1"
      }
    } 
  ]
}

Positive:

• correct language is known in the frontend
• we can use the existing frontend translation logic
• only one set of translation files is used (the one from the frontend)
• Text can be adapted in the frontend according to the context

Negative:

• not seen yet this way
• we need to add translation keys to the existing constraints
• we need to get the parameters
• changing the translation key is a breaking change
• because we make mistakes, it's possible that the key for an existing validation may change
• we need to translate the existing Constraints. (But that may be scripted)

4. Provide the frontend with the translations it needs without the translation key indirection

From https://medium.com/@_Ma27_/share-backend-translations-with-the-frontend-22daf8a4d6e

{
  "type" : "https://tools.ietf.org/html/rfc2616#section-10",
  "title" : "An error occurred",
  "detail" : "periods: This collection should contain 1 element or more.",
  "violations" : [
    {
      "propertyPath": "periods",
      "message": "This collection should contain 1 element or more.",
      "code": "bef8e338-6ae5-4caf-b8e2-50e7b0579e69",
      "i18n": {
          "en": {
            "This collection should contain 1 element or more."
          },
          "de": {
            "Diese Liste muss mindestens 1 element haben."
          }
      }
    } 
  ]
}

Positive:

• correct language is known in the frontend
• frontend and backend are not tied together. (e.g. the form of the translation key may be library dependent)

Negative:

• only seen once this way
• we need additional translation files in the backend
• needs some logic in the frontend to grab the correct message

What to do with the other cases

If we use translation files in the backend, we change the Email Translation logic to use symfony translations (for Title and Body of the email)
else we also use the existing self made mechanism for the email body for the email title too

[manuelmeister]

Core Meeting Decision

• @BacLuc versucht Variante 3 kombiniert mit N° 4