The tools automates the extraction of strings to be externalized from TS and JS code. It therefore help localizing VSCode extensions and language servers written in TS and JS
public static failedToEnumerateFilesInDir(path: string, errCode: string, errMessage: string): string {
return localize(
{
key: 'Failed.To.Enumerate.Files.In.Dir',
comment:
[
'Error message when failed to enumerate files in a directory.'
]
},
`Failed to enumerate files in directory '{0}'. Error code={1}, Error message={2}`,
path,
errCode,
errMessage
);
}
When targeting ES5, all is well. But once we target ES6, the backtick as a quote character is preserved:
static failedToEnumerateFilesInDir(path, errCode, errMessage) {
return localize({
key: 'Failed.To.Enumerate.Files.In.Dir',
comment: [
'Error message when failed to enumerate files in a directory.'
]
}, `Failed to enumerate files in directory '{0}'. Error code={1}, Error message={2}`, path, errCode, errMessage);
}
This causes vscode-nls-dev to fail during build with this error:
libraryResourceStrings.js(661,11): second argument of a localize call must be a string literal.
For now we workaround it by changing our own use of backtick to single quotes. But that requires much more escaping in our English strings because we use single-quotes inside the localizable string.
We have this code that vscode-nls-dev rewrites:
When targeting ES5, all is well. But once we target ES6, the backtick as a quote character is preserved:
This causes vscode-nls-dev to fail during build with this error:
For now we workaround it by changing our own use of backtick to single quotes. But that requires much more escaping in our English strings because we use single-quotes inside the localizable string.
Please enable use of backticks.