microsoft/vscode-l10n

Further multiline issues

tehcrashxor opened this issue · 2 comments

tehcrashxor commented

While there were a couple PRs fixing #63, looks like there are still issues with multiline strings and multiline comments.

Multiline Strings:

Running npx @vscode/l10n-dev export on

vscode.l10n.t("multiline\ntest")

produces a bundle.l10n.json with

{
  "multiline\\ntest": "multiline\\ntest"
}

Generating an XLF with npx @vscode/l10n-dev generate-xlf removes that extra escape slash to

<trans-unit id="++CODE++60babcaf5bf8760815f018b47248ffc2935c9f5c6a2a0cc34cea133139bce3c7">
  <source xml:lang="en">multiline\ntest</source>
</trans-unit>

but importing a translated version with npx @vscode/l10n-dev import-xlf produces a bundle.l10n.*.json with

{
    "multiline\\ntest": "FAKE TRANSLATION multiline\\ntest",
}

At runtime, the bundle matching fails, as the search string is just using \n, but the bundles (both created via export and import-xlf) have \\n causing a lookup miss and displaying the original English text.

TylerLeonhardt commented

One issue per issue helps chip away at the problems. I opened the multi-line comment issue here:
#77

fixed in microsoft/vscode#171125

  • 👍1
TylerLeonhardt commented

Yeah something isn't right with the newlines because I would have expected their other form in the XLF:
https://github.com/microsoft/vscode-l10n/blob/main/l10n-dev/src/xlf/xlf.ts#L216-L221

but I guess I didn't realize that JSON.stringify doesn't include the \n in the file....... it escapes it and causes \\n to show up in the file. This is odd to me... maybe it's a JSON spec thing... but I wasn't expecting that escaping.

I'm thinking the best way forward is to mirror this on the client... and make sure this:
https://github.com/microsoft/vscode/blob/054e96fda29eda1a71c0943d2eb83374c1225267/src/vs/workbench/api/common/extHostLocalizationService.ts#L45
escapes the \n (and \r for that matter)

So that they can be aligned.