RAM ML in Xprofile Fields

[lahigueracorner]

Hi there. Up to version 3.0, I could use Raw ML language coding in the buddypress Xprofile fields. It worked very fine. Only in the child theme, I had to put some __() coding to get things like “Base” etc properly displayed. The rest it worked like a dream. I use this style coding: [:en]English Text[:de]Deutsch[:]

Together with qTranslate-X. I have lots of translations, so “simply” copying everything in WPML, and then still hoping that that will work, would be an enormous job.

Version 3.0 was a big change. All seemed well, except for the Raw ML X-profile fields.

It seems that somewhere in the 3.0 and up version, an extra translation of the whole HTML happens:

The <value> tag in a select field will no longer have [:en]English Text[:de]Deutsch[:]

But, when for example in German, only hold the value “Deutsch”. As Buddypress first checks for an xprofile field to change, if a value exists, and in this case, just “Deutsch” is not an existing option in the database, the profile is not updated. A Something went wrong error message comes up from Buddypress.

Yet the problem is not in Buddypress, it is in the new Sweetdate. Even with the latest Buddypress, when I downgrade Sweetdate to a pre-3.0 version, everything works pèrfectly again.

 

Somehow, somewhere, the new sweetdate seems to push the whole HTML of the page through another translation cycle (maybe to be sure to be sure), messing up the value fields of select options. I pasted some Raw ML text in the page-parts, without any __() processing of it, in some page-parts and other sections, and in 3.0 and up that all comes out as translated text, not the original Raw ML. It seems somethings “washes the entire page through translation.

My question is, where can I find that. I have been searching and searching, maybe somewhere in the general framework directory?

 

Any suggestions or hints? No fear on messing with the php in my child theme on this side! Where is this probably one line of code that executes another __() or _e() over the whole page?

I do not mind if some other info might not come out translated either, when I can comment this extra translation cycle out. I can fix that easily.

[Laura]

Hello, will assign the ticket to a higher support level who can help and advise you in your query.
Thanks! ?

Hi there!!! Help others from the community and mark any reply as solution if it solved your question. Mark as a solution

Laura Solanes - Graphic Designer and Web Designer

Please be patient as I try to answer each topic as fast as i can.

If you like the theme or the support you've received please consider leaving us a review on Themeforest!

Always happy to help you 🙂

[Radu]

Hi,

What version you was running before to update to 3.x ?

I think this function causes those for you

COPY CODE

/*Make xprofile fields translable fix*/
if ( ! function_exists( 'make_x_profile_fields_name_translable' ) ):

	function make_x_profile_fields_name_translable( $fieldname ) {
		return __( $fieldname, 'kleo_framework' );
	}

	add_filter( 'bp_get_the_profile_field_name', 'make_x_profile_fields_name_translable' );

endif;

path : wp-content/themes/sweetdate/custom_buddypress/bp-functions.php from line 2960

It can be overwritten in child as you need.

Let me know

Cheers
R

Hi there!!! Help others from the community and mark any reply as solution if it solved your question. Mark as a solution

What support service includes ? What not ?

[lahigueracorner]

The version I downgraded to is 2.9.11.

The function make_x_profile_fields_name_translable I already found. Yet is seems to translate the field names, not the values (I had some problems in older sweetdate versions, pre 3.0 that I fixed by adding some __() in the child theme.)

Just to be sure I ungraded a backup of my site from sweetdate 2.9.11 to 3.2.11, activated the theme itself (not the child).

This is my Country Field in the source code of the page:
<option value=””>—-</option><option value=”Afghanistan”>Afghanistan</option><option value=”Albania”>Albania</option> … etc. etc. …. </select>

I switch back to 2.9.11 for my tar file. The in the same edit profile HTML, I see:

<option value=”[:af]Afghanistan[:sq]Afganistan[:am]አፍጋኒስታን[:ar]أفغانستان[:hy]Աֆղանստան[:az]Əfqanıstan[:eu]Afganistanen[:be]Афганістан[:bn]আফগানিস্তান[:bs]Afganistan ….etc. etc. all my translations … >Afghanistan</option>

As this long string with all translations is the actually configured xprofile field value in the database, it is accepted to update the profile. Next in all languages, the country name shows up only in the respective country (beautiful!).

