Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

✅ added I18N support #216

Merged

Conversation

mabdullahadeel
Copy link
Contributor

Summary

  • added gettext_lazy so that translations for different messages and prompts can be supported.

@codecov-commenter
Copy link

Codecov Report

Merging #216 (5aacf45) into master (f107afe) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master      #216   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           24        24           
  Lines          595       597    +2     
=========================================
+ Hits           595       597    +2     
Impacted Files Coverage Δ
src/rest_framework_api_key/admin.py 100.00% <100.00%> (ø)
src/rest_framework_api_key/models.py 100.00% <100.00%> (ø)

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

@florimondmanca
Copy link
Owner

florimondmanca commented Jun 15, 2023

@mabdullahadeel Hi, seeing this just now after a break period. Thank you very much for the PR.

Do you happen to know if a Django third party app can come with its own translations? We could add translations for some languages (I could do French).

Also, I wonder what the best practices for translations are. In certain projects I’ve seen people use codes such as api_key.created.confirmation_message bundled with at least English translations, rather than using the English prose as the translation key. It does see easier to me if I were to add translations as a translator. Does that sound reasonable?

@mabdullahadeel
Copy link
Contributor Author

@florimondmanca
In general its good idea to wrap text in gettext_lazy, that way, either user can add his/her own translations or library can also provide some defaults (which is not very common though).

Coming to the naming conventions for the translation, it's recommended to not use this.is_the_translation syntaxt as no one immediately will know what the key for particular translation text is. If the text clearly says it in default (English), user can easily add translation without going deep into the library codebase to find the exact keys.

Copy link
Owner

@florimondmanca florimondmanca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine with me. Thanks @mabdullahadeel!

@florimondmanca florimondmanca merged commit 94b719b into florimondmanca:master Jun 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants