Scope should be larger

[PeterWone]

While it's great that you are looking at providing a formalised solution for localisation of extension strings this is not all that hard once you get past the total lack of documentation. What's hard is coordinating incremental updates when you have a contributor per translation. For example, I do English and French, and I have colleagues who speak English and Spanish, or English and Italian, or English and Icelandic. Every time I release a minor version, I have to coordinate changes to

• readme
• changelog
• UI (settings descriptions etc)
• UI dialog messages
• manual

I can almost hear you drawing breath to say that github does diffs.

It's not good enough.

• It's spread all over the place.
• There's no coherent way to see what languages have been updated and which haven't.

What's required is tooling to manage localisation.

• Tooling to identify translation candidates (literal strings)
  • ignore replacement tokens because these are already being localised
  • ignore literals found in an ignore list
• Tooling to emit difference files requiring translation as a single file for the translator
• Tooling to update the NLS source files from the translated difference file.

If you ask me this begs for implementation as a VS Code extension.

What are your thoughts?

[TylerLeonhardt]

I really like these ideas and I like the idea of having l10n-dev be about the localization dev experiences. That's why I recently added this pseudolang command: https://github.com/microsoft/vscode-l10n/pull/20 which is more of a helper than it is required.

Can you break this up into individual issues of the tools/commands you wish to see so we can evaluate them one by one? That will also help folks who may want to contribute.

There's a lot we can do here, and I am but one person.... so any assistance is greatly appreciated :)

[PeterWone]

I'm in a handy situation where every member of my dev team at work speaks English and one other natural language. Several of them contribute translations to one of my projects. I told them you responded positively and we're workshopping the idea so as to get a more balanced view. One of the things I want to examine is the interplay between version control, maintainer workflow and translator workflow. This should tell us the activities tools and commands must support.

Originally I imagined an extension because it's inherently cross platform, but another possibility is CLI tools, maybe on top of gulp because it's already there for people doing localisation.

[TylerLeonhardt]

The beauty of building a CLI that also had code entrypoints is that we can do both a CLI & a VS Code extension to assist folks. Not entirely sure what an extension would do to help besides be a Command Palette wrapper around the CLI

[PeterWone]

I had a notion of a split view of source and target language for the translator. It's not central.

[TylerLeonhardt]

Yeah that sounds really nice. If it were a web extension, I like the idea of pointing someone to a vscode.dev/github/.... url where they can contribute without cloning the repo locally

[PeterWone]

Another idea was to sketch out the translations using Azure translate so that translators just skim and take a hand when the sense is wrong or particular idiom is required as is often the case for software.

[TylerLeonhardt]

sketch out the translations using Azure translate

This sounds awesome.

[PeterWone]

Tyler, sorry to vanish off the face of the Earth... having a day job will do that. Especially if you also have a rural property to run.

GitHub retired node12 which forces a cascade of updates... and caused me to rediscover this package. Congratulations on the implementation of the Azure Translate idea, it's very nice.

You may be interested in translate.mjs which is a little js app I put together for my release workflow. It uses marked to parse Markdown documents into structural elements so it can present them to Azure Translate and then reconstruct the document. You can't just stuff a Markdown string through Azure Translate, it borks the document in its punctuation translation pass, eg for French it converts all backticks to apostrophe, and then System.Json.Text (which it uses) converts all the apostrophes to \u0027.

If you want to have a look, it's here at the moment but will end up in the root of master.