The value <option value=”Afghanistan”> causes the error. Even if I would skip the check in Buddypress for existing values, the beauty of being able to read Afghanistan in Arab for example when looking in Arab, would be lost.

The great thing was with before 3.0, with the right .mo translations, Sweetdate could be fully localised in all languages, up to the last button. I still run it in this form on my live site, but when I upgrade sweetdate, the profile fields become a mess.

I’ve been grepping all over the place, but until now unable to find it.

[lahigueracorner]

Forgot to mention, in my test, I did comment out the whole make_x_profile_fields_name_translable section.

Still my Afghanistan value came out as described above.

[lahigueracorner]

Finally:

I have another project still on my drawing table. Same concept. Frontend still password protected.

Just check out pop-in.org
Password: cooldate

And see the true beauty of your theme, when someone puts some passion in it. In the header there is a language toggle. Play with it. Switch to Chinese just for fun. Everything is Chinese now, including all profile details (except free text fields). Free text fields can even be entered RAW ML coded, and even that works!

The chat, at the bottom, does more magic. It picks up both users languages and autotranslates. So… I can become friends with somebody in China. I can read the whole profile in my language. The Chinese reads everything in Chinese. Then we can go to the chat. I can ask what the Chinese person is having for dinner tonight. And get a reply back in both Chinese and my language. Magic.

In pop-in.org, you can also make some profiles to play with. See how the profile update works. It is still in sandbox mode anyway (that’s why I put a simple password for now…).

You know the lines of the song Imagine, from John Lennon and Yoko Ono? With sweetdate I could fulfill a part of the dream in that song. Cool!

Now where is that extra translation step that scratches my Imagine song?

[Radu]

Hi,

What do you mean by
“Now where is that extra translation step that scratches my Imagine song?”

Not sure what to advice you since you had done that thing in child to make the translation of the fields, a most reliable way it’s to use a plugin like wpml.

Cheers
R.

Hi there!!! Help others from the community and mark any reply as solution if it solved your question. Mark as a solution

What support service includes ? What not ?

[maartenmarbella]

The case I explained was not in the child theme. To make sure I was not in the child (containing changes I made, as that is what child themes are meant for), I activated the original theme.

The original 2.9.11 theme does not translate the value fields in selects in HTML. It works with older and thye lastest Buddypress vserions flawlessly.
The original 3.2.11 does. And that does not work with Buddypress. I gives a Buddypress error. With older versions of Buddypress and the very latest.

Can you confirm that if I would switch to WPML, and move everything to WPML, everything would work?

Or are there any users of your theme who work multi language who can confirm that sweetdate actually works with WPML?

[Radu]

Hi,

Q : Can you confirm that if I would switch to WPML, and move everything to WPML, everything would work?
R : No, because i don’t know exactly what you have there and what are your expectations, the i suggested WPML cuz it’s very reliable and works on majority of wp versions without similar issues like explained one.

The thing that you may need to take into consideration when you migrate to WPML, it may need to re-do all your translation if the wpml way witch it’s different than your current one.

The WPML it’s compatible with the sweetdate https://wpml.org/theme/sweet-date/

Cheers
R

Hi there!!! Help others from the community and mark any reply as solution if it solved your question. Mark as a solution

What support service includes ? What not ?

[maartenmarbella]

I did some checking on converting from Raw-ML coding to WPML. It has some bad consequences. First of all it will convert all my posts and pages to separate pages per language. Which will make it almost impossible to manage my site, as I support many languages.

Second, all my Buddypress X-profile fields and values need to be manually entered word for word in the WPML system.

Third, all my current user profiles are stored in the database in Raw-ML style. I could make a script to go through the database and convert them. But still a bit tricky, because I I would have to eventually do it on the production database and I have a lot of registered users.

Raw-ML is fully WordPress and Buddypress supported.

My expectation was only that Sweetdate would support it too. Apparently, with the older versions of Sweetdate, I was just lucky that it was still compatible with WordPress and Buddypress standards.

[maartenmarbella]

You can close this ticket.

It actually was a simple and easy fix in the child theme. If you know where to look.

[Radu]

Hi,
Great then
Have a nice day
Cheers
R

Hi there!!! Help others from the community and mark any reply as solution if it solved your question. Mark as a solution

What support service includes ? What not ?

[Author]

Posts