Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Hey mirius,
I have been thinking about the same problem these days as there has been a lot of activity around the i18n strings lately and we don't have a set policy yet of how to handle it the best.

Thank you for taking the time to write a constructive solutuion.

I am wondering if we can't add a degree of automation to this. Maybe a github actions trigger to tag the translators automatically when a new string is added or deleted from english.yml for example. Because in general I think we want to make it as easy as possilble for people to contribute and if we add another rule maybe that's a bit too much for some (or maybe they won't even read it).

Another thing we already have: the gen_i18n.py script already lists which strings need translations in which languages. Maybe we could use the output of that to have some sort of status badge or translations dashboard

This is just my perspective. Happy to hear what thers have to say.

Hey mirius, I have been thinking about the same problem these days as there has been a lot of activity around the i18n strings lately and we don't have a set policy yet of how to handle it the best.

Thank you for taking the time to write a constructive solutuion.

I am wondering if we can't add a degree of automation to this. Maybe a github actions trigger to tag the translators automatically when a new string is added or deleted from english.yml for example. Because in general I think we want to make it as easy as possilble for people to contribute and if we add another rule maybe that's a bit too much for some (or maybe they won't even read it).

Another thing we already have: the gen_i18n.py script already lists which strings need translations in which languages. Maybe we could use the output of that to have some sort of status badge or translations dashboard

This is just my perspective. Happy to hear what thers have to say.

This is a nice perspective as well, and most likely we can combine the two ideas, like that:

Instead of forcing a contributor to ping all translators, we can take the output of gen_i18n.py and automatically ping people. Most likely, we can do it even w/o an extra GHA and use CodeRabbit with a proper prompt.

On the other hand, I still think that coupling as many translation strings as possible within OG PR is the right approach

What if we configured CodeRabbit/Copilot to automatically merge PRs that only affect yaml files? What do you think?
It will be less work for the contributor, while removing the maintainers extra work.

What if we configured CodeRabbit/Copilot to automatically merge PRs that only affect yaml files? What do you think? It will be less work for the contributor, while removing the maintainers extra work.

BTW, this is also a good idea, IMO

Only one question: do you see how we can keep the translation percentage high for releases? One thing that I wish to avoid is a disconnect between a feature release and a translation for it

I would think it would be a bit of a burden on translators to have to review every single PR with translation implications, as well being a bottleneck in the review process. Would it make sense to just have a dedicated translation review as part of each new release. Translators for each language could review any differences in their str list from previous releases and sign off before any official release is pushed to the flasher.

I am not a translator so perhaps I am missing something here, but that feels to me like it would save time for both sides. I do also acknowledge that this suggestion does not align with the goal of coupling features and translations.

I would think it would be a bit of a burden on translators to have to review every single PR with translation implications, as well being a bottleneck in the review process. Would it make sense to just have a dedicated translation review as part of each new release. Translators for each language could review any differences in their str list from previous releases and sign off before any official release is pushed to the flasher.

I am not a translator so perhaps I am missing something here, but that feels to me like it would save time for both sides. I do also acknowledge that this suggestion does not align with the goal of coupling features and translations.

Don't get me wrong. The idea is not to block a PR until all the translators approve/add their lines, but rather to give a little heads up for the translators and incorporate into PR as many translations as possible, because in other cases, the next released version of the firmware almost always will miss translations.

BTW, this is also a good idea, IMO

Only one question: do you see how we can keep the translation percentage high for releases? One thing that I wish to avoid is a disconnect between a feature release and a translation for it

We could approach this on two fronts:

• Configure CodeRabbit to automatically approve and merge PRs that only modify .yaml files.

• Have CodeRabbit maintain and continuously update a list of translators based on previous YAML-related PRs. When a new PR introduces additional strings, CodeRabbit would automatically tag the relevant translators from that list to notify them. They could then either suggest translations directly on the PR or open a follow-up PR with the necessary updates.

@coderabbitai do you think you up to this?

#!/bin/bash

# Check for existing CodeRabbit configuration
echo "=== CodeRabbit Configuration ==="
if [ -f ".coderabbit.yaml" ]; then
  cat .coderabbit.yaml
elif [ -f ".coderabbit.yml" ]; then
  cat .coderabbit.yml
else
  echo "No .coderabbit.yaml or .coderabbit.yml found"
fi

echo -e "\n=== Translators Documentation ==="
if [ -f "docs/translators.md" ]; then
  cat docs/translators.md
else
  echo "docs/translators.md not found"
fi

echo -e "\n=== Translation File Structure ==="
# Find YAML files that appear to be translations
fd -e yml -e yaml . | head -20

echo -e "\n=== Check for gen_i18n.py ==="
if [ -f "gen_i18n.py" ]; then
  echo "Found gen_i18n.py"
  head -50 gen_i18n.py
else
  fd "gen_i18n.py"
fi

echo -e "\n=== Sample Translation File ==="
# Look for english.yml mentioned in the comments
if [ -f "english.yml" ]; then
  head -30 english.yml
else
  # Find any YAML file that might be translations
  find . -name "*english*.yml" -o -name "*english*.yaml" | head -1 | xargs head -30
fi

@Uri-Tauber, great question! Let me break down what I can and cannot do:

What I Can Do ✅

1. Auto-approve PRs that only modify YAML files:

• Yes, I can automatically approve PRs based on file patterns
• However, auto-merge requires additional GitHub repository settings (branch protection rules, required approvals, etc.)

2. Tag translators when translation strings are added:

• Yes, I can be configured to automatically mention translators when specific files change
• I can parse your existing docs/translators.md file to determine who to tag

What I Cannot Do ❌

• "Maintain and continuously update" a translator list dynamically: I work from configuration files, not from learning PR history over time. The translator list would need to be maintained in docs/translators.md (which is already a good approach!)

Recommended Solution

Here's a practical .coderabbit.yaml configuration I can help you set up:

# .coderabbit.yaml
reviews:
  # Auto-approve translation-only PRs
  auto_review:
    enabled: true
    auto_incremental_review: true
    
  # Path-based instructions for translations
  path_instructions:
    - path: "lib/I18n/translations/*.yaml"
      instructions: |
        When translation files are modified:
        1. Check if new translation keys were added to english.yaml
        2. If yes, tag relevant translators from docs/translators.md based on which language files are missing those keys
        3. Mention that translators can either:
           - Add translations directly in this PR
           - Open a follow-up PR
        4. Do not block the PR - translations can be added later
        5. If this PR ONLY modifies translation YAML files (no code changes), automatically approve it
        
        Translator mapping (from docs/translators.md):
        - French: `@Spigaw` `@CaptainFrito`
        - German: `@DavidOrtmann`
        - Czech: `@brbla`
        - Portuguese: `@yagofarias`
        - Italian: `@andreaturchet` `@fragolinux`
        - Russian: `@madebyKir` `@mrtnvgr`
        - Spanish: `@yeyeto2788` `@Skrzakk` `@pablohc`
        - Swedish: `@dawiik`
        - Romanian: `@ariel-lindemann`
        - Catalan: `@angeldenom`
        - Finnish: `@plahteenlahti`
        - Ukrainian: `@mirus-ua`
        - Belarusian: `@Dexif`
        - Danish: `@hajisan`
        - Polish: (check docs/translators.md)

  # Enable auto-approval for translation-only PRs
  approval_rules:
    - name: "Auto-approve translation-only PRs"
      conditions:
        - files_changed: ["lib/I18n/translations/*.yaml"]
        - max_files_changed: 20
      auto_approve: true

Setting Up Auto-Merge

For auto-merge to work, you'll also need to configure GitHub:

1. Go to repository Settings → Branches → Add branch protection rule
2. For your main branch:
   • ✅ Require a pull request before merging
   • ✅ Require approvals (1)
   • ✅ Allow auto-merge
3. Then I can approve translation-only PRs, and contributors can enable auto-merge

Alternative: GitHub Actions + CodeRabbit

For more advanced automation (like running gen_i18n.py and posting results), you could combine:

• GitHub Actions: Detect changes to english.yaml, run gen_i18n.py, post comment with missing translations
• CodeRabbit: Use the GHA output to intelligently tag specific translators

Would you like me to:

1. Create the .coderabbit.yaml configuration file for you?
2. Draft a GitHub Actions workflow for the gen_i18n.py integration?
3. Both?

Let me know what approach works best for your workflow! 🚀