Support localization of multiline strings

[ghost]

The localize function provided by the vscode-nls module doesn't seem to support multiline strings. I've tried multiple ways of formatting multiline strings, like:

localize("msgId", "line1" +
  "line2");
localize("msgId", `line1
line2`);

Any of these attempts at localizing multiline strings in source code result in an error at build time.

[stepanzharychevbroadcom]

I've tested exactly what was suggested in the issue. From this configuration: It produces proper multiline string without any issues in JS and changes new lines to spaces for VSCode system messages.

The alternative working way is: Produces similar results.

@jellypuno @Colin-Stone @zFernand0 I think we can close it.

[ghost]

@stepanzharychevbroadcom Has it been tested that npm run package also runs successfully with multiline strings being localized?

[stepanzharychevbroadcom]

@tjohnsonBCM Build results with error due to vscode-nls-dev dependency, which cannot digest ES6 string as string literal for some reason. I will spend some more time with this one trying to figure out if our setup is incorrect, but if it's not we can't do anything about it, because the problem is not on our side.

src/extension.js(85,38): second argument of a localize call must be a string literal.

[VitGottwald]

This looks like a limitation of vscode-nls-dev we are currently not able to address. Downgrading to ES5 would cause other problems - we use async/await a lot and this would convert all of the code into generators, require a polyfill and generally degrade development and debugging experience.

[VitGottwald]

@tjohnsonBCM do you think we should make this a higher priority? If so I think we should have a broader discussion about how we do localisation.

[ghost]

I don't necessarily think this issue should have higher priority than others which are already in milestones. However, I agree it may be good to have a broader discussion about how we do localization, as we have multiple issues with the Localization label.

On another note, it surprises me that the vscode-nls-dev package doesn't seem to be maintained much anymore and hasn't been updated to support ES6 syntax. It still seems to be the recommended method by Microsoft for adding i18n support to a VSCode extension (their i18n sample still uses it).

[VitGottwald]

@tjohnsonBCM I have not given much time yet to see how vscode-nls-dev works internally, but the idea of extracting strings from source code and massaging them for translation afterwards seems dubious to me. I believe localisation should be baked in the architecture and explicit in code.

[phaumer]

Isn't the danger to make the string non-translatable to other languages? I see examples where strings were fragmented (e.g. in Line 167 in DatasetTree.ts, initializeFavorites.error.profile1), which will make will make it hard to translate as differences in grammar will result into fragments of different length or even empty ones in other languages. If the multi-line layout fits in one language it might not fit in another.

[JillieBeanSim]

This would be an enhancement request, removing bug label. We have started work on a new localization plan with the following: We have adopted the newer l10n Also have WIP for WIP Allow users to contribute translations with POEditor closing this issue also due to lack of activity for 4 years.