Hotfix - Improve the rebuilding of target XLF files #7
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We rewrote the
writeTargetFiles
method inbase.js
to iterate on existing XML trans-units (based on the source XLF file) instead of iterating on the segments from the Translation.io response.This ensures that all XML trans-units for which we compute the same
uniqueIdentifier
will be filled with the same target from the Translation.io response.This fix is put in place after one of our users noticed that some XML trans-units were not filled with the target during a sync.
Indeed, the angular i18n-extractor creates two separate trans-units for sources that "seem" identical but are actually padded with spaces:
Our package purposely trims any leading or trailing space when processing sources, so this results in only one segment being sent to Translation.io.