Please make sure to update to WPML 4.3.5 and check our list of Known Issues before reporting

Hi, Amit here, I am the WPML Support Manager, our current ticket queue is high, update your WPML plugins and make sure you meet the minimal requirements for running WPML before reporting an issue please - many tickets are resolved doing that

Please look at our updated list of Known Issues and you can also use our support search to find helpful information and of course review our documentation before opening a ticket.

If you do need to open a ticket please make sure to provide us with all the needed information as described in this page

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

This topic contains 34 replies, has 3 voices.

Last updated by bothienB 1 week ago.

Assigned support staff: Alejandro.

Author Posts
November 22, 2019 at 3:22 pm #4999611

bothienB

I am trying to:
Display a form where there are several occurrences of a field with the same label.

Link to a page where the issue can be seen:
hidden link

I expected to see:
Each iteration of the field(s) with the correct label and values (for select)

Instead, I got:
One or more labels / selects that are inconsistently populated in English.

What I've tried : change the labels (if you change the lang parameter to 'fr' you will see that repeated fields labels have indexes (like 'Civilité0,Nom0, Prénom0,email0)) resulting in various & mysterious combinations of labels being translated while selecte are not, or both ...

Where I am : deep in the red. For weeks now, since the latest "major upgrade"; I believe this was not the case before.

What I need :
- either identify the problem (hint : looks like the replacement is not done against blog+form_id+field_id but somehow on labels/values ?) and solve it in a very short time (i.e "yesterday")
- OR being able to rollback to previous WMPL version that isn't causing the same disaster WITOUT losing all the translations made.

I really need assistance here, that's a major concern and we were supposed to go live (again) last week.

P.S : in native language(fr) we have no problem.

November 22, 2019 at 4:44 pm #5000961

Lauren
Supporter

Languages: English (English )

Timezone: America/New_York (GMT-05:00)

Please see my previous private reply and let me know once the migration has been completed. Thanks!

November 22, 2019 at 4:48 pm #5001001

bothienB

Lauren, we are multisite; will it fit ?

November 22, 2019 at 4:52 pm #5001011

Lauren
Supporter

Languages: English (English )

Timezone: America/New_York (GMT-05:00)

Yes, it should work just fine. I set up the staging for multisite.

November 22, 2019 at 4:59 pm #5001031

bothienB

Added some details for what blog to test at the bottom of our private initial conversation
6:43 local time (Paris) : still running, copying tables ... 366/849

November 22, 2019 at 5:04 pm #5001071

Lauren
Supporter

Languages: English (English )

Timezone: America/New_York (GMT-05:00)

Perfect thanks. Just let me know once the migration is completed - you should receive an email notification.

November 22, 2019 at 6:04 pm #5001345

bothienB

Still running ... last step.
Migrating Site (Copying Database Table - ******o3_icl_string_translations 577 / 849)

November 22, 2019 at 6:25 pm #5001403

bothienB

Lauren : "migrated" but seems to have some DNS/URL issues with sub-sites ...
Maybe it'll be easier if I set you an Admin account on our site ...

November 22, 2019 at 7:07 pm #5001647

bothienB

Please check first message with login infos

November 23, 2019 at 12:53 am #5002341

Lauren
Supporter

Languages: English (English )

Timezone: America/New_York (GMT-05:00)

Thanks for the additional info. Unfortunatley, I was not able to login as a Super Admin. Can you please double check those credentials?I was able to add a function to the theme to add a user but that only gives me access to the one blog site and I can't see any of the WPML settings.

Thanks for your assistance.

November 23, 2019 at 7:20 am #5002789

bothienB

Hi Lauren,
This was 1AM in my TZ and unfortunately I stooped monitoring @ midnight ...
it's 8AM Saturday now and I can see that we have URLs problems; none of the sub-sites are accessible.
What I will probably do is duplicate the site in our MU environment and create credentials for you so that you can have a look on Monday. Will keep investigating on my side but one of the things I noticed is that all the icl_xxs tables seems to be pretty heavy ...
We use NS Cloner plugin to generate sub-blogs; is there something here that could explain our problems ?
BR
Antoine.

