LIT default translations don't update correctly

[bkroeker]

Changing the default translation does not correctly update the value in LIT. Here's the behaviour, as best I can tell.

t('key_one', default: 'My Translation') # => 'My Translation'
t('key_one', default: 'A different translation') #=> 'My Translation'

t('key_two') # => missing translation
t('key_two', default: 'My Translation') #=> 'My Translation'
t('key_two', default: 'A different translation') #=> 'A different translation'

In the former case, 'My translation' is saved as the translation for 'key_one' in the database, and used for all subsequent translations. In the latter case, null is saved as the translation for 'key_two' in the database, and any provided defaults will take priority for all subsequent translations while maintaining null in the database.

Neither case is ideal. What I'd ideally expect to see is that any passed defaults will be saved in LIT and will overwrite any existing value in LIT unless the translation was flagged as human approved, at which point it should be locked.

An example scenario where this is relevant is when I, as a developer, wish to provide more detail in a translation, or fix a typo. My improved default won't actually be applied, because the original default was saved when the translation was first instantiated.

[mlitwiniuk]

Actually given, that there is no easy way to deal with this, we've decided to leave this as it is. Checking if value has been "accepted" would require checking db and/or redis on every call, which is time-consuming and very expensive. On translation-heavy pages significant amount of time is spent on contacting redis alone (that's why there is experiment with speeding this up and caching values in memory - https://github.com/prograils/lit/tree/speed_up_by_using_memory_cache ). Unless you have viable (fast!) solution how to deal with changing default value, I'd prefer to close this issue,

[bkroeker]

I haven't fully familiarized myself with thin ins and outs of LIT, so forgive me if I'm off the mark. But if you're already hitting redis or memory to fetch the translated value, couldn't you also fetch the is_changed flag in the same request? I believe that's the flag you use to determine if the given value is accepted or not, and it would presumably follow the same cache invalidation rules as the actual translated text.

Then, once received, you could compare the values. If the default passed into the method is different than the translation received from redis, and the redis result indicates that is has not yet been accepted, then you know you can return the passed-in default, and need to update the database with the new default.

This might increase the complexity of the payload stored in redis a little bit, and would add a comparison or two, but doesn't strike me as requiring a huge performance hit. I could be missing something though.