Changes in Key-Value Formats
A change in the way an upload of a source file affects the translations for it was deployed earlier today.
When a maintainer of a project uploads an updated source file, Transifex will extract all entries from the file and save them in the database. At the same time, it will invalidate all translations for the entries that were changed or deleted completely.
Until now, Transifex would look only at the identifier of the entry, to determine, whether the entry had actually changed. For instance, in PO files this is the
msgid part of an entry. On the other hand, if the value (source string) of the entry had changed, Transifex would just update the source string, without any effect on the translations for that entry.
The reasoning for this behavior was that in most formats the source string is placed in and extracted from the source code; that is, the identifier for an entry is the source string itself. As a result, any changes in the source string would affect the identifiers, too.
However, there are certain formats that are used in a different way. In these cases, the source code only contains a key as a placeholder for the string instead of the string and the source string lives in a key-value like file. There are many formats that fall in this category, like Java .properties files, YML for Ruby On Rails and Joomla .ini files. The typical workflow in these cases is to never change the key in the source code, but update the source string in the source file instead (the value for that key).
For this reason, Transifex changes the way it works for this kind of formats to better suit this workflow. So, it invalidates the translations for an entry, when the source string changes, even if the identifier is still the same.
This change should not affect in any way the day-to-day operations for any project that does not want to benefit from this feature.