explanation on GitHub is scarce
Try the binder! An example of a downstream extension of it is jupyterlab-myst.
Why should exactly this plugin be extended?
If only concentrating on markdown (and not e.g. code comments), that plugin offers an alternative markdown renderer to marked, used everywhere in JupyterLab, called markdown-it. Unliked marked, markdown-it is much more extensible (though there are still some challenges).
Out of the box it already supports things like mermaidjs, which is now supported by GitHub-flavored markdown.
In this approach, translations would appear as close to its neighbor content as possible, inside the same field of the notebook format. The idea would be to offer a new markdown syntax (or ideally reuse an existing one, but I don’t know of one), e.g.
```{@en title}
# Hello World
```
```{@de title}
# Hallo Welt
```
The extension would then offer rendering the blocks only of a specific language(s) based on user preference, or offer like-named language blocks as e.g. tabs.
But now there’s a new syntax that no other tooling understands.
This syntax could then also be implemented in nbconvert, or markdown-it-py so that this behavior could get out to a sphinx site with myst-nb or the whole jupyter-book contraption.
one central Jupyter Notebook
keeping the information “close,” but not inside the same field, I actually explored implementing a prototype intermediate solution back in classic, using cell metadata. Unfortunately, it was not open source… but worse yet, was also not based on any standard.
This required a bunch of metadata to work well (e.g. keeping track of the source that had been translated for each language) and didn’t work very well with revision-control-based workflows, and probably wouldn’t work very well with the CRDT-based stuff unless the internationalization metadata scheme became a well-known notebook format (like kernel_info).
stored in another file
The advantage to this approach is… it already exists! By knowing identity of the whole file, and how to extract what needs to be translated given the entire document, one could extract markdown, code comments (with knowledge of the kernel) and a raft of other aspects, and be able to know exactly what needed to be changed.
some other software
Right, the idea would be to enable the editing of these files, in the right context, in JupyterLab, which is much better at doing more than one thing at a time.
There are a number of existing pieces of software from which to draw inspiration, and this would result in something that improved the usefulness of JupyterLab for more than just writing special syntax in markdown.
If this worked well with jupyterlab-git and jupyterlab-pull-requests, and even jupyterlite, then there would already be a semi-portable workflow for doing doing translation work and looking at history.
For example, we currently rely on a SaaS solution to manage the effort for internationalizing JupyterLab… this is great for a big open source project, but would not scale to thousands of individual groups working on individual notebooks.