Fields that aren't translatable aren't updated in the index on languages that aren''t the current language

When an entity is saved / updated, only the current language index item is updated for that entity_id. This results in non-translatable fields becoming out of sync between languages. For example, suppose you have

• A multilingual site (English and French) - set to update items immediately
• A simple node index
• A view using the index, showing only "promoted" nodes
• A node (nid:1) with a french translation

Now suppose you edited that node while on the English site and changed the "promote" field to 1. The english entry in the index will have the correct value, but the french entry won't. Here's a sample xml search result from a solr implementation (I removed non-pertinent fields for brevity):

<response>
  <result name="response" numFound="2" start="0">
    <doc>
      <bool name="bs_promote">false</bool>
      <str name="content">Ju Suis en Français</str>
      <str name="hash">jkcc5w</str>
      <str name="id">jkcc5w-node_index-fr_1</str>
      <str name="index_id">node_index</str>
      <str name="item_id">fr_1</str>
      <str name="ss_field_colour">Noir</str>
    </doc>
    <doc>
      <bool name="bs_promote">true</bool>
      <str name="content">I am in English</str>
      <str name="hash">jkcc5w</str>
      <str name="id">jkcc5w-node_index-en_1</str>
      <str name="index_id">node_index</str>
      <str name="item_id">en_1</str>
      <str name="ss_field_colour">Black</str>
    </doc>
  </result>
</response>

Now, if you were visit your hypothetical view (mentioned above) on the English site, it will correctly show us node 1, but if you visit it on the french site, it won't list the node.

Note that I have also tested this with an actual non-translatable field as well (as opposed to a node property) and the problem is the same.

The solution I would propose for this is to update all indexed languages on entity_update. There is a patch in Comment #4 of #2429539: When a node is updated, it is removed from searches' results until the next cron run. that adds this functionality. I'm hesitant to post it here, however, so as not to take credit from the original Author. Also, the issue he is fixing is technically different than mine (although the solution is the same).

I'd be interested to know if other people are having this same issue. It seemed quite odd to me that anyone else using this module wouldn't have noticed it. I don't think the example I gave wasn't especially unique, but I could be wrong...

Thanks!
drclaw