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
the transifex gh app supports 2 way sync, with the strings in this repo as the source of truth in merge conflicts. it'd be good to have a solid, tested, understanding of this behavior
one example i'd like to test is:
we have 20 strings in a file
one is updated in the repo
20 are updated in transifex
sync is run
is the app smart enough to resolve conflicts there by only syncing the one string up to transifex? or do all the new translations in transifex get wiped by the sync?
The text was updated successfully, but these errors were encountered:
one argument for keeping 2 way sync is for fixing format variable issues that aren't caught in transifex, but simply updating the strings in transifex when those issues are found has been proposed as an alternative solution
For existing resources that have already been synced with GitHub, if translations are found in GitHub, they will be sent to Transifex only if no translations are found for that language in Transifex
knowing this, it seems we should stick to the idea of transifex as a source of truth for all translated strings, and any updates should happen in transifex
the transifex gh app supports 2 way sync, with the strings in this repo as the source of truth in merge conflicts. it'd be good to have a solid, tested, understanding of this behavior
one example i'd like to test is:
is the app smart enough to resolve conflicts there by only syncing the one string up to transifex? or do all the new translations in transifex get wiped by the sync?
The text was updated successfully, but these errors were encountered: