reproduce
- create content, add webform components and select both options in "LOCALIZATION BY STRING TRANSLATION"
- translate the content
- refresh the strings, translate the form labels
- create a new content, do some things (in my case, I was using identical form config)
- refresh the strings, check your original content: translations are gone.

Issue found on staging site and I was able to reproduce this on my local development environment.
looking into it.

CommentFileSizeAuthor
#21 string_translations_lost_on_refresh-1483942-21.patch4.6 KBrv0

Comments

rv0’s picture

rv0 commented
Title: String translations are being deleted » String translations are being deleted on "Refresh strings"
GDrupal’s picture

GDrupal commented

That is strange I will look into it too....

rv0’s picture

rv0 commented
Status: Active » Needs review

Aaargh spent too many time debugging this simple bug :(

  // Get components configured as translatable.
  $query = db_select('webform_component', 'wc');
  $query->fields('wc');
  $query->condition('wl.expose_strings', 0, '>');
  $query->innerJoin('webform_localization', 'wl', 'wc.nid = wl.nid');
  $components = $query->execute()->fetchAllAssoc('cid');

fetchAllAssoc('cid');
Means not a lot will survive the string refresh ;)
Change to:

$components = $query->execute()->fetchAll();
GDrupal’s picture

GDrupal commented

@rv0: Ouch that was ugly! I will review this ASAP. Is working properly for you after that change?

rv0’s picture

rv0 commented

yes, working fine here..

The only strange issue I have is that a new node with same fields (using a slightly modified version of webform_template to handle the localization settings) will use the string translation of the original node (which it shouldn't without any custom code). After refreshing strings however, it doesn't have this behavior. Weird cashing issue? I'm not too familiar with i18nstrings yet.

GDrupal’s picture

GDrupal commented

That is strange indeed because the string are found by a string id that uses the node id... nid+cid+stuff... have to be unique right?

rv0’s picture

rv0 commented

@GDrupal, indeed.. and when I check the translation table there's only the strings of the original node.

Anyway, this problem should fix itself in my use case as I'm writing code to copy and resave the original strings, but with the new nid in the name string.

GDrupal’s picture

GDrupal commented
Assigned: Unassigned » GDrupal
Status: Needs review » Fixed

Fixed, committed and attributed!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

mlima’s picture

mlima commented
Version: » 7.x-4.x-dev
Issue summary: View changes

I'm having the exact same issue in the exact same scenario.

bluesman2014’s picture

bluesman2014 commented

Me too, hundreds of translated strings have been deleted!

bluesman2014’s picture

bluesman2014 commented
Priority: Normal » Major
Status: Closed (fixed) » Active
alanburke’s picture

alanburke commented
Priority: Major » Critical

Data Loss means this is critical

denes.szabo’s picture

denes.szabo commented

Same issue. I have just lost all my translated string during refresh.

denes.szabo’s picture

denes.szabo commented

My quick fix for my site:
Delete 237-240 lines from webform_localization_delete_all_strings() function webform_localization/includes/webform_localization.i18n.inc.

Now, my translations remain intact after strings refresh.

tasc’s picture

tasc
Primary language German
Location Berlin
commented

Same here, but fortunately I have a Feature which reverts my translations, so I can reproduce.
With "clean up left over strings checked" it happens only on batch when I select multiple text groups. In my case these are Fields, Metatag, Webform Localization, Menu, Taxonomy in this order.
Selecting Fields alone deletes all translations for Fields.
Selecting Metatag, Webform Localization, Menu, Taxonomy deletes Webform Translations.
Selecting Webform Localization, Menu, Taxonomy the translations get refreshed & stay intact.
Bizarre..
(#15 doesn't work)

denes.szabo’s picture

denes.szabo commented

@tsc_a - You are right, #15 is not a good solution. Actually, somehow I could manage to delete my translations. But, I removed the delete part of this module… So, It's correct: bizarre.

denes.szabo’s picture

denes.szabo commented

I just did a little debug:

The refresh strings deletes the strings when the Node types and Webform Localization both selected from text groups.

If both selected, the translate elements version become 0 (locales_source.version) , then because of the "Clean up left over strings" is set, these translate elements will be removed completely - so you can't translate them again, just after refresh the Webform strings, because the sources have deleted.

I am continue now with the "Node types" debug…

karlkablisk2’s picture

karlkablisk2 commented

Arg! I just had this issue and was so confused. I see the change mentioned above in the module file

$components = $query->execute()->fetchAll();

To Denes.Szabo. Your tip was a BIG help in isolating the issue so it can be avoided.
But I still had ONLY my webforms translations deleted when Node types strings were refreshed. I didn't have both selected and I didn't have "Clean up left over strings." checked. I did a few tests because I was lucky enough to have a backup with backup and migrate module to do this a few times.

So I can now avoid all my form translations being deleted... My problem now is that the new webform translations won't appear because when I refresh the strings on webform localization, nothing happens. Also I think this bug should be addressed. If I slip up once and don't have a backup handy I will have to redo all the translations.

Side note does drupal have any direct translation options!? This is annoying refreshing strings etc. Why can't there be a 1:1 translation right next to the field when I edit it. This is the most counter intuitive system I've seen in Drupal, language isn't being handled well at all. I didn't see much better with what little I messed with 8 so far. Until then this string refresh system, if I have to rely on it, needs to at least work.

Help! anyone! >_<

joseph.olstad’s picture

joseph.olstad
Primary language French
commented
Status: Active » Needs work
rv0’s picture

rv0 commented
Assigned: GDrupal » Unassigned
Status: Needs work » Needs review
StatusFileSize
new string_translations_lost_on_refresh-1483942-21.patch4.6 KB

The fix is quite simple I think, we have to check if $group == 'webform' in the refresh callback.

See attached patch that does that (patch looks big, but thats just because all the code is nested in the 1 line check. I havent changed any other logic)

My strings don't got lost any more using the usecase from #18

joseph.olstad’s picture

joseph.olstad
Primary language French
commented

Hi rv0, thanks for the patch, is it correct to assume that you tested this on todays build of 4.x before and after the patch and that after the patch on the latest 4.x the behavior is corrected?

rv0’s picture

rv0 commented

@joseph.oldstad.
The patch was created from the latest 4.x branch from git which is at commit 17fb10d303f28f7a517013f7265a253795e3af5e (yesterdays commit)
That is the normal way to create patches afaik ;)

If you are unsure about your version, you can do this fix manually:

- find webform_localization_i18n_string_refresh
- change the function header to function webform_localization_i18n_string_refresh($group) {
- place all the code in the function in the following condition if ($group == 'webform') { /* code goes here */ }

  • joseph.olstad committed 4333798 on 7.x-4.x authored by rv0 
    Issue #1483942 by rv0: String translations are being deleted on "Refresh...
joseph.olstad’s picture

joseph.olstad
Primary language French
commented
Status: Needs review » Fixed
joseph.olstad’s picture

joseph.olstad
Primary language French
commented

Thanks RV0, nice work!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.