November 23, 2019 at 9:51 am #5003247

bothienB

Lauren; so I've been digging into the icl_strings and icl_string_translations.
Will try to add my Excel Worksheet in private message but what appears is :
all translation strings are set accordingly to WMPL recommendations :

1. Fields used for logic statement have a value/label attributes pair and the value isn't translated (shouldn't be a problem anyway, as in my case, translation of these values would only be a single digit : 1 or 0 - but I digress)
2. Regarding conditional logis possible issue : well that's not that; I've removed all conditional rules and the result is unchanged.
3. All (Select->Options) labels are properly set as I find all required translations when joining icl_strings.id to icl_string_translations.string_id
4. I tried various configurations of the select fields (setting values to target/original language or unset them) without luck.

So ... where am I now ?
- I believe there's a rendering issue here, not a string settings issue.
- This rendering issue (apparently) only impact select option labels (the select label is properly translated ... now. Pls don't ask me why)
- So I will dig into the Gravity forms multilingual plugin to - try to - find "something weird" ... great weekend in sight 😉
... and of course, will keep you posted.
BR
Antoine.

November 23, 2019 at 11:10 am #5003687

bothienB

There's definitely something wrong in the rendering.
As I'm the kind of person unsatisfied with "don't ask me why" statements, I went back to my form and then reminded that in its original settings, I had several identical labels for several fields resulting in fields label not being translated.
So I changed the names of identical fields (for instance we have a field labelled 'name' for an attendee, 1 for his companion and 1 for his guest -> name0, name1, name2) and noticed they were - finally - translated.
Reverting this to a "normal" situation - where I can freely choose a label for a field - and setting them all back to "name" resulted in expected behavior : none is translated.

Could it be that trivial ? The plugin relying on field/option label instead of field id / option position to get translations ????

November 23, 2019 at 11:34 am #5003837

bothienB

Update : in fact, only the last field *label* is translated (options aren't), while only the first field *options label* are translated (field label isn't). There's definitely a flaw in a loop somewhere ...

November 23, 2019 at 1:25 pm #5004235

bothienB

SO I tried to sniff inside the code and I must say it's probably way above my knowledge to debug this in a proper manner. Thus, as I'm a bit stubborn, I edited the inc/gravity-forms-multilingual.class.php (starting line 685) as below "just in case" I could find "something" :

		// Filter form fields (array of GF_Field objects)
		foreach ( $form['fields'] as $id => &$field ) {

            echo($id); // edited : should give me an idea of the "index" used later
			$snh->field = $field;

			// Filter common properties
			foreach ( $keys as $field_key ) {
				$snh->field_key = $field_key;
				if ( ! empty( $field->{$field_key} ) && $field->type != 'page' ) {
				    echo(' => ' .$field->{$field_key} . ' => ' .icl_t( $st_context, $snh->get_field_common(), $field->{$field_key} ) .'<br>'); // edited to display original string => translated string
				    $field->{$field_key} = icl_t( $st_context, $snh->get_field_common(), $field->{$field_key} );
					
				}
			}
[...]
}

And - eventually - I did.
If you look at the attachment, you will find that the first iteration of the field "Civilité" (aka "gender" -> same case that what I called "name" earlier in my problem description : multiple occurrences of a field with the same label ) seems to have a "double" ID i.e 13 and 14 resulting in a "merged" 1314 ID that is not in the general logic (+=1) of the (ordered ?) list ...
I'm pretty sure that when returning the $form there will be some hiccups @ rendering ...

Good news is this should not be a heavy fix for your dev team, sadly it also means I'll have to wait until Monday, at best ...

Notes :
- This field has a admin_label ("Guest_Civ") as all other duplicated fields.
- It is the first one to "break translation", I've not met other "double ID" case after.
- Regarding the field labels; all the fields (not only selects, also basic text inputs) with a duplicated label are correctly translated in their last occurrence, otherwise, not translated. Select Options labels are only translated in the first occurrence.