You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Per the comment in both the TMX and XLIFF versions of FilenamesToAddToCache, we "Prefer the custom localizations folder version if it exists, otherwise the installed language folder." The problem with this is that a user might supply some missing translations, creating a custom localization. Even if they share those translations back to the developers and they are incorporated into a later version of the program, they'll continue to use their custom version, unless they are instructed to delete their local custom file so the program can use the "official" versions. That not only means that newly added or improved versions of strings for existing IDs will get ignored but -- even worse -- new translations for new string IDs will get ignored! I could not understand why I wasn't able to see the newly added translated strings for new string IDs until I stepped through the code and saw that comment.
This is probably fairly low exposure since very little field-based translation is probably happening for languages that have official translations. But it's pretty confusing and annoying when it does occur.
The text was updated successfully, but these errors were encountered:
Ideally, we should be able to detect when the new official version covers 100% of the existing custom strings and blow away the local copy. (If all custom localizations are present but some of the strings are different, we can continue to let the local copy stay around.)
Per the comment in both the TMX and XLIFF versions of FilenamesToAddToCache, we "Prefer the custom localizations folder version if it exists, otherwise the installed language folder." The problem with this is that a user might supply some missing translations, creating a custom localization. Even if they share those translations back to the developers and they are incorporated into a later version of the program, they'll continue to use their custom version, unless they are instructed to delete their local custom file so the program can use the "official" versions. That not only means that newly added or improved versions of strings for existing IDs will get ignored but -- even worse -- new translations for new string IDs will get ignored! I could not understand why I wasn't able to see the newly added translated strings for new string IDs until I stepped through the code and saw that comment.
This is probably fairly low exposure since very little field-based translation is probably happening for languages that have official translations. But it's pretty confusing and annoying when it does occur.
The text was updated successfully, but these errors were encountered: