I'm using auth.password_reset for a view with my own template. The template has 1 string of text that will not translate. I'm not exactly new to i18n so I'm 99% sure I covered all my bases and that it would translate if it were my own view. Here are the things I made sure not to forget:
-Removed the ;fuzzy tag
-Made sure I had the right translation string
-ran makemessages, translated and compilemessage
-restarted my server
Any idea what is going on?
Related
Tailwind offers a feature where you can give an input element the peer class and then, in a sibling element use the peer-invalid: pseudoclass to apply conditional stylings. This is commonly used to provide helper text when a form field is not valid.
I don't see how this can be tested in JS-DOM though, as JS-DOM doesn't have access to the actual CSS when it is just rendering components in unit tests.
The information I have seen about getting JS-DOM to use CSS at all is kinda sketchy, so I was wondering if it's even worth trying to get it to evaluate a bunch of tailwind classes in a NextJS/Jest/RTL project. I'm using Tailwind 3 so it's not even like I have a big file full of generated classes I could try and pass to JS-DOM :/
So can it be done? (Note the hard fact please mods!!!)
(And, somewhat more subjectively, should it be done? Or is there a better way to approach this?)
I was working with an open-source project (made in Django). I couldn't understand what pgettext_lazy is used for. Can you please tell me
What is pgettext_lazy?
Usage of pgettext_lazy?
pgettext_lazy(..) [Django-doc] is a function that is used to translate text. The Django documentation has a section on translation [Django-doc] that discusses this.
pgettext_lazy is a lazy variant of pgettext. This is a function that makes context-aware translations [Django-doc]. Context-aware translations deal with the fact that a word can be translated in multiple ways. For example May can be translated as the name of a month, or a verb.
We can make it clear how to translate it by adding a "context marker", and thus call the translation with:
from django.utils.translation import pgettext
month = pgettext("month name", "May")
In your .po file(s), the files you use to define translations, you can then add the context marker:
msgctxt "month name"
msgid "May"
msgstr ""
You can make translations in the views in the language that is activated, but you can not just define that translation in for example the help_text of a model. Indeed, if you would call pgettext(..) in a models.py file. It would translate the help_text in the language that is active at that time. But if later a user with a different language uses that help_text, it would not be translated in the other language.
By making the translation lazy, the process of translation is postponed until a str(..) is called on the result. That way, if you render the lazy object in a template it will be translated in the language of the user.
You can find more information on this in the Translation section of the documentation.
Hy!
I would need to make urls based on language.
Example:
If I had the language english and subcategory named "articles" then the url might be like this:
/en/articles/...
If the language were portuguese and subcategory already translated is "artigos" then the url will be:
/pt/artigos/...
How can I do it?
I must use the urls.py or some monkeypatches?
thanks
This features is already existing in the yet-to-be released version 1.4. You can read about it in the release note.
If your really need this feature, and no existing app feets your needs, you can still try to apply the corresponding patch yourself.
Django LocaleURL is a piece of middleware that does exactly this. The documentation can be found in the source, or online.
Edit: I read over the fact that you want to translate the url itself... I'm not aware of any piece of code that provides this. Perhaps you could extend the LocalURL middleware to take care of the translations for you. Say you have a regex match like (?P<articles>\w+), you could in the middleware determine which view you want to use. Something like the following mapping perhaps?
if article_slug in ['articles', 'artigos', 'article']:
article(request) # Call the article view
I've been using transurlvania with great success, it does exactly what you need and more, however i see that in the next Django release django-i18nurls will be included in django core so perhaps it would be better to learn that
There's one thing in (new) Rails I envy: internationalization support (Django has one too, but I prefer Rails' flavour).
The key difference between Rails' and Django's approaches is what kind of string behaves like keys in key-value translation mapping, i.e.
Django version (keys - strings in "main" language, for example english):
msgid "Save and quit"
msgstr "Zapisz i wyjdź"
Rails version equivalent (keys - abstract strings; standalone unusable - one need to provide at least 1 "translation") - actually, Rails uses YAML format, but following example present the idea:
// english translation file
msgid "SAVE_QUIT_MESSAGE"
msgstr "Save and quit"
and
// polish translation file
msgid "SAVE_QUIT_MESSAGE"
msgstr "Zapisz i wyjdź"
Rails' way of supporting i18n is IMHO much better (think of key immutability - resistant to grammar/spelling corrections; language agnosticism etc).
One way to utilize this schema in Django would be to use some abstract language for the sole purpose of being translated (strings in that language would make immutable keys), but Django support only fixed set of languages. Another solution - sacrifice one of the supported (unused) languages to play this role - but this is just bad :P
Any ideas/third-party apps/techniques to solve this issue?
Sidenote: extending i18n support for artibrary languages would give funny opportunities:
// slang translation file
msgid "SAVE_QUIT_MESSAGE"
msgstr "Save shit 'n' quit, bro"
Step back for a minute or two. Your doing triple work here. First you have to come up with a UNIQUE_ID and then you force people to look up either the context from the code or another language file to figure out what would the proper message for AMBIGUOUS_ARGUMENT_PROVIDED would be until you get down to providing the actual translation. And who ever said that creating IDs that can meaningfully convey the context and provide good message hints was ever easy?
What your trying to do is some preposterous shit bro! Jokes aside, the reason gettext is the most prevalent and widely used i18n and l10n API is because each message gets a unique message catalog ID assigned from it's contents and because it's proven you'll have a way better time translating messages than providing translations for IDs, reminiscent of when everyone tried making their own key->value i18n framework because it was the most straightforward to design.
You'll eventually conclude that it was a bad idea to use gettext the way it wasn't meant to and you can save yourself right now by forgetting about the whole idea.
If you insist on doing it this way, then it can be done by generating a .po file that will contain the English translations of the source strings.
I'm in a Django website's I18N process.
I've selected two potentially good django-apps :
django-modeltranslation which modifies the db schema to store translations
django-dbgettext which inspect db content to create .po files and uses gettext
From your point of view, what are the pros and cons of those two techniques ?
If you want to let users of your app(or third party translators) easily update the translations without code changes then go for one of the solutions that stores the translations in the database.
If you instead want greater quality control(version control, several set of eyes, etc), then use gettext. By using gettext you may also control which strings you want translate.
Just my 2c.
django-modeltranslation is best for storing translated value. you will go to django-admin and put translated value.
But If you are using django-dbgettext, then you dont need to put any value in django-admin, you can use rosetta for that. If you are not able to look any value for translation and you want it to translate, then you can do entry of model in "*dbgettext_registration.py*" and run command "python manage.py dbgettext_export" then "python manage.py compilemessages".
http://packages.python.org/django-easymode/ combines the two:
http://packages.python.org/django-easymode/i18n/index.html
http://packages.python.org/django-easymode/i18n/translation.html
Gettext is used to translate large ammounts of data, and the admin is used for day to day updates.
I would suggest you always use files for your translations. It's portable and doesn't have unknown impacts on DB performance (especially an issue when using "magic" packages that monkey patch your DB schema)
This package looks simple and extensible: https://github.com/ecometrica/django-vinaigrette