I18n add translation support for invenio-checks

[Samk13]

❤️ Thank you for your contribution!

Description

This PR introduces backward-compatible multilingual support for rule configurations in invenio-checks. Rule titles, messages, and descriptions can now be specified in multiple languages using dictionary format while maintaining full backward compatibility with existing string-based configurations.

Changes

Core Features

• Multilingual rule fields: title, message, and description now support multilingual dictionaries
• Translation function: New translate_field() function with intelligent fallback chain
• Backward compatibility: Existing string-based configurations continue to work unchanged
• Jinja2 filter: Registered translate_field filter for dynamic language change "macro didn't work"

Translation Fallback Chain

1. Current user locale (from current_i18n.locale)
2. English ("en") as universal fallback
3. First available language in the dictionary
4. Empty string for truly empty configurations

API Changes

• New translate_field() function in invenio_checks/utils.py: Handles translation of multilingual fields with fallback
• Jinja2 filter registration: Template filter available as {{ field | translate_field }} in templates
• Error handling: Graceful fallbacks for unsupported field types with descriptive ValueError

Configuration Examples

New Multilingual Format

{
  "id": "access:open/publication",
  "title": {
    "en": "Open Access Publication",
    "sv": "Öppen tillgång publikation", 
    "de": "Open-Access-Publikation"
  },
  "message": {
    "en": "Publication articles must be Open Access",
    "sv": "Publikationsartiklar måste vara öppen tillgång",
    "de": "Publikationsartikel müssen Open Access sein"
  },
  "description": {
    "en": "This rule ensures that all publication articles are Open Access.",
    "sv": "Denna regel säkerställer att alla publikationer är öppet tillgängliga.",
    "de": "Diese Regel stellt sicher, dass alle Publikationen Open Access sind."
  },
  "level": "error"
}

Backward Compatible (still works)

{
  "id": "simple-rule",
  "title": "Simple Rule Title",
  "message": "Simple string message",
  "level": "warning"
}

Mixed Format (also supported)

{
  "id": "mixed-rule", 
  "title": "String Title",
  "message": {
    "en": "English message",
    "sv": "Swedish message"
  },
  "description": "String description"
}

Breaking Changes

None - This is backward compatible. Existing configurations work unchanged.

1. Replace string fields with language dictionaries:

   // Before
   "title": "My Rule"
   
   // After  
   "title": {
     "en": "My Rule",
     "sv": "Min regel"
   }

2. Use the filter for custom templates:

   {{ rule.title | translate_field }}

• The first check in the screenshot shows a case where the rule has no translations and still appears in English without errors.
• The last check displays a case where the rule contains a mix of English strings and translations.

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 on Discord.

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.

[utnapischtim]

in which situation is it necessary to place the imports here?

[Samk13]

The lazy imports are necessary to prevent application context errors. This utils module might be imported during Docker builds, CLI scripts, or testing, all before Flask's application context exists. Without lazy imports, you'd get RuntimeError: Working outside of application context or import failures when the module is loaded outside a running Flask app. So I am trying to avoid that.