Field labels&descriptions are lost on string refresh

Have you cleared the cache?
Have you refreshed the strings?

After string refresh it deleted also strings which were used and usefull:

Performing cleanup for text group field, deleting 11 left over strings.
Successfully refreshed 323 strings for Fields
Deleted 11 left over strings.

Some translation of field names (labels) was deleted. It's a bug.

Please try the latest release 7.x-1.14
and if that doesn't resolve:
please try the latest dev 7.x-1.x-dev which is ahead of 7.x-1.14

make sure to run update database (drush updb if you use drush)

might be a configuration issue as well. Is this node translation or entity translation?

I'm facing the same issue.

I tried what Joseph said but it didn't work.

I noticed that in the first time that i refresh the string if the box "Clean up left over strings." checked it didn't remove my translation. It only remove my translation in the second time that i refresh the string with the box "Clean up left over strings." checked.

First Refresh:
- Performing cleanup for text group field, deleting 3057 left over strings.
- Successfully refreshed 4693 strings for Fields
- Deleted 3057 left over strings.

Second Refresh:
- Performing cleanup for text group field, deleting 1 left over strings.
- Successfully refreshed 4693 strings for Fields
- Deleted 1 left over strings. (This 1 string couldn't be deleted. It was translated)

@Garuggi,
what module / label / entity type / field / are you having trouble translating?

Did you make sure the t() function is called for the label (in the code) and appropriate substitutions for variables.

also, is this a string in Javascript , if so, are you using the Drupal API to handle /insert your javascript (the t() function is available in javascript if you're correctly using the drupal api)

with your description, need more details

#2829507: String refresh deletes field translations is possibly a duplicate of this issue. Not sure

Confirmed bug, needs work

Just a quick note where i think the problem lies:

In i18n_field.i18n.inc:47 we have title, description and default_value:

function i18n_field_i18n_object_info() {
...
  $info['field_instance'] = array(
    'title' => t('Field instance'),
    'class' => 'i18n_field_instance',
    'key' => array('field_name', 'bundle'),
    'placeholders' => array(
      '%bundle' => 'bundle',
      '%field_ui_menu' => 'field_name',
    ),
    'edit path' => 'admin/structure/types/manage/%bundle/fields/%field_ui_menu',
    // We can easily list all these objects.
    'list callback' => 'field_read_instances',
    // Metadata for string translation.
    'string translation' => array(
      'textgroup' => 'field',
      'properties' => array(
        'label' => array(
          'title' => t('Label'),
        ),
        'description' => array(
          'title' => t('Description'),
          'format' => 'format',
        ),
        'default_value' => array(
          'title' => t('Default value'),
          'format' => 'format',
        ),
      ),
      //'translate path' => 'admin/structure/types/manage/%bundle/fields/%field_ui_menu/translate/%i18n_language',
    )
  );
  return $info;

While in i18n_field.inc:145 we only have default_value ("only for text types" seems reasonable).
So on string refresh titles and descriptions are deleted.

class i18n_field_instance extends i18n_field_base {
...
  protected function build_properties() {
    $properties = parent::build_properties();
    $object = $this->object;
    $field = field_info_field($object['field_name']);
    // Only for text field types
    if (!empty($object['default_value']) && i18n_field_type_info($field['type'], 'translate_default')) {
      $format = isset($object['default_value'][0]['format']) ? $object['default_value'][0]['format'] : NULL;
      $properties[$this->get_textgroup()][$object['field_name']][$object['bundle']]['default_value']['string'] = $object['default_value'][0]['value'];
      $properties[$this->get_textgroup()][$object['field_name']][$object['bundle']]['default_value']['format'] = $format;
    }
    return $properties;
  }

Fiddling together the 2 missing lines might make it work...

Copied better summary from the dup.

I just found a similar bug that we had some years ago with the form fields. It may gives some clue for this current bug. https://www.drupal.org/node/1483942

Hey guys any updated here?

I have the problem as well. I first started to suspect Token module, but a relevant patch is already in version 1.7.

No matter what I do I cannot preserve the translations I've exported using features translations, but strangely not every installation is effected. While it works on one installation, on two others it's stating that "Source string not found" when I use the translation UI.

Another strange thing ... some descriptions are working. Example: 4 content types with the same field (i.e. title_field): article, teaser, event and topicpage. While description seems to work for the latter 3, its always lost for the first one.

Its not limited to title field. Same happens for entity reference fields, text fields, paragraphs field, lists, an so on.

If we can get detailed instructions on how to consistently repeat this observed behavior in a test environment then we can more easily find a solution. What language mode is the administration interface in when the translations are captured in a feature? And what language is the administration interface in when the strings are refreshed, not sure if that makes a difference.

The more detailed the steps the better. I have started making drush make files to capture core version, patches, contrib module and versions and patches and also libraries. For an example drush make for drush version 7.x or drush 8.x see my sandbox project bolstrap. In my project I have a make file in there.

So detailed steps, suggesting a make file with all dependences, then configuration, capture it in a feature and upload it to this issue.

Likely is NOT an issue with the i18n module.
See a fix for an implementation of i18n_string
#1483942: String translations are being deleted on "Refresh strings"

I18n_string is provided by i18n

Actually, might be worthwhile making a patch based on #11 and running it through a simpletest

Hi, sorry for my bad english.

This is the steps for reproduce the error.

Install:
- Drupal
- Field translation
- Menu translation

Go to admin/config/regional/language and
- add a language

Go to admin/config/regional/translate and
- take a note for the total number of strings for the fields and for the menus

Go to admin/config/regional/translate/i18n_string and
- select fields and menu
- select "clean up left over strings"
- refresh strings

Go to admin/config/regional/translate and
- check that the total number of strings has not been changed

Go to admin/config/regional/translate/i18n_string and
- select fields and menu
- select "clean up left over strings"
- refresh strings

Go to admin/config/regional/translate and
- you can see that the fields strings now are 0/0

To restore the original situation, go to the admin/config/regional/i18n/strings page and
- select "Text group handler default." for all text group in the fieldset
- save configuration (you need to save also if the radiobutton was "Text group handler default."... is needed for set some variables)

Go to admin/config/regional/translate/i18n_string and
- select fields and menu
- select "clean up left over strings"
- refresh strings

Go to admin/config/regional/translate and
- you can see that the fields strings now are 0/[original value]

To break even the menu strings (or other textgroups) go to admin/config/regional/i18n/strings page and:
- select "Text group handler which include persistent caching." for all text group in the fieldset
- save configuration

Go to admin/config/regional/translate/i18n_string and
- select fields and menu
- select "clean up left over strings"
- refresh strings (now we have populated the cache... is needed another refresh for break the strings. so...)
- select fields and menu
- select "clean up left over strings"
- refresh strings

The problem seems to be on the i18n_string_textgroup_cached class.
The difference in behavior between fields and other text groups is caused by different default values until you go to the admin/config/regional/i18n/strings page and save (even without modifying anything)

Attached a patch that standardizes the behavior between fields and other textgroups, making it work by default.

Unfortunately now I have no time to investigate the problem due to the selection of "Text group handler which include persistent caching."

I have closed the following issues #3034388: Refresh and cleanup strings removes all source strings #2801873: After string refresh module deleted also strings which were used and usefull: as duplicates of this issue

I have the same problem, debug it and whole problem is that after updating translated strings, textgroup field cache is not reset. That is why it behave strange and it looks that some translated strings has been lost (but they appear correctly after clear cache).

I have tested patch submitted in #21 and it fixed the issue, but I think better approach is to add cache reset for field textgroup after translation update. So I attach the patch with this change.

Thanks, looks good to me! Just one minor comment nitpick, but can be fixed on commit.

+++ b/i18n_field/i18n_field.module	(date 1670322486866)
@@ -163,6 +163,26 @@
+ * Field extra translation form submit function

Comments should end with a dot.

Thanks everyone for the fix, this has been an annoyance for a long while and good to be fixed.

Here you go,

https://www.drupal.org/project/i18n/releases/7.x-1.32

thanks for the reviews and the patience!