BuddyPress.org

Hi @presis_carsten,

could effectively be a translation issue. Why ?
For translation, we (i translate BP into french) mostly use HTML entities for special characters.
In brief, accented letters in HTML. For instance, if you want to type één you would type één.

The only part this should never be used is in the messages, as gettext doesn’t handle mail content.

And so far i see, the dutch phrase contains such an accented letter (beëindigen)

buddypress-nl_NL is here. And you’re free to modify it on Glotpress and of course in your copy, with poEdit or similar.

I checked WP & BP’s nl_NL version on Glotpress and didn’t find the phrase you mention. Could it be you use a very old translation or some notification plugin ?

buddypress/bp-languages/buddypress.pot
Don’t use DW to read, modify or save a translation. Use a text editor (not word) like notepad or notepad++

The NL translation is on Glotpress and the translation you need to put on your server is buddypress-nl_NL.mo

This is a compiled file used by gettext. You cannot read or modify it. If you want to do so, see poEdit.
https://translate.wordpress.org/projects/buddypress/dev/nl/default

Languages and Translations

You can find many other related topics if you search a little on the forum.

ok, supposing you did a translation file (even if you use english by default) to test the above solution and assuming it hasn’t work, let’s try the hard way.

Add this to functions.php, it will force gettext to translate the string.

function bpfr_force_translation( $translated, $original_text, $domain ) {
		
	if ( 'buddypress' !== $domain )  
	return $translated; 
	
	switch ( $original_text ) {
		
		case 'Registering for this site is easy, just fill in the fields below and we'll get a new account set up for you in no time.':
		return 'Join PushkarGuide.com - share your experience, thoughts about this pretty town Pushkar (INDIA).';
		
		default:
		return $translated;
	}
}
add_filter( 'gettext', 'bpfr_force_translation', 10, 3 );

If it doesn’t work i have no other solution to propose.

there are only two files […] which need to be modified.

False.

If you use the old BP-default theme, you only modify a copy of bp-themes/bp-default/registration/register.php placed in your child-theme

If you use any other theme, you modify only bp-legacy/buddypress/members/register.php
placed in the child /your-child-theme/buddypress/members/register.php

The one or the other, but not both. And don’t forget that you should never modify core files, as your work will be lost at the next BP update. That’s why child-theme exist and is so important for customization.

If this change doesn’t work (but it should), you have to try something different.

Create a language file containing only the mentionned string.
Read here.

Do you already use a language file ? §Is your site in english ? If not indicate the used language.
And gave your plugin list and theme name. It could be you have somewhere a conflict with ajax who block something on the registration page.

@micasuh _e( $text ) will search for the translation of $text and print it to screen. If a translation doesn’t exist, it’ll print $text. You might also come across __( $text ). This does the same but it returns instead of printing.

So yeah, these functions are definitely related to translating.

@micasuh the .mo file is most likely being loaded from your theme’s functions.php file. Alternatively, it may be loaded from a plugin. Or, maybe even bp-custom.php (if you have one of those).

Look for something such as the following and try removing it to see if it resolves the issue:

if ( file_exists( WP_LANG_DIR . '/buddypress-en_US.mo' ) ) {
    load_textdomain( 'buddypress', WP_LANG_DIR . '/buddypress-en_US.mo' );
}

If it doesn’t resolve the problem then we know your translation file is OK.

If you still believe the issue is a virus in your database then you could try rolling back. Do you keep database backups? But, to be honest, I’m more inclined to think this is occurring as a result of some rogue theme or plugin code.

Hi @rutzki,

are you responding to yourself ?
i dont find, where i have put in the german translation in the po file.
😀

If you use poEdit, you can create your own copy of de_DE.po directly from the source on your local buddypress copy.

The .po file header information necessary to get all translatable strings:

msgid ""
msgstr ""
"PO-Revision-Date: 2014-08-06 02:16+0100\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Poedit 1.5.7\n"
"Project-Id-Version: BuddyPress 2.0.2\n"
"POT-Creation-Date: \n"
"Last-Translator: \n"
"Language-Team: \n"
"Language: de\n"
"X-Poedit-SourceCharset: UTF-8\n"
"X-Poedit-Basepath: .\n"
"X-Poedit-KeywordsList: __;_e;__ngettext:1,2;_n:1,2;__ngettext_noop:1,2;"
"_n_noop:1,2;_x:1,2c;_nx:4c,1,2;_nx_noop:4c,1,2;_ex:1,2c;esc_attr__;"
"esc_attr_e;esc_attr_x:1,2c;esc_html__;esc_html_e;esc_html_x:1,2c\n"
"X-Poedit-SearchPath-0: ..\n"

https://codex.buddypress.org/developer/translations/

Hi,

i have the same problem, that notification etc. is not translated and i dont find, where i have put in the german translation in the po file.

