Custom Dialogs/Error Msgs. overwritten w/ German translations w/ unknown source

Some dialogs are customizable in the admin panel, while some others are fixed in the code (and can be filtered). It would help if I knew which messages you were referring to.

I am refering to the ones that I had customized in the admin panel, not to the ones fixed in the code. I found out while checking my registration process.

They seem to be the original error messages from wordpress itself. I deactivated my locale, tried to register without a username, and the message still was in German. Then I checked with Codestyling Localization, and sure enough, I found them in the main language files. Apparently, they are not caught off and replaced. Could you include this in your plugin to achieve a complete customization of the front-end processes and dialogs?

Also, in my German installation, on the registration page I am asked for “First Name”, “Last Name” and “Email”, instead of “Vorname”, “Nachname” and “E-Mail-Adresse”. And I can’t change that, since the fields are marked “native” in the fields admin tab.

It seems that WP-Members pulls the field names from the network language, which in my case is English. It would be great if WP-Members could change that to fit the language of the subsite. Would this be possible?

Also, after saving a changed field, I am not redirected to the general fields tab. Instead, I get a confirmation message and the lower part of the tab for adding a new field. Is this just me?

Sorry for expanding on other (related?) problems in this thread. It just seemed cleaner. I can open another thread for the last two comments if you like.

To get back to the original problem: While registering on my site with German WP-Members locale deactivated, I received these following dialog messages that are different from the custom German messages I put in the WP-Members admin dialog tab:

1. Registration failed, username taken: “Entschuldige, aber der Benutzername existiert bereits!” (Custom WP-Members dialog should be: “Dieser Benutzername ist leider schon vergeben. Bitte w?hle einen anderen.”)
2. Registration failed, email adready taken: “Entschuldige, aber diese Email-Adresse wird bereits verwendet!” (Custom WP-Members dialog should be: “Diese E-Mailadresse ist leider schon in Gebrauch. Bitte w?hle eine andere.”)
3. Registration failed, password mismatch: “Passwords did not match.” (Custom WP-Members dialog should be: “Die Passwortangaben stimmen nicht überein. Bitte versuche es noch einmal.” – This string actually comes from WP-Members, and can also be localized.)
4. Registration successful, but moderated: “Deine Registrierung war erfolgreich! Du kannst dich nun anmelden.” This is actually a false positive (it says welcome and that he can login now). At this point, the user should only be informed that his registration has yet to be approved – more about this specific problem in the other thread.

Other dialogs I tested were correct: Successful registration works, if registrations are *not* moderated; password reset works; and for email mismatch you don’t offer a custom message field, so logically I got the English one.

To conclude, it seems that WP-Members in my case cannot override three default (translated) WP strings with its custom set messages (1+2) and with its own (translatable) string (4). And in case of the password dialog, it cannot override its own message string.

I hope you can help me with that. It’s been some long hours figuring out what is actually going on here…

~Manuel

Okay, in case of 4, actually there is no string (that could also be translated). When translating, I found that the locale contains some notice for the admin, telling him that he should change the dialog message, but this dialog box does not exist. So no wonder I get the default WP success message…

I need to point out here that Multisite is VERY different from WordPress single install. They are two different animals when it comes to plugins, especially plugins that handle users (since users in MS are not the same as users in single install). So in that regard, the behavior that you get may differ depending on how the plugin is installed and activated (network installed and activated or activated at the site level). For that reason, MS is not officially supported.

Now, I do work with MS to accommodate as much as I am able, but there are some limits to that, some of which are limitations based on the differences between MS and single install WP.

Also, after saving a changed field, I am not redirected to the general fields tab. Instead, I get a confirmation message and the lower part of the tab for adding a new field. Is this just me?

No, that’s not just you. It’s a known UI flaw that is being addressed in 3.1. 3.1 is focused on a number of changes to fields – offering some much needed additional field types, supporting HTML5 form attributes, and things of that nature. So correcting some of the shortcomings in the fields tab are part of that.

They seem to be the original error messages from wordpress itself. I deactivated my locale, tried to register without a username, and the message still was in German. Then I checked with Codestyling Localization, and sure enough, I found them in the main language files. Apparently, they are not caught off and replaced. Could you include this in your plugin to achieve a complete customization of the front-end processes and dialogs?

That dialog does exist. I think it may not have displayed since the dialog you had in tab was in German (and thus the plugin would think that it is changed.) It’s kind of a logic limitation since I can’t really make it smart enough to know exactly what the dialog was change to.

I see ?? I was not aware that this plugin is not MS compatible. I so much wanted to get this right and working… I also deactivated WP-Members on network & activated on subsite level, but that did not change anything. At least, all my settings and custom messages remained.

Do you plan on fully integrating MS support, if this is technically possible? I would be so glad if you did. And many other admins of multilang network sites would certainly be, too! ^^

That dialog does exist. I think it may not have displayed since the dialog you had in tab was in German (and thus the plugin would think that it is changed.) It’s kind of a logic limitation since I can’t really make it smart enough to know exactly what the dialog was change to.

I did not really understand that. Shouldn’t the custom dialog override anything that WordPress itself tries to give out, no matter if already translated or not? Isn’t WP-Members like the last graffiti sprayer from fall ’89, whose message forever remains on our Berlin Wall?

Also, no. 3 remains unsolved. It seems not an WP MS issue, but something inside WP-Members: A field where we both have a string in the php file (which I translated) *and* a custom field in the dialog tab. This can’t be right, right? We can have one, but not both at the same time.

