BuddyPress.org

i know i’m a bit late on that topic but i do agree that it should almost be a core feature to be able to switch language file.

I’m not talking about having the content translation feature, but the front/back end stuff, basically anything showing on the localization file.

So a user can decide his default language (among the available ones) for the site.

It only makes sense: MU for WordPress MU, for BuddyPress/WordPress MU, for MUlti users, for MUlti blogs and for MUlti language.

I’ve done some research and could not find a black/white solution. it’s seems to be in the grey zone at the moment.

Has anybody been able to achieve this yet?

cheers

Shakera-

If I understand your issue, you are having problems localizing BuddyPress into Cyrillic.

Please check this BuddyPress codex page first as there is a translation of BP for Bulgarian.

If you are making your own translation, then you should read the Translating WordPress codex page.

I also have similar issue. In my case, some Site Wide Activities phrases are still in English, even If i’ve updated the translated version.

I use PoEdit for translations, I’ve translated WP/bbPress/WPMU and never faced such issue. How could be this problem resolved?

Regards,

@JohnJamesJacoby: Is there any possibility to override the bp slugs like members, groups etc.. so they would still work? Because since the problem is pinpointed to that single qTranslated module, I’m having problems with the multi-translations …

or is the progress in the latest svn/trunks ?

Socialpreneur, thanks for the note. I updated the Codex page to reflect this; when I wrote the tutorial the automatic upgrade wasn’t an option.

@Kunal17

Is the bp-custom.php file something that I download or create?

You create it yourself, and place it in “/wp-content/plugins”.

What is the ‘mysite’ language translation as defined in the tutorial?

That is a sample definition that I used for the tutorial — you can use whatever you want. Just make it a label that makes sense to you and your site.

Still wondering about the command to convert .po to .mo. How is that run and from where?

Running that command requires that your web server have basic GNU gettext support — if you don’t know if it’s supported, ask your host (it’s pretty standard on most Linux servers).

Running this command also requires command line access to your server via a program like PuTTY (Windows), Terminal.app (Mac), or from inside an FTP program and requires that your server support “msgfmt”. If you do not know how to run commands like this, or don’t have command line access to your server, please see Translating WordPress for other software options for converting language files (like Poedit).

@Craig dean

Also not understanding the conversion of the po. to the mo. using the run command. Is it a ftp app command. Just not sure.

See me answer above. I also updated the Codex page with these notes.

@Mstoppay

my bp-custom.php file wasn’t loading. Once I moved it out of the buddypress folder and into the plugins folder the language change worked… anyone know why that is?

Yes, as of BuddyPress 1.0 the “bp-custom.php” should be placed in the “plugins” folder instead of inside the BuddyPress directory, as noted by Andy in this thread. Thanks for the reminder — I updated the Codex page to note the correct location.

Note also that if you use the “Automatic upgrade” option to update your BuddyPress install, make sure to backup your language files first since they could be removed during the upgrade process (see this thread).

Ok, I see now that I have to create the bp-custom.php file myself.

Still do not know how to run the command to create a .mo file. Do I use cpanel or ftp software for this? Would poEdit, create a .mo file that I can just upload? (Thanks Gilbertc for the above clarification, I’ll definitely look into PoEdit for the long run but currently I only need ‘blog’ to be ‘news’ everywhere )

Also, what is the ‘mysite’ language translation as defined in the tutorial?

Thanks.

The Northern Smurfs called a certain object a “bottle smurfer”, while the Southern Smurfs called it a “smurf opener”.

Language customization is subtly different from language translation but both share similar localization processes, using the same tools.

