BuddyPress.org

go to Users – profile fields
try found message on page “BuddyPress Multilingual – have no translated fields” something like that. there is a button in the message, we press it, wait and now we can translate into string translation.
I searched for a long time and why the authors of the plugin did not include this in the instructions.

Hi @glenphillips33,

Anything is possible, what’s unknown is the probability. IIRC, I had a similar experience, but it involved the wordpress.org site and drop-down menu items that affected Chromium on a AlmaLinux distro. Google Chrome worked fine as well as Firefox. On a Ubuntu and Debian distros (Linux), Chromium work just fine, as was with Windows 10. Long story shorter, eventually, the AlmaLinux distro received an update with a new Chromium build that fixed the issue with Drop-down menus.

That said, it doesn’t seem likely for a Windows platform since Google Chrome should be automatically updated and is usually ahead (stable release) of Edge, Opera and other browsers that share the Chromium engine or, maybe you are using cutting edge/beta releases/builds but, as previously mentioned, anything is possible.

If you want to supply the Web URL, I suggest you add that to your BuddyPress Profile, there is a field specific for this purpose (Web URL). That way, you can remove it later, if you don’t want the URL to remain public. I can then either confirm or deny whether I see something unusual while visiting a profile area with Google Chrome.

Next up are a couple of housekeeping items, that you require your attention, of which should not be related to the issue you reported in this thread.

(1) BuddyPress 12.4.1 is not compatible with WordPress 6.7.x. The effect is that your server error log(s) are filling up with an error notice, e.g.:

Notice: Function _load_textdomain_just_in_time was called <strong>incorrectly</strong>.
Translation loading for the <code>buddypress</code> domain was triggered too early. This is
usually an indicator for some code in the plugin or theme running too early. Translations
should be loaded at the <code>init</code> action or later. Please see <a
href="https://developer.wordpress.org/advanced-administration/debug/debug
-wordpress/">Debugging in WordPress</a> for more information. (This message was added in
version 6.7.0.) in /var/www/html/wp_test/wp-includes/functions.php on line 6114

The solution is to either to roll back WordPress to version 6.6.2 or upgrade BuddyPress to version 14.3.3.

(2) BuddyPress 12.4.1 is missing 2 security patches, if you are going to continue to use the BuddyPress 12.x branch, it is recommended that you upgrade to BuddyPress 12.5.2, see If you are using BP 12.x and can’t upgrade to 14.2.1, and apply (1), accordingly.

Hello again 🙂

This might start to make sense then!

First, when you translate something within the code itself (not using a translation plugin and po/mo file) it will for the most part be overridden whenever you update your WordPress / plugins that are translated. So, this might be why it doesn’t work now after the update.

I personally use a combination of LocoTranslate and TranslatePress. This is because BuddyPress activity is updated the way it is and for that reason LocoTranslate itself is not able to translate the dynamic content (like when activity updates – without the page doing so) – this TranslatePress supports.

So, for the BuddyPress content that can’t be translated correctly using LocoTranslate, I use the TranslatePress for those. Both plugins are free to use, and it doesn’t require you to purchase any expensive addons.

It’s important that you pick the right placement for your translation-files (custom, author, system). If they’re not in the right place the translation might not show up on the front-end. Also make sure you setup the settings within the LocoTranslate plugin not to override your translated files upon updating WordPress: Loco Translate > Settings > File system access > Modification of installed files & Editing of POT (template) files must be set to Disallow.

For the display name, this should be the default value it sorts by. Mine by default sorts by display name. When you go to Users > Profile Fields – you can edit the different settings from within there with the names and what is mandatory/not mandatory.

For the sorting part (or other features in the future) if it still causes issues, maybe a snippet code using a plugin like WPCode Lite might be a better solution rather than going into the code and edit it from there. In this way it will not get affected in most cases when you update WordPress, plugins and theme.

Maybe some of this can help you – if not – then feel free to keep me updated. 🙂

Sounds weird, since I’m also using the user fields (xProfile fields) – my site is translated into Danish, but my site-admin back-end it set to English. This is due to it being easier to find items in the menu when troubleshooting (hate when settings and so on is translated lol).

