Towards incorporating multiple languages in the linkml-docs

[matentzn]

This is a technical follow up on linkml/linkml#1937 (any general discussion on multilang should go there).

@sujaypatil96 I am wondering how you could see multiple languages concretely realised as part of the docs. A complex solution would involved a language switcher. But not sure this already exists properly, e.g. squidfunk/mkdocs-material#2346. But even on a simpler level. Would it be possible to somehow display language translations of schema elements right then and there when compiling the docs? What if the translations live in a different file (TSV, YAML or otherwise)?

[matentzn]

@sujaypatil96 just following up on this! Do you have any time to look into how the above could look like?

[cmungall]

I am worried that this will add a lot of complexity. It's already hard to maintain this and other cookiecutter repos, test against edge cases, etc.

I would recommend people who need this try it in a fork and report back

[noelmcloughlin]

I am not sure cookiecutter can do much in this area - its end of the food chain.

Core Linked Data Standards and Generators should be addressed by https://github.com/orgs/linkml/discussions/2896

The Ecosystem of generators will build on Core LinkML Solution:

1. language specific mapping generation:

   • Typescript: Populate messages/ directory - used by inlang/paraglide-js for example.
   • Python/Pydantic: Populate gettext (./locale) and/or babel (./translations) directories
   • Java: Populate messages_<lang>.propertiies files for Java ResourceBundle and Spring Messagesource?
   • Rust: Populate locales/ directory - (rust-i18n)[https://crates.io/crates/rust-i18n/1.2.2]

2. documentation mapping generation:

   • No native mkdocs solution so Setting up multi-language installations squidfunk/mkdocs-material#2346 is best path.

3. Database frameworks mapping generations: TBC