django_admin_log table stores messages in different languages depending on which language was active while editing.

[dimyur27@…]

In my project (in development) there are 3 different languages supported. Admin site supposed to have 3 main superusers, each is a native speaker of one of the languages. If one superuser edited an object, another one is not able to read what his fellow superuser previously did, because "Change history" page doesn't respect the current user language and displays the messages in the language that was current when the changes took place.
Maybe change_message field should be removed and the messages generated each time they are displayed.
So is object_repr, because object's representation may be dependant on the current language too.
Thank you.

[wim@…]

Accepted. I'd like messages to be language-agnostic and translatable.

[jooyous]

So at this point I understand how to change this so all subsequent log entries behave correctly. But currently the translated strings are being saved away as part of the object, and I think (?) this means we've lost the information of the starting language, so the only way I can think of fixing *existing* histories is by writing a script and having the user run it, specifying their relevant languages?

[Claude Paroz]

Fixing existing history might be impossible to achieve. I wouldn't set that as a goal for this ticket.

[anonymous]

I can't get ugettext to translate "Changed" for some reason, even though there are bits of code where it does it successfully and I'm not sure what I'm doing wrong.

[jooyous]

Replying to anonymous:

I can't get ugettext to translate "Changed" for some reason, even though there are bits of code where it does it successfully and I'm not sure what I'm doing wrong.

Whoops, that was me. Didn't realize I was logged out.

[jooyous]

Hellooo I am still working on this.

[jooyous]

​https://github.com/django/django/pull/3345

Here's a partial fix for this bug. It changes the log messages so that they're saved in the database in English and then parsed and translated when they need to be displayed. However, due to the way the change messages were written upon being entered into the database, I wasn't able to properly distinguish between different types of save messages. For example, if an object (for example, a Poll or Choice) contained a period or quotation marks in the body, I could not tell the difference between the end of the message and the punctuation within the message body. So I'm only submitting a partial fix. From what I could test, it works pretty well for Users. I was also having some trouble getting certain words to translate.

If having history messages displayed in different languages is a priority, I would recommend restructuring the logging functionality entirely, and have the messages be saved in an unambiguously delimited format (yaml? json? something!) so that they can be formed into translatable sentences after they are extracted from the database. I would be willing to work on this if an issue gets made!

[Claude Paroz]

Replying to jooyous:
(...)

If having history messages displayed in different languages is a priority, I would recommend restructuring the logging functionality entirely, and have the messages be saved in an unambiguously delimited format (yaml? json? something!) so that they can be formed into translatable sentences after they are extracted from the database. I would be willing to work on this if an issue gets made!

Yes, I think that this would be the right approach.

[Claude Paroz]

​PR

[Tim Graham]

Left comments for improvement on the pull request.

[Claude Paroz <claude@…>]

In 35c4198:

Moved LogEntry-related tests to their own test case

Thanks Tim Graham for reviewing and contributing to the patch.
Refs #21113.

[Chris Cogdon]

I know this is very late to the party, and it's not that critical of an issue, but generally it is considered good form [citation-needed] to ensure the top level of a JSON structure is an object/dictionary, rather than a list, string, int, etc. django.http.response.JsonResponse for example considers anything except a dict to be 'unsafe'.

The change is simple... just use {'changes':[ ...]} rather than simply [...], but this does involve changing the entire patch. 😦

[Claude Paroz]

Changing the entire patch is not an issue at all.

I would appreciate though if you could find some reference about this design issue.

[Tim Graham]

From a bit of searching, I guess the "good form" is to mitigate ​JSON hijacking? Those concerns probably aren't relevant here.

[Tim Graham]

Left a few more comments on the pull request.

[Claude Paroz <claude@…>]

In cf7894be:

Fixed #21113 -- Made LogEntry.change_message language independent

Thanks Tim Graham for the review.

[Tim Graham]

Possible flaky test seen ​on Jenkins:

admin_utils.test_logentry.LogEntryTests.test_logentry_change_message

Stacktrace

Traceback (most recent call last):
  File "/mnt/jenkinsdata/workspace/django-master/database/mysql/python/python3.5/tests/admin_utils/test_logentry.py", line 65, in test_logentry_change_message
    self.assertEqual(logentry.get_change_message(), 'Changed title and hist.')
AssertionError: 'Changed something' != 'Changed title and hist.'
- Changed something
+ Changed title and hist.

[Claude Paroz]

Probably an issue with .latest(), on MySQL, not by chance! We may find another way to get the target logentry based on another criterion...

[Claude Paroz <claude@…>]

In 4a03e6f2:

Refs #21113 -- Updated test to allow for bad MySQL time resolution