So seems weird to me if the translation part of it is causing the issue, since I’m also using it, but not having the same issue?

Hope you find a solution and it ends up working for you though! 🙂

It sounds like you’ve done a lot of the right things already. Here are a few additional steps you might try:

Check for Conflicting Plugins: Ensure no other plugins are overriding BuddyPress translations.
Clear Caches: Clear any caches that might be affecting the translation display.
Verify Translation File: Double-check that the .po file has the correct translation for “Name” and is properly saved.
Theme Conflict: Make sure your theme isn’t overriding the BuddyPress translations.
If the issue persists, you might want to reach out to the BuddyPress support community for more specific advice.

Hi @capexpe

I believe we’ve improved this part actually in 14.0, see https://buddypress.trac.wordpress.org/changeset/13936.

You shouldn’t put your custom language into /wp-content/languages/plugins because it will be replaced by the official translation after it has been updated by the Polyglots team.

Custom language files for BuddyPress should be in one of the locations we are looking for:
– /wp-content/languages/plugins/buddypress
– /wp-content/languages/buddypress
– /wp-content/languages

More informations are available from this documentation page: https://github.com/buddypress/buddypress/blob/master/docs/user/advanced/texts.md

I’ve just tested renaming “Groupes” with “Expé” in custom fr_FR translation files I’ve included in the /wp-content/languages/plugins/buddypress folder:
– /wp-content/languages/plugins/buddypress/buddypress-fr_FR.po
– /wp-content/languages/plugins/buddypress/buddypress-fr_FR.mo

And it’s behaving the way it should, see screenshot below:

@adjunkten I have no idea how Loco translate deals with translation files, but if you put their generated alternative language files at one of the three locations I listed above making sure they respect the WordPress default way of naming these, it should also fix your issue. Here’s the translated message for the “members-only” login page.

Hello BP-developers,

I also want to thank you for maintaining and developing Buddypress!
We have been using it for almost 10 years and never had issues when updating to a new version.

Passing to 14.0.0 was different. Thanks for the BP Classic that fixes many issues for us but as Lars we still cannot have the translation working yet.

We used to use the buddypress-fr_FR.mo file to change the by default translation of “groupe” (French word for group) in “Expé” for expédition on our site. But changing the buddypress-fr_FR and re-uploading to wp-content/languages/plugins as we were used to do at each update, does not seem to work.

Here is a link to our website with both public and registered users : where the blue button close to the title should be “Créer une Expé” instead of “Créer un groupe” and the other blue buttons next to each group “Rejoindre l’Expé” instead of “Rejoindre le groupe”.

Thanks for your help.

WP 6.6.1
BP 14.0.0
Theme : a minimally customed child version of Boss

@neighborhoodnurturers0 These strings will be translated with the help of Loco Translation plugin.
https://prnt.sc/DXGWPwAhVAIm

Thanks! 🙂

What I can see is that the group menu option that you picked is pointing some odd post_type=buddypress url, which is wrong, it should simply point to https://yoursite.com/groups (or your translation of the word groups.

You can either try editing that menu item, or create a custom link to that URL. (yoursite,com should be your own site address).

Is that a psychology site you have there?

You can change these using translation. Basically, create your own translation file for you country, which translates Friend into Contact, everywhere it appears.

@abdallahgh You can change or rename Group to Sections using translation; try the loco translate plugin. https://codex.buddypress.org/getting-started/customizing/customizing-labels-messages-and-urls/

Hi @shemakeswebsites,

12.0.0 brings URL slugs customization, that’s a big improvement to have meaningful URLs for non English communities.

These communities are using different words for things like Activity, groups etc.. They can do so thanks to the l10n feature of WordPress. So a good way to reach your goal is to use a custom translation file. And I believe it’s the best way to do so, because the page title or labels won’t be enough to really reword all places where we use groups.

You can try to put your custom translation file into wp-content/languages/buddypress/buddypress-xx_XX.mo replacing the xx_XX with your locale maybe it’s even working with en_US.