Issue with findBySource / parseFromDeveloperNote

[fvet]

I've a label (don't mind the Dutch caption that should have been translated in English ;)) that contains a developer comment for the nl-BE language.

MessageLbl: Label 'Aantal mag niet gewijzigd worden als er een transferregel voor deze inkoopregel bestaat: in inkoopregel Documentsoort=%1, Documentnr.=%2, Regelnr.=%3.', comment = 'nl-BE="Aantal mag niet gewijzigd worden als er een transferregel voor deze inkoopregel bestaat: in inkoopregel Documentsoort %1, Documentnr. %2, Regelnr. %3."';

Using following settings ...

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

... I'd expect the Xliff file to contain the proper Dutch translation, although it seems truncated?

<trans-unit id="PageExtension 1255613137 - Method 716454850 - NamedType 3071485667" size-unit="char" translate="yes" xml:space="preserve" al-object-target="PageExtension 1255613137">
          <source>Aantal mag niet gewijzigd worden als er een transferregel voor deze inkoopregel bestaat: in inkoopregel Documentsoort=%1, Documentnr.=%2, Regelnr.=%3.</source>
          <target state="translated">Aantal mag niet gewijzigd worden als er een transferregel voor deze inkoopregel bestaat: in inkoopregel Documentsoort %1</target>
          <note from="Developer" annotates="general" priority="2">nl-BE="Aantal mag niet gewijzigd worden als er een transferregel voor deze inkoopregel bestaat: in inkoopregel Documentsoort %1, Documentnr. %2, Regelnr. %3."</note>
          <note from="Xliff Generator" annotates="general" priority="3">PageExtension CustomerListExt - Method OnOpenPage - NamedType MessageLbl</note>
        </trans-unit>

Could you please guide me in the good direction if I would miss any setting to extract the right Dutch translation from the developer comment?

Here's a repro + sample project.

ALProject21.zip

Thanks!

[rvanbekkum]

Hi @fvet, I think your setting of xliffSync.parseFromDeveloperNoteSeparator might explain this. You have set it to ,, but the 'translation for nl-BE' also contains commas. XLIFF Sync splits based on the character(s) specified in this setting. Does this explain it for you? I think you might be best off using a different separator, but if you have other ideas, please let me know.

[fvet]

Hi Rob, this indeed explains the source of the issue, but I'm a bit reluctant on changing the parameter.

Some background:

We used https://marketplace.visualstudio.com/items?itemName=ClipDynamics.al-language-tools for several years and now want to migrate to Xliff Sync without changing a lot of our habits, snippets, source code, ....

AL Language Tools expected translations in format below

Caption = 'English Text', comment = 'ESP="Text in Spanish",ITA="Text in Italian"';

Via https://marketplace.visualstudio.com/items?itemName=BartPermentier.al-toolbox, we're also using various snippets to add translations in comments / regex validation (https://github.com/BartPermentier/al-toolbox/blob/dcc44da9f0b1ad445f89bf1e016218643dd4105d/src/codeAnalyzers/XLF/checkTranslations.js#L33) (similar to the Xliff Sync snippets, but I want to avoid our devs having to switch to use other snippets)

We're almost there with Xliff Sync, with the lastest support for parseFromDeveloperNoteTrimCharacters. Would it be possible when parsing translations from the developer note, to not just split on just the separator only, but take into account the parseFromDeveloperNoteTrimCharacters?

Caption = 'English Text, comma separated', comment = 'ESP="Text in Spanish, comma separated",ITA="Text in Italian, comma separated"';

[rvanbekkum]

It would be possible to take into account.

A good alternative would be to choose a character (a sequence of characters should work as well(!), see https://github.com/rvanbekkum/ps-xliff-sync/pull/29) that XliffSync will split on, to avoid splitting inside of the translation.

[fvet]

Hi Rob, any chance of including support for this in a not so far release? The impact of changing to another character is too large due to the number of projects / repositories.

[rvanbekkum]

Hi Frédéric, Sorry for the later reply (I was enjoying a good holiday 😇). I can see if I can include something for it in the next release, but I also expect to be quite busy with other things in my free time, so I am not sure when I will be able to work on this and make a new release.

[fvet]

@rvanbekkum We decided to switch using || instead as separator.

No longer needed to spend any effort on this issue ;)