Add internationalisation support

[wgresshoff]

❤️ Thank you for your contribution!

Description

Add internationalisation support. By adding a lang column and extendig the unique constraint the goal is achieved. This feature is available in the Administration interface as well.

Checklist

Ticks in all boxes and 🟢 on all GitHub actions status checks are required to merge:

• I'm aware of the code of conduct.
• I've created logical separate commits and followed the commit message format.
• I've added relevant test cases.
• I've added relevant documentation.
• I've marked translation strings.
• I've identified the copyright holder(s) and updated copyright headers for touched files (>15 lines contributions).
• I've NOT included third-party code (copy/pasted source code or new dependencies).
  • If you have added third-party code (copy/pasted or new dependencies), please reach out to an architect.

Frontend

• I've followed the CSS/JS and React guidelines.
• I've followed the web accessibility guidelines.
• I've followed the user interface guidelines.

Reminder

By using GitHub, you have already agreed to the GitHub’s Terms of Service including that:

1. You license your contribution under the same terms as the current repository’s license.
2. You agree that you have the right to license your contribution under the current repository’s license.

[wgresshoff]

Needs inveniosoftware/invenio-app-rdm#2967

[slint]

LGTM, some minor decisions and concern about use of server_default vs. default for the field definition

[slint]

minor/question: (probably I18N/L10N experts can jump in) is this the best format to store the language? E.g. could en-US or similar be better and map to the overall translations process? This would affect the string size, i.e. 2 vs. 5 (or even higher?)

[wgresshoff]

I'm not an expert but this is the information the UI provides?! This follows the settings in I18N_LANGUAGES.

[slint]

minor: I feel this is because you specify server_default in the Alembic recipe but not in the SQLAlchemy model definition. I think there are two options:

• Use server_default in the SQLAlchemy model column definition. We don't do this in general and I'm still unsure what's the best practice:
  • Definitely more "efficient" since the DB does the work for us, and I know that PostgreSQL is smart about it when adding the new column.
  • Less flexible, since default=... allows functions that can compute the value based on application config or other runtime conditions
• Instead of using server_default in the alembic recipe column definition, you can create the column in multiple steps and populate the default value:
  1. Create the column with nullable=True
  2. Run an UPDATE ... command to set the lang="en" (see also this more complex recipe, doing updates)
  3. Add the nullable=False constraint to the field

[wgresshoff]

Replaced server_default by default: no changes in the test results.

[slint]

In that case we have to see what the output of ext.alembic.compare_metadata() is, I think it contains some more specific information... We've disabled in other places Alembic tests, because of some other irrelevant issues, so if this is the case, we can do this here as well.

[wgresshoff]

Seems the output is how to rollback the modifications:

[('remove_constraint', UniqueConstraint(Column('url', NullType(), table=<pages_page>), Column('lang', NullType(), table=<pages_page>))), ('add_constraint', UniqueConstraint(Column('url', NullType(), table=<pages_page>))), [('modify_nullable', None, 'pages_page_version', 'lang', {'existing_type': CHAR(length=2), 'existing_server_default': False, 'existing_comment': None}, False, True)]]