You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I was wondering can the strings in responses in views get changed so rest-auth is compatible with UJSONRenderer?
Seems like ujson doesn't track well with Django's proxy objects when outputting json.
I've noticed that I get weird response from logout endpoint and managed to break it down to the message in the response.
this results in such a response {"success":["S","u","c","c","e","s","s","f","u","l","l","y"," ","l","o","g","g","e","d"," ","o","u","t","."]}
I've noticed that if the string is evaluated by putting it in u'{}'.format(_("Successfully logged out.")) or through `unicode(_("Successfully logged out.")) the response is:
{"success": "Successfully logged out."}
Would ugettext_lazy removal be valid for this situation? If ugettext is used the message is as it should be!
If the goal is to support translation rather then optional renderers I'll fix it in my fork and keep it there but maybe using traslated strings a not lazily translated would be such a problem here?
The text was updated successfully, but these errors were encountered:
Hi, I was wondering can the strings in responses in views get changed so rest-auth is compatible with UJSONRenderer?
Seems like ujson doesn't track well with Django's proxy objects when outputting json.
I've noticed that I get weird response from logout endpoint and managed to break it down to the message in the response.
this results in such a response
{"success":["S","u","c","c","e","s","s","f","u","l","l","y"," ","l","o","g","g","e","d"," ","o","u","t","."]}
I've noticed that if the string is evaluated by putting it in
u'{}'.format(_("Successfully logged out."))
or through `unicode(_("Successfully logged out.")) the response is:{"success": "Successfully logged out."}
Would ugettext_lazy removal be valid for this situation? If ugettext is used the message is as it should be!
If the goal is to support translation rather then optional renderers I'll fix it in my fork and keep it there but maybe using traslated strings a not lazily translated would be such a problem here?
The text was updated successfully, but these errors were encountered: