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

Add FAQ entry regarding StrPromise to README #1320

Merged
merged 2 commits into from
Jan 14, 2023

Conversation

mschoettle
Copy link
Contributor

@mschoettle mschoettle commented Jan 12, 2023

I have made things!

Follow-up from my question in #1319, this PR adds a FAQ entry to the README with a small code snippet.

The first commit addresses some markdownlint violations (still 1 left).

Related issues

Refs #1319, #689

README.md Outdated
errors.add(_('Error message'))
```

If this is reported on Django code, please report an issue or open a pull request.
Copy link
Collaborator

@intgr intgr Jan 12, 2023

Choose a reason for hiding this comment

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

Sometimes also the correct solution is to call str(value) on the StrPromise, for example when passing to a third party library that expects a str type value. Although when done incorrectly, this may result in the translation being evaluated too early.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, I can add this. Are you aware of any documentation on when it might be sufficient to evaluate translations (too) early?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Copy link
Collaborator

Choose a reason for hiding this comment

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

In particular:

Using gettext_lazy() and ngettext_lazy() to mark strings in models and utility functions is a common operation. When you’re working with these objects elsewhere in your code, you should ensure that you don’t accidentally convert them to strings, because they should be converted as late as possible (so that the correct locale is in effect). This necessitates the use of the helper function described next.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, that's great. I revised the text and removed the code snippet.

@intgr
Copy link
Collaborator

intgr commented Jan 14, 2023

Thanks! I suggest you add a direct link to https://docs.djangoproject.com/en/4.1/topics/i18n/translation/#working-with-lazy-translation-objects as well. Maybe instead of one of the GitHub links.

@mschoettle
Copy link
Contributor Author

Thanks! I suggest you add a direct link to https://docs.djangoproject.com/en/4.1/topics/i18n/translation/#working-with-lazy-translation-objects as well. Maybe instead of one of the GitHub links.

Ah, apologies! I forgot to add the link to the text. I had it in the second paragraph (fixed). If you prefer that I replace one of the GitHub links as well I can do that (I would change the link to "cannot be used interchangeably" then).

Copy link
Collaborator

@intgr intgr left a comment

Choose a reason for hiding this comment

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

This looks good to me.

@intgr
Copy link
Collaborator

intgr commented Jan 14, 2023

If you prefer that I replace one of the GitHub links as well

Na it was just a thought.

@intgr intgr merged commit 54a1e89 into typeddjango:master Jan 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants