Improve Translation Coverage, Localization Tests, and Documentation for i18n

[mahdirahimi1999]

Improve i18n Reliability, Translation Coverage, and Documentation

This pull request introduces a set of enhancements aimed at improving internationalization (i18n) support across the project. The updates focus on localization testing, translation accuracy, and developer documentation to ensure a more stable and user-friendly multilingual experience.

---

Summary of Changes

1. Improved Localization Reliability

The i18n/l10n test suite has been refactored to enhance maintainability and catch common localization issues early in development.

Notable improvements:

• Translation Coverage Validation: Tests now ensure all message keys exist across all .po files, and every language declared in constants has a corresponding translation file. This prevents missing translations in production.
• Localized Error Message Tests: Extended coverage to include translated error messages, including edge cases like invalid API settings (ALGORITHM) and token validation errors.
• Developer-Friendly Debugging: Leveraged subtests to surface multiple translation failures in a single test run, improving development efficiency.
• Test Isolation: Tests that modify global or runtime settings are now isolated to prevent side effects and order-dependent failures.

2. Translation Improvements

• French (fr):
  • Fixed capitalization for the translation of "user" to match the .po file (Utilisateur).
• Chilean Spanish (es_CL):
  • Fixed capitalization for the translation of "user" to match the .po file (Usuario).
• Persian (fa, fa_IR):
  • Refined translations for clarity and consistency, especially in error messages and algorithm-related terms.
• Dutch (nl_NL):
  • Fixed a typo in the translation for "Unrecognized algorithm type".

3. Test Dependency Update

• Added polib to setup.py test dependencies to enable .po file parsing in tests and CI environments.

4. Documentation Updates

• Improved documentation with clear instructions on enabling translation support via LOCALE_PATHS.

---

Impact

• Developers gain a more dependable localization testing framework.
• Translators benefit from more consistent and accurate source strings.
• Users enjoy clearer, localized error messages and improved setup documentation for enabling translations.

---

Note:
This PR also ensures that the test suite and translation files are in sync, preventing false negatives in CI and making it easier to maintain translation quality as the project evolves.

[Andrew-Chen-Wang]

Thank you! You will need to rebase first.

[mahdirahimi1999]

Thank you! You will need to rebase first.

You're welcome! Done.

[mahdirahimi1999]

I’ve done the rebase, this PR is now updated @Andrew-Chen-Wang
Could you please check it?

[Andrew-Chen-Wang]

This file is unreviewable. We'd have to update this all the time, and there isn't really a need to test for these messages.

[Andrew-Chen-Wang]

same with this file

[mahdirahimi1999]

Hi, thanks for the feedback. I see your point about the extra work to maintain these test files.

The main reason I added them was to fix the bugs in this PR. In fact, many of the corrections in the .po and .mo files were identified by running these exact tests. They now work as a safety net to catch similar issues in the future.

By keeping tests/test_locale_messages.py and test_token_validation_and_localization.py, we can make sure that future translation updates won't accidentally break the API for users.

It's a small step to prevent bigger problems down the road, and that's why I think keeping them is a good idea.

Need to re-review

[Andrew-Chen-Wang]

Hi I can accept the translation fixes, but it is obvious you are using AI to generate these test files and PR. It's fine to use AI, but there isn't human-centric thinking going behind those test files. There is no way we'd update the test files because they rely on making sure we update the translations and the test files.

[mahdirahimi1999]

Hi I can accept the translation fixes, but it is obvious you are using AI to generate these test files and PR. It's fine to use AI, but there isn't human-centric thinking going behind those test files. There is no way we'd update the test files because they rely on making sure we update the translations and the test files.

Hi, thank you for the detailed feedback!

I'd like to clarify that none of these tests were generated by AI; they were all written manually. For reference and to show my approach to contributions, here are some of my other pull requests in this and similar projects:

• djangorestframework-simplejwt:

  • feat(auth): Revoke refresh token on password change #928
  • Add Django 5.2 support to test matrix and packaging #907
  • Revoke access token if user password is changed #719

• django-rest-framework:

  • Prevent small risk of Token overwrite encode/django-rest-framework#9754
  • Refactor token generation to use secrets module encode/django-rest-framework#9760
  • Refactor get_field_info method to include max_digits and decimal_places attributes in SimpleMetadata class encode/django-rest-framework#8943

• Chromium:

  • https://chromium-review.googlesource.com/c/chromium/src/+/6875163

Regarding the very problem you pointed out—that the test files need to be updated whenever the translation files change—that was actually an intentional design. The idea was to require that users who modify the translations must also update the corresponding test file. This approach allows us to track which parts of the translations have changed and to identify any potential "breaking changes."

However, I understand your perspective and will follow your guidance. As you suggested, I will remove these two files from this pull request.

[Andrew-Chen-Wang]

In OSS, getting volunteers for translations/contributions in general is very tough. Asking for too much would be a burden. Thanks for understanding.

[mahdirahimi1999]

@Andrew-Chen-Wang
Hi, PR updated.