Closed fvet closed 1 year ago
Would this change "https://github.com/rvanbekkum/vsc-xliff-sync/pull/110" that will be available with the next release of vsc-xliff-sync already help? With this change you can specify what you would like to do with closing tags.
The suggested change will probably do!
Not sure if this setting will also be available in the PS version of Xliff Sync (to keep the list of supported settings in sync between both Xliff Sync extensions). As long as I've a method to ensure the output from the VS Code and PS sync is similar, that would be great.
The option is available in version 1.4.0.0 of vsc-xliff-sync. I will see if I can also make a similar setting available in the PowerShell module.
A new parameter -useSelfClosingTags
has been added to Sync-XliffTranslations
in version 1.9.0.
A new parameter
-useSelfClosingTags
has been added toSync-XliffTranslations
in version 1.9.0.
Great work! Unfortunately I am still getting whitespace difference.
A new parameter
-useSelfClosingTags
has been added toSync-XliffTranslations
in version 1.9.0.
Great work! Unfortunately I am still getting whitespace difference.
g.xlf:
<note from="Developer" annotates="general" priority="2"></note>
Correct, I noticed this as well, it is the .NET/XmlDocument's default behaviour for empty tags, so I decided to leave it like this for now.
Do you have any suggestions on what might be good to align it? I could do a "text replace" of />
with />
if -useSelfClosingTags
is enabled, or something like that, but it would be a bit of an ugly solution.
Having that extra space seems like a decent default behaviour, so I understand keeping it. I would change the result from VsCode to match the Powershell output, but that risks breaking everyone elses workflows I guess.
My main concern is that, like fvet, I don't want to trigger git changes for the closing tags everytime I send my VsCode synced files through our build pipeline.
I'll just update our VsCode setting to not use the self closing tags. That will give us a lot of changed lines once, but that's not an issue.
VS Code
Settings
When packaging an app in VS Code, I get following trans-unit id in the g.xlf file
Running the 'Synchronize Translation Units' in VS Code results in following trans-unit id in the nl-BE.xlf file
PowerShell
Script
This results in following trans-unit id in the nl-BE.xlf file
Issue
These seems to be a difference in the sync results (I guess my settings in VS Code and PS should be the same) when ran in VS Code vs Powershell.
<note from="Developer" annotates="general" priority="2"/>
<note from="Developer" annotates="general" priority="2"></note>
In our pipelines, we perform a compile step, then run a Test-BcAppXliffTranslations step and conditionally re-compile the app with the updated xliffs. The re-compile is ran conditionally espc. to save build time when no changes to translation file changes had been detected (checked via Get-FileHash).
However, due to the differences in above results, the re-compile is always ran. Any advice / inputs or possible fix?
PS: Another nice option would be if Test-BcAppXliffTranslations could return whether any of the xliff files has actually changed by the command.