The i18n functionality of Angular itself is very comprehensive and can be complex, particularly in large codebases where people's conventions, and exceptions to those conventions, need to be accounted for.

We have an existing i18n rule in @angular-eslint/eslint-plugin-template which is already quite heavy, but there have been a number of requested additions which have not yet been addressed.

Not all of these proposals are complementary (as well as some requiring breaking changes to existing features) and so it is worth stepping back and reimagining our i18n support as a whole.

One open question is: Do we want to split i18n into multiple rules instead of one all encompassing one?

• Pro: Matches other things conceptually, where we don't try and capture every possible feature related to e.g. component metadata in one rule
• Con: May require duplication of code and effort

One thing that makes this trickier is that I have never personally leveraged the i18n functionality in Angular, so I don't have a perfect intuition for the most effective lint feedback.

This issue is open for community discussion and design and I am looking for quality input from experienced users of both the i18n feature set in Angular and the existing i18n rule and its current shortcomings.

In terms of roll out of changes:

• New rule(s) will be added in v20 minor and the existing one will be deprecated
• Old rule will be removed in v21 and an automated migration to the new one(s) provided wherever possible

Thanks all!