( https://codex.wordpress.org/Localizing_WordPress & https://codex.wordpress.org/Translating_WordPress. Google for more)

Of course, as Lance accurately stated, using dedicated software is overkill if your intention is to change a small set of frequently used words site-wide (turning “groups” into “teams”, “members” into “players” and so on).

In which case I’d go for the “slugs” method, as suggested by Andy Peatling, rather than tinker with the language files.

As always, scale matters.

If you are interested in managing one or more custom language versions, or if you find yourself willing to change more stuff as it comes, I strongly advise you to consider the software option.

It’s a personal investment which requires you to do your homework and learn to organize your projects accordingly but the learning curve isn’t that steep, and it will guarantee you less white hair in the long run.

PoEdit is a good choice, giving you the full benefit of a precious asset: translation memory.

Once installed on your PC, it creates and maintains databases for each translation project – its original purpose. A feature that can be put to good use for language customization.

Its rather straightforward user interface lets you focus on the language changes you want to make, with a built in “search” feature to locate words or expressions.

There is no built in “find & replace” feature as software translation is primarily based on strings and not single word occurrences, which can be located in different strings with different contextual meanings.

If you really want to batch-replace words, you can achieve this using a text editor like Notepad++. Proceed with extreme caution, though: unexpected replacements using this method are frequent, that you can’t always undo except by hand, which defeats the purpose of the whole process.

Since language files are usually modified with each new release (added strings, modified strings, different string locations…), you’re also better off handling language file updates that way, keeping the language customization logic independent from the file itself, in PoEdit’s TM (translation memory) safe at home on your PC.

When upgrading BP, it will spare you tedious language files comparison and copy-paste hell in a river of strings, and will do the job with more accuracy.

A single mistake in a modified language file can generate cryptic errors which you don’t want to start tracking and debugging in 3,000 + strings distributed in multiple language files.

PoEdit gives you the ability to manage multiple language files using a single TM database (or as many as you wish).

This is especially useful when you know that the number of language files to be handled gets larger as your platform grows (plugins, themes and templates sometimes have their own – and should).

Using PoEdit will give you the required semantic homogeneity among all language files belonging to the same project, seamlessly.

This is where translators make significant productivity gains. And so can you.

What is more, the software approach scales nicely:

If you want to leverage your community’s knowledge for language customization – Klingon, Smurf, slang, professional jargon, secret dialect, whatever… – you may want to install Pootle

( http://translate.sourceforge.net/wiki/ ), an open source collaborative translation platform that does the same as PoEdit, on your server, and upload the languages files for collective customization – the scenario is yours.

I’m just finishing a translation based on BP 1.0, coming up soon.

Wpviet23-

Thank you for your contribution.

Have you checked the BuddyPress Language Translations Codex pages here? https://codex.buddypress.org/translations/

There is another Vietnamese translation of BuddyPress.

I’m experiencing the same problem.

It’s with a few strings that are translated in the PO file, but do not appear correct.

“created the group”

“updated the”

“created a new blog:”

“wrote a new blog post:”

.. and may be more I can not catch at this moment.

These strings are from the site-wire activity and appear in the INDEX , as well in other pages.. and.. they are pretty key to the user experience.. so it will be nice if there’s a solution on the horizon

Do I need to translate WPMU first ?

Look in the link that DJPaul provided. There is a WordPress translation of Arabic already. I’m not sure what additional work you’d have to do for WPMU. Most likely translation of some of the admin pages. But, I’m not a localization expert.

What will be different because Arabic is RTL language ?

As long as the themes that Arabic users are using properly reference some type of right to left CSS file, then this should not be an issue. Look at rtl.css to see how that works.

Also, look at this relevant BuddyPress thread: https://buddypress.org/forums/topic.php?id=245

Check out https://codex.buddypress.org/translations/ for starters – there’s a link taking you over to the main WordPress site with further details.

Hey, I translated BuddyPress yesterday!

You can find my translation here: https://codex.buddypress.org/translations/greek-ellinika-el_gr/

I hope you like it, because I was exhausted after the hours I spent working on it.

P.S. Ki egw Ellhnas eimai.

from the WP org codex:

Using Localizations

In order to localize your installation of wordpress, create a directory named languages inside of wp-includes, if it does not already exist. Then grab the appropriate localization files from the Subversion Repository as described above. The main .mo file for the language should go inside the languages directory. Set WPLANG inside of wp-config.php to your chosen language. For example, if you wanted to use french, you would have:

define (‘WPLANG’, ‘fr_FR’);

i’ve this configuration on my MU+BP and all works fine.

The WordPress MU language file should be in /wp-includes/languages/ and you can change the language in your admin section of your wpmu install.

The BuddyPress language file (buddypress-xx_XX.mo) should be in /wp-content/plugins/buddypress/bb-languages/ the xx_XX should be the same as on the file in /wp-includes/languages/ since BP gets the language setting from WPMU…

You don\’t have to edit anything in your wp-config.php file!

All of this is for WordPress MU 2.7.1 and BuddyPress 1.0. I don’t know how it is with older versions…

HTH

Regards,

RuneG

Kogigr now you have buddypress-el_GR.po and buddypress-el_GR.mo in /wp-content/plugins/buddypress/bp-languages/ right?

in wp-config.php insert on line #77

define (\’WPLANG\’, \’el_GR\’);

and save…

I think this should resolve (BP side), however, looks for the translation of MU in greek.

@Kogigr;

AFAIK, you have to use the same language in WPMU as in BuddyPress. BuddyPress gets the language setting from WPMU. There is some info about the greek WPMU translation here, but I don’t read greek, so it’s not necessarily the info you need

But you’ve named the file(s) right, you only need the .mo file in your bp-languages folder.

So basically you need to use the same language in WPMU that you want to use in BP. So get the greek WPMU translation, upload it to you WPMU install, and change the language in you admin section…

HTH

Regards,

RuneG