I would like to propose a few potentially useful features on i18n of Forem and hear from the community. I may create a PR with the described spec if people see fit. Any suggestions are welcome.

Mechanism to create and link translations of a post

Overview

Great posts inspire translation. To attract wider global users in and keep the community's ecosystem self-sustained, the feature provides a systematized way to create a translation from an existing post, and navigate across all translated versions of the post when they exist. It most likely requires the language tag property for articles.

It will be built on the same ID all the translation family share. They normally share the same original post. Sometimes there could be re-translation, but we can expect for practical purposes that their contents are functionally equivalent.

All existing language versions are shown inside a small navigation on the top of post view (above or below the Series component) for every post belongs to the family, so that people can jump across each other.

You can make a new translation by a button attached to the page. When you do, the system prompts you to select language and opens a new editor, prefilled with the original post content.

IIUC It can be independently added to the current build of Forem (as of Aug 17, 2021), without interacting with any other functions except the requirement above.

Related

Option to write the same article in different speaking languages #890

chrisvasqm posted on Oct 12, 2018

Describe the solution you'd like As a writer, I would like to be able to provide different versions of my article to support other languages (spanish, english, etc).

Describe alternatives you've considered Perhaps something like having a dropdown menu or toggle for both writers and readers could satisfy this.

View on GitHub

Spec

Model

• add translation bigint field/column in Article
  • it copies the original post's ID as a family ID (null if no translation)
  • alternatively there could be a relation table (ID - translation ID); while I believe an additional column is more elegant, I'm not sure which is more efficient when pulling a list of translation.

View

• add a <details> element somewhere on the top of the post view if it has one or more other language versions
  • in <summary>: Available in other languages:
  • inner content (for example): Original: English • German • French (1), (2) • Japanese • Klingon (each with link)
  • looks somewhat like the header strip of this page when open
  • not showing when the only translation is unpublished
• add a [Translate post] button somewhere on the post view
  • opens a modal
• add a "Create translation" modal on the post view
  • let the user select language
  • warn if translation already exists in the language
• add a hidden field translation in the editor UI (v2)
  • not sure if meaningful to visibly expose the (to-be) translation family ID to users, since a post ID is not easily got from the current UI

Controller

• once the user proceeds from the "Create translation", transition to a new editor view, with the original title, cached_tag_list, body_markdown, translation (or OP's ID if none) copied in, and new target language value (text_lang) filled.
  • perhaps adding a line WIP translation at the beginning of body
  • what if they use v1 editor?
• when the translation post is submitted, check the original post whose ID = translation ID, and if the translation field of OP is null, give it the same value.

Discussion

• When the original post is deleted, the family ID needs no change.

  • But should notify in the translation nav that original is deleted.
  • You can create a new translation from one of remaining versions with the same ID.

• Each language name in nav best be in its native spelling.

• What if the original post is deleted and reposted?

  • Ask admin?