Handling all available versions/translations of the lesson as equals

[amsichani]

During our discussions on how to group together multiple translations under one banner/ alert message #1738, we were also puzzled on how to handle the alert message notifying on the original version of the lesson. Actually , the current architecture of this message is only set to notify on the English original of the lesson, presupposing that the original will always be English , privileging somehow English as the first/ original language .
{{ site.data.snippets.translation-source[page.lang] }} {{ site.data.snippets.language-name.en[page.lang]}}

While this might be an interesting technical quiz for us to solve, it reveals a more fundamental question on what is the overall benefit of keeping this distinction between original and translation of a lesson, while we are growing into a project with multiple equal publications: there are multiple and equal versions of the same lesson. We will soon have an English translation of ES original lesson, and perhaps later a Portuguese translation of a FR original. This is a very welcomed 'Babel', from my point of view, and we should celebrate and actually enhance this type of growth and collaboration between publications. If a user or a team member wants to find the 'genealogy' of a lesson, she can find everything in the metadata at the start of the lesson (date, translator etc) / code. Other than that, I cannot see the point of keeping these distinctions.

We @walshbr @jenniferisasi and @amsichani are in favour of treating all available versions / translations of a lesson as equals, once they are created, and to present them as such in the lesson's page. We 'd like to propose also a technical solution for this idea: replace the source /original alert message and the (multiple) translations messages on the lesson with a more clear layout, following this rationale:

Available in: EN | ES | FR | PT | XYZ

We could use the language buttons we are having in the top of the page, but this might confuse users regarding entry points.

We welcome suggestions, ideas, thoughts, theoretical and technical.

[mdlincoln]

There's no underlying data assumption that the originals are in English. If you swap out that .en call to [translation_source.lang] then you'll get the right language for the source. You could post up a lesson right now in Spanish, translate it to English, add the correct original metadata to the English lesson, and the links would be generated. The snippets file already contains the translations under translation_source

translation-source:
  en: This lesson was originally published in
  es: Esta lección fue publicada originalmente en
  fr: Cette leçon a été à l'origine publiée en

There IS an underlying assumption that all pages (not just lessons) have an "original" source. That's baked in to the translation link mechanism as I lay out in the documentation.

You could have pages be entirely free-floating entities without assuming an acyclic graph relationship of one original -> many translations. The tradeoff would be that you would need to add to the YAML metadata of every single page what the links are to every other language, instead of relying on Jekyll to infer those links.

[mdlincoln]

That said, it's also just fine to keep the underlying original->translation data model, but simply display Available in: EN | ES | FR | PT | XYZ

[mdlincoln]

though I imagine you'd want to make sure "Available in" was using the current page lang, not just english

[amsichani]

thanks for these comments @mdlincoln . I will now close this ticket as the information and discussion is now on #1767