rvanbekkum / ps-xliff-sync

A PowerShell module to synchronize and validate XLIFF translation files.
MIT License
14 stars 5 forks source link

Different Developer closing note when syncing xliffs via PS vs VS Code #38

Closed fvet closed 1 year ago

fvet commented 1 year ago

VS Code

Settings

"xliffSync.autoCheckMissingTranslations": true,
    "xliffSync.autoCheckNeedWorkTranslations": true,
    "xliffSync.needWorkTranslationRules": [
        "OptionMemberCount",
        "OptionLeadingSpaces",
        "Placeholders",
        "ConsecutiveSpacesConsistent",
        "ConsecutiveSpacesExist"
    ],
    "xliffSync.parseFromDeveloperNote": true,
    "xliffSync.parseFromDeveloperNoteOverwrite": true,
    "xliffSync.parseFromDeveloperNoteSeparator": "||",
    "xliffSync.findBySource": true,
    "xliffSync.findBySourceAndDeveloperNote": true,
    "xliffSync.parseFromDeveloperNoteTrimCharacters": "\"",
    "xliffSync.preserveTargetAttributesOrder": true,

When packaging an app in VS Code, I get following trans-unit id in the g.xlf file

<trans-unit id="Codeunit 2906659059 - NamedType 2580332125" size-unit="char" translate="yes" xml:space="preserve">
          <source>Suggests to open the Drinkmaster 365 apps landing page</source>
          <note from="Developer" annotates="general" priority="2"></note>
          <note from="Xliff Generator" annotates="general" priority="3">Codeunit ESCG Drinkmaster Notification - NamedType NotificationDescriptionTxt</note>
        </trans-unit>

Running the 'Synchronize Translation Units' in VS Code results in following trans-unit id in the nl-BE.xlf file

<trans-unit id="Codeunit 2906659059 - NamedType 2580332125" size-unit="char" translate="yes" xml:space="preserve">
          <source>Suggests to open the Drinkmaster 365 apps landing page</source>
          <target state="translated">Stelt voor om de Drinkmaster 365 apps landingspagina te openen</target>
          <note from="Developer" annotates="general" priority="2"/>
          <note from="Xliff Generator" annotates="general" priority="3">Codeunit ESCG Drinkmaster Notification - NamedType NotificationDescriptionTxt</note>
        </trans-unit>

PowerShell

Script

$AppFolders = @("App")
$SyncAdditionalParameters = @{
    "preserveTargetAttributesOrder"   = $true
    "findBySource"                    = $true 
    "findBySourceAndDeveloperNote"    = $true
    "parseFromDeveloperNote"          = $true
    "parseFromDeveloperNoteOverwrite" = $true
    "parseFromDeveloperNoteSeparator" = "||"
    # parseFromDeveloperNoteTrimCharacters" = "\""
}

Test-BcAppXliffTranslations -printProblems -appFolders $AppFolders -translationRules @("OptionMemberCount", "OptionLeadingSpaces", "Placeholders", "ConsecutiveSpacesConsistent", "ConsecutiveSpacesExist") -restrictErrorsToLanguages @("nl-BE", "nl-NL") -buildProjectFolder $BuildProjectFolder -syncAdditionalParameters $SyncAdditionalParameters

This results in following trans-unit id in the nl-BE.xlf file


<trans-unit id="Codeunit 2906659059 - NamedType 2580332125" size-unit="char" translate="yes" xml:space="preserve">
          <source>Suggests to open the Drinkmaster 365 apps landing page</source>
          <target state="translated">Stelt voor om de Drinkmaster 365 apps landingspagina te openen</target>
          <note from="Developer" annotates="general" priority="2"></note>
          <note from="Xliff Generator" annotates="general" priority="3">Codeunit ESCG Drinkmaster Notification - NamedType NotificationDescriptionTxt</note>
        </trans-unit>

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.

rvanbekkum commented 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.

fvet commented 1 year ago

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.

rvanbekkum commented 1 year ago

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.

rvanbekkum commented 1 year ago

A new parameter -useSelfClosingTags has been added to Sync-XliffTranslations in version 1.9.0.

b-zijlstra commented 1 year ago

A new parameter -useSelfClosingTags has been added to Sync-XliffTranslations in version 1.9.0.

Great work! Unfortunately I am still getting whitespace difference.

b-zijlstra commented 1 year ago

A new parameter -useSelfClosingTags has been added to Sync-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>

.xlf - VsCode: `` .xlf - Powershell: `` .xlf - VsCode - useSelfClosingTags : `` .xlf - Powershell - useSelfClosingTags : ``
rvanbekkum commented 1 year ago

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.

b-zijlstra commented 1 year ago

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.