Today I found that when I set my network/root site lang from English to German (as the subsite I am refering to here has been ever since), at least the registration form field “Email” becomes “E-Mail”, as we spell it here. (Mind you, there is no such translation in the locale of WordPress. There is “E-Mail:”, there is “E-Mail-Adresse”, but there is not “E-Mail”. Only WP-Members had this translated string, and in the WP-Members admin field tab I now get the German explanation and this term for the field; both had remained English before. So this could very well be some MS problem you referred to?)

I have changed the translation from “E-Mail” to “E-Mail-Adresse”, hoping this is alright, to see if backend and registration form will deliver this correct term – if the address is meant, “Adresse” is necessary. (The tranlations seem to take a while to be available for download, though, it’s been ten minutes and none available in my backend.)

The “First Name” and “Last Name” remain English, hoewever. :/ Maybe WP-Members just cannot translate/replace them because you haven’t had strings for that yet? If it works with “email”, wouldn’t it work for them, too?

I see ?? I was not aware that this plugin is not MS compatible.

It’s not that it’s not “compatible” but rather that it is not fully supported. There’s definitely a difference. It is compatible and can run on multisite. But as I mentioned, multisite has some very big differences when it comes to both plugins and users. And the number of possible offshoots from that in how people use it makes it nearly impossible for me to handle every possible scenario of how people think it should work. There are definitely people using it on multisite. And I do add more improvements for using on multisite as they come up (one of which you’ve identified – more on that below).

I think that the first name/last name strings (and a couple of others) got lost somewhere in the transition to the glotpress project. They were in the original .pot file but when a .pot is generated from the code, they won’t be in there. This is because all of the fields get stored in the db as English and are translated when displayed. So the gettext is handled like this:

__( $field[1], 'wp-members' );

I’ll need to look into why these strings got dropped and see about getting them added back in as that affects all of the default fields the plugin installs.

Any other strings (such as the password confirmation mentioned earlier) are in there and should be correctly processed (the password confirm string is). When the plugin is network enabled, I would think that it would take it’s language off the root site.

Regardless, I can look into adding some additional logic to the wpmem_load_textdomain() function to account for multisite. It’s probable that the locale needs to be handled differently.

Glad that I could assist in finding this transition issue. Thanks for looking into it.

The “E-Mail-Adresse” is since today correctly coined on the registration form. So it really was first in English, because my network and root were in English, and now it is in German, since my network and root are now in German, and also I get the correct translation from WP-Members now, too.

About the passwort mismatch string, I think this has nothing to do with the other stuff, it is independent from translations. Please clarify: Do you want to use custom field, or do you want (translated) php string? Because it seems that the hardcoded beats the custom. So I would kindly ask you to remove the custom field for that, if it is useless anyway.

About the passwort mismatch string, I think this has nothing to do with the other stuff, it is independent from translations. Please clarify: Do you want to use custom field, or do you want (translated) php string? Because it seems that the hardcoded beats the custom. So I would kindly ask you to remove the custom field for that, if it is useless anyway.

This is talking about two different things.

The password mismatch string is hardcoded, it should be displaying when passwords do not match, provided that the password fields are either the originally installed default password fields OR have been added with the option names “password” and “confirm_password”.

I did some digging into this because in my test environment running single install in the plugin’s original German translation (before the polyglots version), I got the same issue. It seems that the string in the code ends with a period “.” where the string in the .po does not (not sure how that happened).

Of course that’s not a match, so the English displays. That seems to have carried into the polyglots translation file as well (since the original templates of those were automatically built off the plugin’s translations). But I do see there is a string in that file that does not have the period.

So I would say take a look at the install that you have. This message occurs in /inc/register.php – look for this comment:

// If form contains password and email confirmation, validate that they match.

The other thing I was talking about is the custom strings. They have to be handled as custom. Otherwise you’re stuck with the fields the plugin installs with. It can’t be both ways. Most people want the ability to set their own fields.

It used to not be an issue for generating the template because the translated string was installed in the db. But that caused too many problems for users who installed it in English first and then switched to a language; then they had to force the fields to be updated. So now the English string is stored on install and translated when the form is displayed.

I’m not sure how the strings for the default fields got removed from the template because they were in the original translation files. But I think I have a solution for that coming in the next release anyway. There will be a container for all of the fields that the plugin installs by default so the gettext call will be there for any default fields. (The 3.1 series will be re-building a lot of things around registration/profile input fields.)

Thank you for taking the time to dig into this. Yes, I found this line, all looks normal there.

So, please correct me if I’m wrong: While 1+2 from the above comment are hardcoded strings in WordPress itself, 3 (password mismatch) is hardcoded in WP-Members. WP-Members offers to customize them all, but in my case fails to do the job, possibly due to MS issues, displaying at the frontend the default/locale translations from de_DE (1+2) and wp-members-de_DE (3) instead of giving out the custom dialogs.

I am looking forward to 3.1, then!

I think that if some strings are translated and others not, then it’s not an MS issue. 3.1 is going to move all front end strings to be loaded as part of the WP_Members object, so it will be easier to manage them. I’m still making a decision on whether or not to make them all wp-members textdomain, or to continue leaving the strings that are part of WP to be translated as such.

I’ve noted the password mismatch string to be looked into so hopefully I can figure that one out during 3.1 development.