Localise media paths in walkthroughs

[PeterWone]

For context see https://github.com/microsoft/vscode-l10n/issues/180

Strings directly defined in walkthroughs can be localised with the usual %walkthroughs.mykey% mechanism.

However, walkthroughs depend heavily on references to resources like images and Markdown documents.

  "walkthroughs.howToPrint.title": "Premiers pas avec l’impression",
  "walkthroughs.howToPrint.description": "Découvrez l’impression dans l’éditeur pour le code source et la documentation.",
  "walkthroughs.steps.printEditorActive.title": "Imprimer l’intégralité du contenu de l’éditeur actif",
  "walkthroughs.steps.printEditorActive.media": "assets/print-entier-content-editeur-actif.fr.md",

As you can see in the above excerpt from a package.nls.fr.json, the path to walkthroughs.steps.printEditorActive.media was inappropriately localised.

After some discussion on the linked issue, our tentative proposal is

1. Define a token {locale}
2. Path strings requiring this kind of localisation are marked by the presence of {locale}
3. Localise them by replacing the token with the locale code for each generated file

This approach makes no assumptions about the structure of the resource path; the locale might name a directory, or it might be part of the filename. It does require that resource filenames for the default language have literal {locale} in the name or path. The below examples are in the context of contributed settings in package.json

  "walkthroughs.steps.printEditorActive.media": "assets/print-entire-content-active-editor.{locale}.md",

or

  "walkthroughs.steps.printEditorActive.media": "assets/{locale}/print-entire-content-active-editor.md",

This should extend to the properties of object values.

"media": {
	"image": "media/image.{locale}.png",
	"altText": "%walkthroughs.foo.media.altText%"
},

[vs-code-engineering[bot]]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[PeterWone]

It would be prudent to check that the value also contains a slash to reduce false positives; if there's both a slash and the symbol it's almost certainly a path with a symbol and not text that just happens to contain the symbol. For remaining edge cases people will just have to escape some part of it.