Project

General

Profile

Actions

Feature #271

closed

Add a User

Added by Sarah Morgano almost 14 years ago. Updated over 13 years ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
WordPress (misc)
Target version:
Start date:
2010-07-19
Due date:
% Done:

0%

Estimated time:
Deployment actions:

Description

When you add a user to a blog, the page reads as if non-commons members can be added, which they cannot. It also says that "new users will then be sent an email with a randomly generated password and login link" which is also not the case. Is it possible to change the verbiage on this page to reflect that it's for commons members only and that after members select the activation link they will automatically have access to the blog upon signing into the commons?

Actions #1

Updated by Matt Gold almost 14 years ago

  • Status changed from New to Assigned
  • Assignee set to Chris Stein
  • Target version set to 1.0.1

Hi Chris,

Do you have time to handle this? I know that time is getting tight for you right now, so no worries if not. But I think that Sarah's request makes a lot of sense. A short explanation that only CUNY Commons users can be added to blogs is needed. This page can be found in the WordPress dashboard under Users > Add New

Matt

Actions #2

Updated by Boone Gorges almost 14 years ago

Chris - I believe this is at /wp-admin/user-new.php. You might want to look into setting up a custom language file for the Commons. The process for BuddyPress is listed here: http://codex.buddypress.org/how-to-guides/customizing-labels-messages-and-urls/. It'll be similar for WordPress more generally, but with a different text domain. Alternatively you might find a do_action on the Dashboard page that allows you to hook in a custom message, but I wouldn't bet on it given the way WP Dashboard pages are coded.

Actions #3

Updated by Chris Stein almost 14 years ago

  • Status changed from Assigned to Reporter Feedback

Boone, I looked into the custom language and it's an interesting option. The po and mo files are a bit confusing at first. The main issue with the approach you outlined is that buddypress is good about defining a domain for all of the text it makes available for translation. They put the 'buddypress' domain on everything, for example
_e('Enable discussion forum', 'buddypress')

Wordpress hasn't done that
__( 'You can add new users to your blog in two ways:' )

So I had to modify the core WP code for user-new.php but I tried adding a domain to them for that page instead of just changing the text in user-new.php, ie:
__( 'You can add new users to your blog in two ways:', 'wordpress' )

Then I added a .mo and .po file in wp-content/languages (had to create the languages folder)

Then in wp-content/plugins/bp-custom.php I added the code to load the .mo file for the wordpress text domain.

Does this seem like a good way to do this kind of thing going forward? And are these good places for the files?

Actions #4

Updated by Boone Gorges almost 14 years ago

This sounds close, Chris. What you did would be perfect if this was a BuddyPress string. But it might have to go a little differently for WordPress, so that we can avoid changing core files and remain future-friendly. (I probably should have been more clear about this in my original suggestion above - sorry about that.)

Your placement of the files sounds perfect. It's important that it's inside of wp-content so that it doesn't get overwritten with upgrades.

The reason why Wordpress strings don't have a text domain is because WP is the base program being run when PHP loads the site. It should be possible to make a language file for WP in the same vein as foreign language ones. See for example http://codex.wordpress.org/Translating_WordPress. Then we would set the language in wp-config.php, as per http://codex.wordpress.org/Installing_WordPress_in_Your_Language. Here is the POT for our version of MU: http://svn.automattic.com/wordpress-i18n/pot/mu/tags/2.9.2/wordpress.pot

Would you mind taking a look at this process? Now that you've got the translation tools installed, it should be pretty straightforward. And once we have both a BuddyPress and a WordPress .po/.mo system in place, we'll be able to change wording sitewide at will. That'll be really great.

Actions #5

Updated by Boone Gorges almost 14 years ago

  • Status changed from Reporter Feedback to Assigned
Actions #6

Updated by Chris Stein almost 14 years ago

  • Status changed from Assigned to Reporter Feedback

OK, I got it to work. There are a couple small gotchas I should mention that gave me some fits. The big one is that, as far as I can tell, in order for the changes to take place you need two things:
1. .mo (and maybe .po) files that have one of the recognized language abbreviations in front
2. Change the settings in Dashboard to the language you're using (Settings->General then Blog language dropdown).

Number one is what took me the longest to figure out. I had named my files commons.po and then changed the wp-config but nothing happened. Read about changing the Dashboard settings but the language wouldn't show up even with making sure to define the language correctly in the .po comments.

When I changed the name to en_CAC then a second English shows up in the language dropdown in General->Settings. I don't know if there is away around this to call it something other than English but that seemed the best option rather than some other language.

There is another place to set the language in the dashboard Site Admin -> Options then scroll down to default language. I forgot to mention this in the commit message.

I've played around with this a bit and basically General->Settings controls the current blog, while Site Admin -> Options controls general site settings.

The problem for us is that the blog settings override the site language settings. Also changing the site settings doesn't effect any change in the existing blogs. This means that to see the changes we've made to the language file all of the existing blog users would have to go into their blog's dashboard and change the language to the second English. (all new blogs will get the new default language).

The only other option (besides changing core files) is to somehow do an update to the DB to change people's language for them.

This stuff also raises the question of whether we are going to allow people to make their blogs in languages other than English? That would require making similar changes to that po/mo file as we did for the English one.

A final weird sidenote is that you don't seem to have to change wp-config and do the
define ('WPLANG', 'en_CAC');
thing. It seems to work with or with out this.

Actions #7

Updated by Boone Gorges over 13 years ago

  • Status changed from Reporter Feedback to Resolved

This one got snuck into 1.0 somehow :)

Actions #8

Updated by Boone Gorges over 13 years ago

  • Target version changed from 1.0.1 to 1.0
Actions

Also available in: Atom PDF