When you add a new user form in CRED with the "visual" builder, you get a "repeat password" field.
That field's label is not translated, while the "main" password field label is translated, if you use WP in any non-english language.
For example set WP to Spanish, then setup such new user form with password field
It will generate a main and a repeat password field.
The main password field will say "Contraseña". The Repeat field will say "Repeat Password"
One needs to use the advanced HTML editor to change that.
(Note, I switched WP to Spanish AFTER creating said form, and that might be connected to the issue, however, since the main pwd form IS in fact changing language so I would expect the repeat password field to change as well)
It seems that the language is set at the time you save the form.
If I switch the site language to Spanish, then edit the form and save it, then visit the form on the front end, the label will say "Repetir contraseña".
If I then switch the site language to English and visit the form on the front end again, it will still say "Repetir contraseña".
Let me look into how this is set up and I'll get back to you.
As you know if you switch to the advanced editor you'll see that the form texts are wrapped in cred_i18n shortcodes.
Checking the source code (see the screenshot), it shows that these are designed to be translated with WPML, and don't use normal gettext calls so cannot be readily translated any other way.
So the "solution" is to use WPML to provide the translations.
If you don't want to, and WPML isn't active on the site, then you can see how the text for translation is passed through the filter 'wpml_translate_string', so you could add your own callbacks to that filter to handle translating the text.
Yes, IF I want them translated to any other language, then I will use WPML.
But I do not.
It makes no sense to me that I would have to install WPML just to have the label of the SECOND password field in my websites language, but the FIRST password field label would do this all on its own?
Even if resaving the form does fix something, this is not the point.
The point is that switching the language does change the FIRST pwd label, but not the SECOND.
Since both are labels... I would expect both or none to change, on language swap, wether we save or resave the form should not matter, and wether we have or not WPML should matter even less.
I found when using the Visual Editor that the second password field label was in whatever language the site language was at the time of saving the form.
So if I was working on a site where the site language was Spanish, and I created a user form that included password fields, upon saving the form and visiting it on the front end the second password field label would be in the correct language.
In your original post you said you changed the site language after you created the form: that is why the label is in the "wrong" language.
Re-save the form when the site language is whatever you want the field label language to be.
If you confirm that works then there doesn't seem to be an issue.
1. Two fields, one is password, one is repeat password
2. The fields labels do not both "react" the same to a language change
3. The First field label will change its language. The second not.
That, to me, seems like something that does not act the same.
What is the justification behind "For the first field we will switch that language for you. However, if you want the tightly connected similar field to also switch language, you have to re-save the form"
Of course we can call this a minor issue, or even ignore it. But I don't see why we would. There are two fields, and both fields do not seem to operate the same way. Weird, at least. Confusing, to others, and cause to ticket, for time wasters like me 🙂
I still do not understand how the "issue" would be less of an issue, or even a non-issue.
What you say is exactly what I reported. And both fields do not act the same. One changes, the other not.
However, no time to follow up here - do what you want, close the ticket if you like. I solved the "issue" on my end prior to report, wasted some time trying to explain why it is an issue, and failed.
If you give me exact steps to reproduce the problem where the first step is "set the site language to the language you want the form fields to appear in" then that's something to work on, but given what you have described so far there is no issue to investigate.
I just followed your steps and both password fields are in English (because the form was created in English).
In any case, were I able to reproduce the issue it could be avoided by creating the form while the site language is the same as intended for the form, or if the form has already been created in the wrong language, could be fixed by re-saving it in the correct language.
There isn't enough of an issue here to escalate to the developers.
Screenshot of the form AFTER switching the language and AFTER resaving the form
It is now the exact opposite of what I saw on client site... this is a fresh site :rofl:
hidden link
Database dump with sample page and user form, AFTER switching language AFTER resaving said form
Now, maybe I am dumb, but to me, it pretty much seems it does a bit of whatever it wants.
While on client site the Secondary Password Field was the ONLY one not reacting to the language switch, in local it is the ONLY one that does react. And note, I HAVE resaved the form as you say is a "solution" to the problem
I don't have time to proceed here, so if you still think this is all below Toolset's level of entry, feel free to keep the thread closed.
For me, I couldn't care less what works or not. I will just make it work somehow fo the client, it's my job.
Further digging I find that if we CHANGE the user role BEFORE we save the form, and THEN save the form ALL fields get updated label
Probably that is "expected" too?
Like, a user has to know that after changing the site language not only they have to resave the form, but also switch user role it creates, then switch back, so it triggers the Visual Editor once *and destroys whatever they customised in there*, then they can rebuild the form and resave it.
I created a sandbox site to go through the steps exhaustively one more time.
You are welcome to log in and play around with it yourself: hidden link
Here are the steps I took:
Created a Sandbox site, with EN (default) plus ES
Created a form "Register Author" using the Visual editor
Inserted form on a page "Register Author"
Checked on the front-end: all field labels in English
Switched language to ES
Checked on the front-end: all field labels in English
Edited the form and saved without making any changes
Checked on the front-end: Password => "Password", Repeat Password => "Repetir contraseña"
Switched language to EN
Checked on the front-end: Password => "Password", Repeat Password => "Repetir contraseña"
Edited the form and saved without making any changes
Checked on the front-end: all field labels in English
Switched language back to ES
Edited the form and saved without making any changes
Checked on the front-end: Password => "Password", Repeat Password => "Repetir contraseña" (same as before)
Edited the form and manually changed the label to "Contraseña"
Checked on the front-end: Password => "Contraseña", Repeat Password => "Repetir contraseña"
Switched language to EN
Created a new form "Register Author 2" and repeated many of the above steps, and observed the same results.
Switched language to ES
Created a new form "Registrar Autor"
Inserted form on page of same name
Checked on the front-end: all field labels in Spanish
Switched langauge to EN
Edited the form and saved without making any changes
Checked on the front-end: Password => "Contraseña", Repeat Password => "Repeat password" (same as before)
Switched language to ES
Edited the form and saved without making any changes
Checked on the front-end: all field labels in Spanish
From the above I conclude there are no issues to escalate.
1. If you set the required language before creating the form, all labels are as expected with no edits necessary
2. If you create the form in the wrong language and want to correct it, you need to switch to the intended language, edit the form, change any static labels (e.g. the password field is a static field with a label; it will only change if you change it). Dynamically generated fields such as the repeat-password field will—after saving the form—automatically inheret the correct language.
After many attempts I cannot reproduce any issue, it works as expected, so—yes—let's close here.
This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.
