BuddyPress.org

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.

Yeah I know that. I’m currently using fillters and hooks etc to override so I can put them into my bp-custom.php. A nice plugin so I can use the WordPress UI to change the messages would be better.

I\’d like to know as well. Especially that \”Dear User\” annoys the hell out of me. \”User\” sounds like \”drug user\” or \”abuser\” or \”you\’re not a friend, you\’re just a user!\”.

The email is sent out after the new member has already given his name. There should be a way to just include the full name or first name in the welcome email. It\’s standard practice.

BTW, Socialpreneur, do you mean this thread? It’s not very helpful.

> Also when I go to add a widget to a sidebar when that widget is already used by another sidebar, WordPress does not give you the option to add it again. How do you include the widget on two sidebars at the same time.

You’d have to create a duplicate the widget, and depending on how it is written and what it does, it may or may not require further modification.

Lo.

> Why is it when I add a page to my WordPress site, it doesn’t show up in my BuddyPress navigation?

Because that’s just the way the default home theme is written. The items listed on that menu aren’t ‘Pages’ in the WordPress sense, anyway, so it makes little sense for the default, out-the-box BuddyPress theme to do that.

The bit of code you’d need to change (or to add in your custom/duplicate theme) is in header.php. Where you see:

<ul id="nav">

Add this underneath:

<?php wp_list_pages('title_li=<h2>Pages</h2>' ); ?>

Documentation for that function is at https://codex.wordpress.org/wp_list_pages

Remember also, that the navigation in header.php has NOTHING to do with WordPress pages. They are hard coded to the BuddyPress predetermined hi-jacked URLs.

Like Andy said, the “Home” theme is really intended only for the “Home Blog” or the main blog that your website is responsible for. It’s intent is similar to a “portal” page for those of you familiar with phpNuke, vBulletin, etc…

Think of wordpress.com…

There’s a page there that shows all sorts of SITE WIDE content. Then you can drill down into users blogs, and see their specific blogs and themes. Exact same idea with the home theme.

Using the Home theme as a user blog will result in errors, because the “Members” and “Groups” and “Blogs” links don\’t exist under sub domains/directories.

For a “seamless” type of interaction, you will want to make a duplicate of your “Home” theme, call it “User”, edit the style.css to give it a new name, delete home.php, and edit the header.php file to use$bp->root_domain in place of get_option('home')

This is what I did for http://delsolownersclub.com. You’ll notice that the user blogs look just like the home blog.

This makes sense, because like you said above, the Member Themes aren’t real WordPress themes; BuddyPress just muscles itself in and takes over the place. And as long as the member theme functions.php registers a sidebar with the same name, WP doesn’t know the difference and loads it up.

It’s posts like this, Burt, that lead me to believe that there’s a whole lot of progress that will be made in modifying the Member Theme area.

Good post, A+ for the day.

Since this is a BuddyPress forum, I’ll assume you’re talking about the Buddypress widget “Recent Blog Posts” and not the WordPress widget “Recent Posts”

You need to look in bp-blogs-widgets.php for the code. But, do not change the code within that file. It is a core BuddyPress file and any changes you make will be lost the next time you upgrade. Instead, make a copy of that file and create your own custom widget.

Derosion-

Although the WordPress widget API clearly advises developers not to use the widget functions starting with wp_, there is an issue with localization of Widgets in BuddyPress if the register_sidebar_widget() is used.

If you’re not planning on distributing your custom components or widgets, then you can code them with the register_sidebar_widget() function call instead of wp_register_sidebar_widget(). However, if you plan to make your custom component or widget available to the community, you should use wp_register_sidebar_widget() at this time.

See Changeset 1244 for more information.

Mariahneu-

First of all, we need some additional information:

1. Which version of WordPress Mu are you running?
2. From where (provide link) did you download WPMU?
3. Which version of BuddyPress are you running?
4. Did you open any of the BuddyPress files?
5. Did you alter any of the BuddyPress files?

After disabling bphome and just running on the classic wordpress theme whenever I visit any of the pages that involve BP scripts I get the error.

A classic WordPress theme will not work with BuddyPress. There is BP-specific code within BP themes and BP theme folders. The question is, what happens when you use the standard BP themes that come with BuddyPress?

Also, after switching to the standard BP themes, and if you’re still having issues, then you should set PHP to run on version 5 instead of 4 and see what happens.

Could you just add <?php wp_list_pages(); ?> to the header.php file?

