Custom language file does not load in bp_core_load_buddypress_textdomain()

[r-a-y]

WP now handles language pack downloads.

Let's say a language pack is downloaded and used for BP, the latter section in bp_core_load_buddypress_textdomain() references a custom language file that ​never gets loaded since a language file is already in use.

I think it should be the opposite. Custom language files (if they exist) should take precedence over GlotPress language packs.

Attached are two approaches to addressing this.

1. custom_language_file.patch - basically reverses the order of textdomain checks
2. load_plugin_textdomain.patch - simply uses load_plugin_textdomain() without the extra parameters since we don't bundle language files in /buddypress/bp-languages any more. This means that WP will look at wp-content/plugins/ for the language file first, and then wp-content/languages/plugins (where the language pack is downloaded).

The first patch is more backward-compatible.

[boonebgorges]

For the record: this is not a regression in 2.1. What's happened in 2.1 is that we've removed the bp-languages directory (because of changes in our build script). Removing this directory has made some folks come out of the woodwork to note that they had previously been putting their custom language files into the bp-languages directory. http://buddypress.org/support/topic/buddypress-2-1-bp-language/

never gets loaded since a language file is already in use.

If I understand the situation correctly, this statement is a bit too general. Our recommended practice has been to put a file buddypress-$domain.mo at WP_LANG_DIR. It appears that this will "never get loaded" if WP has downloaded a translation for the same $domain. In other words:

wp-content/languages/buddypress-fr_FR.mo
will never be loaded if there is a
wp-content/plugins/buddypress-fr_FR.mo

But if you're using a custom domain, or if WP has not downloaded a "canonical" translation, the custom language pack should load just fine.

I think it should be the opposite. Custom language files (if they exist) should take precedence over GlotPress language packs.

All this being said, I agree with this statement. As much as I like the elegance of your second patch, I think we should attempt to maintain backward compatibility with the currently recommended technique of having a file directly in WP_LANG_DIR.

[DJPaul]

I think we ought to put a fix for this in the 2.1 branch (maybe the first patch).

[boonebgorges]

Replying to DJPaul:

I think we ought to put a fix for this in the 2.1 branch (maybe the first patch).

DJPaul - Care to say a bit more about this? This is not technically a regression, though perhaps changes in 2.1 have made some odd practices a bit more visible. Is your concern that this is severe enough/affecting a large number of users?

[DJPaul]

I think we've just had more discussion from users on the forum about this fairly niche "feature" than we've had for anything for a few releases. As we need a minor release to push out a new build of BP-Default to fix the compatibility issues, we could sneak it in -- we're not proposing to do a release just for this ticket.

If you or any of the other core devs feel that you have a strong justification to not do this (to only fix it in 2.2), I'm OK to live with that.

[boonebgorges]

Thanks, DJPaul. I have no real objections, other than general conservativeness. r-a-y, can we go with your more conservative fix for 2.1.1?

[r-a-y]

The first patch doesn't do any harm. I haven't tested what happens if someone is already loading the same language file with some custom code though, but that's edge-case.

[imath]

I've tested r-a-y's first patch. It's working fine. But i think it can bring some confusion as if for instance you add the buddypress-fr_FR.mo at the root of WP_LANG_DIR then it will be listed in the available site language.

​https://cloudup.com/c7kNPwn868e

If you look at get_available_languages(), you'll see that there is no filter available to remove files placed at the root of WP_LANG_DIR. So i'm not sure it's the right place to add a custom language file to override the one that is placed in WP_LANG_DIR/plugins. It seems to me this place is restricted to site language files

[imath]

We can avoid this by putting the custom language files in a buddypress folder in WP_LANG_DIR directory

I think it's a good compromise between "the currently recommended technique of having a file directly in WP_LANG_DIR." and the fact BuddyPress language file is showing in the site's language dropbox.

so /wp-content/languages/buddypress/buddypress-fr_FR.mo instead of /wp-content/languages/buddypress-fr_FR.mo

I've adapted r-a-y's first patch to this organisation in 5887.bp_folder_language_file.patch

What do you think ?

[r-a-y]

Good catch on the "Settings > General" page, imath.

I definitely agree that our custom BP language file should not show up there. A pity that there is no filter in get_available_languages(). One workaround is renaming the language file to ms-buddypress-fr_FR.mo. Because that function omits language files with that prefix, BP will not show up as an option. Kinda ugly, I know.