Can u upload your file, or copy and paste the few lines here?

cheers,
Patrick

@henrywright
Nothing in /wp-content/languages is touched during an upgrade just as a child theme also is not touched during a parent theme upgrade. Whomever conveyed using a language file is bad practice for translation is terribly misinformed. You are right by not agreeing Henry. The fact is this particular files directory has to be created by the admin in cpanel, ftp, or whatever they use for their server and is not replaced nor overwritten with core upgrades.

see here the answer from @shanebp.
He listed all notification instance in the po file

Maybe you have an idea what that could be?

You give the answer: once translated to German and once not.
Guess if something is not translated, you can’t see it. 😉

It could also to be that if you added the header infos to your po, that your translation plugin found immediatly some forgotten strings or new ones and added them, so you saw those unstranslated strings.

I suggest you to update the po file from the source using poEdit locally, for example from within bp-languages/buddypress-de_DE.po, to ensure that you have all 1476 strings of BP 2.0.2

Once done, you remove the po/mo from bp-languages and put them into wp-content/languages/plugins/

Hallo @findolfin,

Effectively, many peoples are claming about de_DE translation issue.

As the german translation for BuddyPress awaible on GlotPress is only translated to 52% (58% for 1.9!), the only other source to get po/mo files is deckerweb who provides 2 versions, Du and Sie version for BP 1.9 (latest in january 2014)

I downloaded the Sie version and opened the po. This file doesn’t contain any header information. So i guess gettext can’t read it correctly. And if you use this file it could be at the origin of your issue.

Here are the whole header informations, including the whole keywords list like _x which you need to add into your german buddypress-de_DE.po
Open the file with a text editor (notepad++ or similar) and paste it at the beginning of the file.

Once done, you must open the modified po with poEdit and save it again, to generate the mo file which is in fact the compiled format of the translation used by gettext.

msgid ""
msgstr ""
"PO-Revision-Date: 2014-08-08 09:45+0100\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Poedit 1.5.7\n"
"Project-Id-Version: BuddyPress 2.0.2\n"
"POT-Creation-Date: \n"
"Last-Translator: \n"
"Language-Team: \n"
"Language: de\n"
"X-Poedit-SourceCharset: UTF-8\n"
"X-Poedit-Basepath: .\n"
"X-Poedit-KeywordsList: __;_e;__ngettext:1,2;_n:1,2;__ngettext_noop:1,2;"
"_n_noop:1,2;_x:1,2c;_nx:4c,1,2;_nx_noop:4c,1,2;_ex:1,2c;esc_attr__;"
"esc_attr_e;esc_attr_x:1,2c;esc_html__;esc_html_e;esc_html_x:1,2c\n"
"X-Poedit-SearchPath-0: ..\n"

Check this first and if it does not work, give feedback. And also theme name in case of. 😉

Please read here:

BuddyPress in Your Language

https://codex.buddypress.org/developer/translations/

Before installing any plugin, consider this translation into persian from the official translation repo for WP/BP/bbP
https://translate.wordpress.org/projects/buddypress/dev/fa/default

You can also contribute to this persian translation. Everithing to do so is explained on Goltpress.

Hi @noyzen,

if you only updated BuddyPress, it’s possible that the translation file contains an error.

Check your .po file for any strings looking like this one

https://buddypress.trac.wordpress.org/browser/tags/2.0.1/bp-languages/buddypress.pot#L3464

Example: Groups <span class=\"%s\">%s</span> or Members <span class=\"%s\">%s</span>
If correctly translated, perhaps is something wrong in your theme or child theme or even a plugin.
in this case, you should check the file indicated above the string to translate.
%s is very important to stay in the translation and in the original file to get the count

read:
https://buddypress.org/support/topic/translation-fails-only-at-sitewide-activity/

it’s not the theme
it’s not the translation
seems to be somthing unstable with bp-loader
sometimes i have things translated, sometimes not ! Stuning ! 👿

@shanebp,
forcing a translation is not the best solution, even if it is a solution.
Mine by hacking the core file is not better, as we loose it at the next update.
Your function won’t be loosed, but it should be used by caution, as gettext pass a second time on ALL strings. It’s not dramatical to force the translation for one string, but what will happen if someone use this trick for 20, 50 or more strings ? Performance trouble !

I’ll track this further before opening a ticket.

https://codex.wordpress.org/Plugin_API/Filter_Reference/gettext
https://codex.wordpress.org/Plugin_API/Filter_Reference/gettext_with_context

@levre Something got lost in translation, not quite clear what you mean. What I’m getting is that you have a WP Multisite installation and you have BuddyPress network-activated. I gather that you want separate instances of BuddyPress in that multisite installation. That is not possible at this time except through plugins see https://buddypress.trac.wordpress.org/ticket/4732