Bug #19415
closedAudit usage of custom en_CAC locale
0%
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.