Closed mabdullahadeel closed 1 year ago
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%> (ø) |
:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more
@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?
@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.
Summary
gettext_lazy
so that translations for different messages and prompts can be supported.