Privacy: The personal data export file should be generated in the user's locale

[coreymckrill]

Similar to #43985, the HTML file containing the personal data export should be translated into the locale the user has selected for their profile, with a fallback to the site's locale.

[iandunn]

It'd be nice to get this in 4.9.6, but at this point it doesn't seem like there's enough time. cc @desrosj just in case you think it should be there.

[desrosj]

@iandunn I agree. Would be great, but I don't think there is enough time to test this properly. If a committer feels strongly about this for 4.9.6, they are more than welcome to see it through.

[desrosj]

Moving to the new Privacy component.

[desrosj]

Marking privacy bugs as introduced in 4.9.6.

[desrosj]

Moving all tickets in 4.9.7 to 4.9.8.

[sebakurzyn]

I already tested this bug and everything works correctly. Tested on Duch translation, single site. Email and export data have the correct language.

[SergeyBiryukov]

Tested with the following configuration:

• Site's default locale: English (en_US)
• Administrator's locale: Russian (ru_RU)
• Editor's locale: Spanish (es_ES)

When exporting Editor's personal data, both the confirmation email and the export file use the administrator's locale (Russian in my case). Per comment:9:ticket:43985, they should use the requester's locale instead (Spanish in my case), with a fallback to the site's default locale for visitors who don't have an account.

[vanyukov]

Added a patch. Will update the locale if the email for data export is from a valid user

[desrosj]

44084.diff​ is a different approach than file.diff​.

It utilizes the user ID stored in the WP_User_Request object to prevent an unnecessary database query in get_user_by(). It also switches to the site's default locale if the current user is using a different locale, and switches back after the file is done generating.

There are a few strings not included in the actual file that are still not translated:

• the stripped email, which has @ replaced with -at-.
• the file basename, which is wp-personal-data-file-$stripped_email.

These two strings should probably be translated as well. But proper sanitization will need to be added for filenames with non-English characters.

Another situation to consider. An administrator can click a link to download the data export file in the admin. When that is clicked, a fresh file is generated. With 44084.diff​, the file will always be in the user's selected locale. Should the file ever be generated in the administrator's locale instead?

Tests for this change should be added to the test class being worked on in #44233. I can add those once that is committed.

[desrosj]

After discussion in yesterday's #core-privacy chat, it was determined that the data should be exported as follows:

• If the user's locale matches the site's default locale, only one export file in that locale will be generated.
• If the user's locale does not match the site's default locale, two files will be added to the ZIP file (one in each locale).
• If the administrator's locale does not match either of these, no additional action will be performed.

[johnbillion]

Needs a new patch as the proposed approach to this task has changed.

[apedog]

This ticket might be related. A get_admin_locale() option that is independent of the Administrator's personal-preference user locale and independent of the front-facing site locale.

#49971

[desrosj]

With no activity in 5 weeks and beta 3 later today, I am going to punt this one. If someone can create a well rounded patch before RC1 (1 week from today), then it can be reconsidered.