WordPress.org

Make WordPress Core

Opened 12 months ago

Closed 12 months ago

Last modified 12 months ago

#51351 closed enhancement (fixed)

Improve clarity of privacy error strings

Reported by: garrett-eclipse Owned by: garrett-eclipse
Milestone: 5.6 Priority: normal
Severity: normal Version: 4.9.6
Component: Privacy Keywords: has-patch has-unit-tests needs-testing
Focuses: administration, ui-copy Cc:

Description (last modified by garrett-eclipse)

Branching off comment#4 of #46536 by @birgire this ticket strives to improve the error strings for privacy requests so they are more easily distinguished from other system actions/requests/exports/etc within logs.

An initial overview of the update (new words are bold);

'Sorry, you are not allowed to manage privacy on this site.' => 'Sorry, you are not allowed to manage privacy options on this site.'
'Sorry, you are not allowed to erase data on this site.' => 'Sorry, you are not allowed to erase personal data on this site.'
'Invalid request.' => 'Invalid user privacy request.'
'Invalid action.' => 'Invalid user privacy action.'
'Unable to initiate confirmation request.' => 'Unable to initiate user privacy confirmation request.'
'Unable to generate export file. ZipArchive not available.' => 'Unable to generate user privacy export file. ZipArchive not available.'
'Unable to open export file (archive) for writing.' => 'Unable to open user privacy export file (archive) for writing.'
'Invalid request ID when generating export file.' => 'Invalid request ID when generating user privacy export file.'
'Invalid email address when generating user privacy export file.' => 'Invalid email address when generating user privacy export file.'
'Unable to create export folder.' => 'Unable to create user privacy export folder.'
'Unable to protect export folder from browsing.' => 'Unable to protect user privacy export folder from browsing.'
'Unable to open export file (JSON report) for writing.' => 'Unable to open user privacy export file (JSON report) for writing.'
'Unable to open export file (HTML report) for writing.' => 'Unable to open user privacy export file (HTML report) for writing.'
'Unable to add data to JSON file.' => 'Unable to add data to user privacy export file (JSON format).'
'Unable to add data to HTML file.' => 'Unable to add data to user privacy export file (HTML format).'
'Unable to open export file (archive) for writing.' => 'Unable to open user privacy export file (archive) for writing.'
'Invalid request ID when merging exporter data.' => 'Invalid request ID when merging user privacy exporter data.'
'Invalid request ID when processing eraser data.' => 'Invalid request ID when processing user privacy eraser data.'
'An incomplete request for this email address already exists.' => 'An incomplete user privacy request for this email address already exists.'
'Invalid user request.' => 'Invalid user privacy request.' Note: This should merge strings with the one above.
'This link has expired.' => 'This user privacy request has expired.'
'Missing confirm key.' => 'This user privacy request is missing the confirmation key.'
'Invalid key.' => 'Invalid user privacy request.' Note: Merging string as this error doesn't need to be unique it just indicates the request object is missing required data.
'Invalid action.' => 'Invalid user privacy request.' Note: Merging string as missing the request timestamp indicates the request object is invalid.
'Invalid key.' => 'This user privacy request confirmation key is invalid.' Note: This is unique from the other Invalid key as the previous indicated the request is broken while this one indicates the confirmation key is invalid.
'The confirmation email has expired.' => 'This user privacy request confirmation key has expired.'

Primarily this adds 'user privacy' to the strings for clarity from other system functions when these strings are found in logs.

The above original strings were all checked for uniqueness against non-privacy uses and no correlation was found, confirming they weren't used outside of the privacy context.

Note: By making the privacy request error strings more specific I don't think we really need to apply 'context' as we wouldn't be differentiating them in a way their verbiage isn't already doing.

Feedback appreciated.

Attachments (1)

51351.diff (14.7 KB) - added by garrett-eclipse 12 months ago.
Initial patch

Download all attachments as: .zip

Change History (7)

@garrett-eclipse
12 months ago

Initial patch

#1 @garrett-eclipse
12 months ago

  • Description modified (diff)

#2 @garrett-eclipse
12 months ago

Related: #46079
*Once committed this patch will need a refresh.

#3 @carike
12 months ago

  • Milestone changed from Awaiting Review to 5.6

It would be nice to get this in early so that Polyglots have enough time to review the fuzzy strings :)

#4 @birgire
12 months ago

I read through it and this looks like a good improvement to me (at least in English)

Thank you Garrett for the detailed overview of changes.

Will be good to have more eyes on it.

Last edited 12 months ago by birgire (previous) (diff)

#5 @SergeyBiryukov
12 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 49090:

Privacy: Improve clarity of privacy error strings.

Primarily this adds "user privacy" to the strings for privacy requests, so they are more easily distinguished from other system actions within logs.

Props garrett-eclipse, carike, birgire.
Fixes #51351.

#6 @SergeyBiryukov
12 months ago

#46079 was marked as a duplicate.

Note: See TracTickets for help on using tickets.