lahigueracorner

[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?

[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]

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.

[Author]

Posts