https://codex.wordpress.org/wp_list_pages

Okay, I’ve reread this thread for the second time. You state that:

The problem must be with the data; since a fresh install works perfectly and after the data gets imported, I get the nasty 404 bug.

Andy’s answer is:

This is normal with WPMU, you are not going to be able to transfer over blog tables as there are all sorts of URL settings in the DB.

I have a few questions based on this interchange:

1. Which version of MySQL are you (is your host) running?
2. Have you tried repairing the DB tables before reimport?
3. Are you moving your data between different domains?

Since WPMU 2.7.1 + BuddyPress 1.0 + standard themes work fine with a new, empty MySQL DB, the issue is, as you state, with the data. Either you have data corruption, indices that need reindexing, or hardcoded links within the tables that are causing the 404s.

If the domain mapping is not identical to the hardcoded links in your WPMU tables, you will have issues.

So, here’s what I’d suggest:

1. Backup your data again
2. Then, repair/reindex
3. Then, if your domain mapping is not identical, follow these instructions keeping in mind that these articles are for WP and not WPMU. You’ll have to adjust accordingly:

   • https://codex.wordpress.org/Changing_The_Site_URL
   • https://codex.wordpress.org/Moving_WordPress

Ilya,

I’m working on a project where i must integrate WPMU, buddypress and bbpress all together.

http://terafriu.com/forum/ is the forum page. I have modified the kakumei theme that came with bbpress. Changing the header and footer will go a long way. But it ultimatly depends on what you are trying to acheive. For the time being you’ll either have to create/modify your own.

Keep in mind that Buddypress is a fairly new application and we should be gratefull to get such an application for free! When the important stuff like bug fixes etc are resolved we will see tons of themes, just like WordPress.

Kitwit, I think you’re a little confused… It’s working exactly like it should.

The directory pages are the pages that show the A-Z options on the top. The profiles are just profiles. They reside in members/username, but viewing a profile isn’t the same as viewing a directory of many users.

When you turn on Extended Profiles, it will totally ignore any of the admin area WordPress profile fields, and wait for you to create your own profile groups and fields. Extended Profile information can then be edited through BuddyPress on the front end of your profile area, exactly like you can do here.

When you turn off Extended Profiles, BuddyPress will fall back on the WordPressMU user information found in the admin area (if you have the BuddyPress setting turned on for it to do so.)

Yes… I’ve posted this elsewhere (so please excuse me if I sound like a broken record) but it would be great if groups could share different kinds of content… photos (coming this fall?) videos, files and wiki’s (aka group-editable page/post).

Maybe once we are able to share blog posts in groups (as Andy mentions above)… wiki functionality could be wedged into groups simply by installing WordPress Wiki. Create a blog post, make it wiki-enabled and then share it with the group? Just a thought. Not sure if that would work or not.

Ilya-

I understand!

It is actually an issue with the way WordPress, or more precisely, Automattic has created the registration script. The script allows for spaces but then it can cause login problems.

Unfortunately, that issue needs to be addressed at a different level than BuddyPress. Since all of the moderators donate our time on these boards (i.e. we do not work for Automattic), we have no control over this issue.

As I said, I had the exact same issue and the only solution I had was to create a new username.

I would consider using AWPCP “another wordpress classifieds plugin”

google it, it could easily be used for your purpose

and It works well on wpmu with buddypress

Kunal17-

I am running BuddyPress 1.0, WP 2.7.

Are you running WP 2.7, as in single-user WordPress?

If so, that is your issue. BuddyPress only runs on WPMU (multi-user version). Also, you need to be running WPMU 2.7.1 and not 2.7.

I thought wordpress doesn’t allow spaces in user IDs…

Well, we can’t see your profile, but you can… at least you can use it.

Ilya-

If you are asking about bbPress themes in general, then Google and you’ll see that there are a number of themes available for bbPress.

If you’re asking about specially customized BuddyPress-friendly bbPress themes, then the answer is as jjj points out above. With v1.0 of BuddyPress just released, theme designers are more than likely working hard at creating new, custom themes.

Once bbPress is publicly released in a stable version, I would imagine that some theme designers will create BuddyPress-friendly bbPress themes as well.

Remember, these are open source projects. The vast majority of the human resources poured into the community are done so for free. WordPress, BuddyPress, and bbPress all come with themes by default. It is up to the community to take those basic themes and create more flexible, powerful designs.