Maintaining translations for frontend applications is a very easy task to automate in all cases except when one of these two conditions is met:

• Your codebase has places where translation keys are dynamically generated, e.g. t(`main.fields.${field}`).
• Translation keys are stored in a database, returned by an API, or located anywhere else outside the application codebase.

Ways to Deal with Maintenance Issues

To make the first case maintainable, we need to eliminate dynamic key generation by moving all such cases to Map<string, string>, conditionals, factories, or other helpers. The only requirement is that after refactoring, translation keys must be stored in the codebase in static form so that we can find them with full-text search.

The second case is more difficult to maintain. First of all, storing translation keys in any external location should be avoided. If you need to return a translation key for some model via API, it’s better to return an intermediate entity, such as a constant string that will be mapped to a translation key in the application code. This way, the translation keys remain searchable.

Another method to deal with both cases is to place dynamic translation keys in a separate namespace in your translations.json or translations.yaml. This way, you can tell the script to ignore the dynamic keys namespace while all other keys will be considered safe.