Project

General

Profile

Actions

Bug #19415

closed

Audit usage of custom en_CAC locale

Added by Raymond Hoh 11 months ago. Updated 10 months ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
WordPress (misc)
Target version:
Start date:
2023-12-14
Due date:
% Done:

0%

Estimated time:
Deployment actions:

Description

In our codebase, we use a custom en_CAC locale to load these strings:
1. WordPress - https://github.com/cuny-academic-commons/cac/blob/12e3001973274946faa69cd37360a2d7fce35f04/wp-content/plugins/bp-custom.php#L492-L509
2. BuddyPress - https://github.com/cuny-academic-commons/cac/blob/12e3001973274946faa69cd37360a2d7fce35f04/wp-content/plugins/bp-custom.php#L172-L176
3. BP plugins - https://github.com/cuny-academic-commons/cac/blob/12e3001973274946faa69cd37360a2d7fce35f04/wp-content/plugins/bp-custom.php#L1837C4-L1865

For point 1, en_CAC is not a valid locale and can cause issues when using certain javascript libraries like Shoelace that attempts to load a locale file for CAC. Also, most of the strings in our custom WordPress localization file are no longer being used. I would recommend removing the update_option( 'WPLANG', 'en-CAC' ) approach and doing string overrides using the 'gettext_default' filter on a page-by-page basis. It looks like the only string we would need to override is the one for /wp-admin/ms-delete-site.php: https://github.com/cuny-academic-commons/cac/blob/12e3001973274946faa69cd37360a2d7fce35f04/wp-content/languages/en_CAC.po#L34-L38 .

Points 2 and 3 are not as important to address, but it looks like we only made a few changes overall: https://github.com/cuny-academic-commons/cac/commits/master/wp-content/languages . I think we need to audit this list to determine whether most of our string overrides are even necessary nowadays.

Actions

Also available in: Atom PDF