Is your feature request related to a problem? Please describe.
Collectives is not so good for maintaining documentation in multiple languages at the moment.
Describe the solution you'd like
I imagine an optional feature (to be toggled on/off per collective) that allows to provide translations of pages in different languages. On a page that has translations available, it should be possible to switch between the translations. When opening a page without language parameter, the translation should be selected from the browsers locale, with a fallback.
Ideally a default language could be selected and pages in this language regarded as "source of origin". Translations could be marked as "up-to-date" and would be marked outdated once the source page got changed.
Describe alternatives you've considered
Maintain separate collectives for each language with a similar page structure.
Maintain one collective with different languages as first level pages and similar page structure below.
Maintain one collective with one global page structure and translated pages next to each other.
All of these solutions bring different maintainability issues.
Additional context
I don't have a good idea how to map page translation files yet. One option would be the convention to use Title.<language-code>.md as filenames. But that would bring the problem how to translate page titles, as currently the page title is hardcoded in the markdown filename.
Hello @mejo- great idea!
I don't know if it's applicable but maybe you could take inspiration from Pretix (open source ticketing software) and how they manage multi-language markdown pages for event descriptions.
Is your feature request related to a problem? Please describe. Collectives is not so good for maintaining documentation in multiple languages at the moment.
Describe the solution you'd like I imagine an optional feature (to be toggled on/off per collective) that allows to provide translations of pages in different languages. On a page that has translations available, it should be possible to switch between the translations. When opening a page without language parameter, the translation should be selected from the browsers locale, with a fallback.
Ideally a default language could be selected and pages in this language regarded as "source of origin". Translations could be marked as "up-to-date" and would be marked outdated once the source page got changed.
Describe alternatives you've considered
All of these solutions bring different maintainability issues.
Additional context I don't have a good idea how to map page translation files yet. One option would be the convention to use
Title.<language-code>.md
as filenames. But that would bring the problem how to translate page titles, as currently the page title is hardcoded in the markdown filename.