If we are going to add another subdirectory, I would use /wp-content/languages/custom/ so potentially other language files can be added there by other plugins.

[imath]

I think we need more time to take a decision about it, thanks a lot r-a-y for your feedback.

[danbp]

My point of view.

akismet, as native WP plugin lives in wp-content/languages/plugins/akismet.mo
bbpress, as additionnal plugin, lives in wp-content/languages/bbpress/bbpress-xx_XX.mo

logically
buddypress, as additionnal plugin, should be in wp-content/languages/buddypress/buddypress-xx_XX.mo

For now, automated update affects wp-content/languages/plugins/buddypress-xx_XX.mo

This must be cleared first:
Are akismet, bbpress and buddypress plugins or are they so different that each one has his own direcory. If those plugin translation must be provided by the same automated process, it is also logic that they could/should/must be in the same directory.

wp-content/languages/
or
wp-content/languages/plugins
or
wp-content/languages/plugins/plugin_name/

The other problem is the case of a custom translation who doesn't come from wp translate but who only use the pot file.

So i think we must have a custom folder somewhere.

This custom folder must stay intact to preserve a custom translation, but must receive the pot, like it was previously with /bp-languages/buddypress.pot

Not every BP install is using a custom translation, but i think that responsible of such installs are aware of customization and know how to handle their work.
The question is not how to use it, but where, to put this customization.

My suggestion:
wp-content/languages/one_of_the_3_option_above/custom/buddypress-xx_XX.mo with a priority of 1, and if empty/not exist, default to one of the adopted option.

That way, people who want the default translation are automatically updated from glotpress and those who want a custom work, receive a pot in a dedicated custom folder where they can add their custom mo

[imath]

FYI, just posted a ticket on core trac about the site languages dropdown to check if it's something that should be handled by WordPress directly.
​https://core.trac.wordpress.org/ticket/29892

[imath]

I think we really need to give site admins the choice, so i'm suggesting 5887-multiple-locations.patch (i may exaggerate with the array of possible locations + filter)

I think it might also be useful to english people. Because, there can be contexts where default / or default translated strings don't match the purpose of the site using BuddyPress.

For instance, i use BuddyPress in a company, so all strings containing 'friends' or 'amis' don't match at all the purpose of my community (i'm using contacts instead). So having ways to override the default translation is really really important for BuddyPress. Another example that comes to my mind is thirdscribe.com which built a community around books where groups are books.

[danbp]

+1 @imath! #5887 is a really good compromise for translators or even custom language users.

And a question, just to get this clear for the future: what about the pot file ?
Where/how will this file be accessible ?

[DJPaul]

​#WP29892 has been updated in 4.1 now so that it only shows translations for WordPress core inside the drop-down box.

[DJPaul]

I think WP_LANG_DIR . '/custom' is unnecessary, but I think the patch is OK other than that. imath, want to finish this sometime? Since you have a non-English install, you'll probably find it easier to test all the different permutations.

[imath]

Replying to DJPaul:

imath, want to finish this sometime? Since you have a non-English install, you'll probably find it easier to test all the different permutations.

Sure working on it :)

[imath]

In 5887-multiple-locations.02.patch :

• i've removed the WP_LANG_DIR . '/custom'.

• I agree that since 4.1, the problem i've reported on ​#WP29892 has been resolved, meaning we can directly use this location: /wp-content/languages/buddypress-fr_FR.mo and be sure it's not listed in the Site's Language admin dropdown. But i suggest to keep this location: /wp-content/languages/buddypress/buddypress-fr_FR.mo as we support WordPress back to 3.6.

[DJPaul]

Let's do it

[imath]

In 9247:

Make sure custom language files (if they exist) are taking precedence over GlotPress language packs

There can be cases where a community needs cutom language files. In order to make sure these custom language files are loaded, BuddyPress will first check 2 locations before loading the GlotPress language packs :

• WP_LANG_DIR . '/buddypress'
• WP_LANG_DIR

Using the WP_LANG_DIR . '/buddypress' location for the custom language files avoids the mo file name to be listed into the site's language setting of the WordPress general options.

We are also introducing a new filter 'buddypress_locale_locations' so that it's possible to add a custom location to the ones listed above.

Props r-a-y, boonebgorges,danbp,DJPaul

Fixes #5887