-2

To help others and myself learn new human natural languages I want to create a program for translating phrases shared between generally all such languages ("basic phrases").

Although, using this program should require to know the writing system of the language that a user desires to translate to.


With Drupal, such program would likely contain two content types:

  1. English
  2. Translation

The English content type will include one node named English, containing headings and underlying tables of basic phrases:

<h2>English</h2>

<h3>Greetings</h3>

|[node:tltle]|
|------------|
| Hello      |
| Please     |

<h3>Conditionals</h3>

|[node:tltle]|
|------------|
| If         |
| Else       |

A user could add a node of the Translation content type and this node should have the name of a Non-English language; say, Russian.
The Russian node would automatically look like this:

<h2>Russian</h2>

Dear user, please double click a basic phrase to translate it,
per how you assume it should be translated:

<h3>Greetings</h3>

|[node:tltle]|
|------------|
| Hello      |
| Please     |

<h3>Conditionals</h3>

|[node:tltle]|
|------------|
| If         |
| Else       |

After double-clinking a cloned English term for in-place translating, and translating correctly:

Hello → Здравствуйте
Please → пожалуйста

If → Если
Else → еще

My problems

I don't know how to automatically give Translation nodes the same content of English node.

I also don't know how to allow the user to actually double click to in-place translate the already-copied English basic phrase in that Translation node (without going to in-place edit mode before).

Possible solution

Unifying nodes content by a view page:

  1. Creating a pattern node with a list of headings and empty underlying tables contexts created from plain text fields with one or more values
  2. Manually copying that pattern node to both English node and Russian node and manually filling these nodes with basic terms in each language
  3. Creating a view page combining both nodes and properly format so that for the end user both nodes will appear as two adjacent groups of headings and underlying tables (two adjacent contexts)

This is a complicated solution forcing users to do identical architectural changes in two or more nodes each time:
Imagine you have to update the same contextual group in two or more language nodes instead doing level-headed changes in two or more columns of the same table rows, in a single node.

My question

As the Views solution is hard to maintain, is there another solution?

  • I would say that's not possible using just the core. You will need contrib modules and probably a custom module. Besides that, maybe there are other approaches. A few questions: Do all the translation nodes have the same table? From your example this would mean all translation nodes would have The "If", "Else", "Hello" and "Please" entries and the "Greetings" and "Conditionals" groups. I guess not, each translation node would have a custom set of phrases. And and more important, those translations are Drupal string translations (from Drupal internationalization system) or just regular content? – sanzante Dec 5 at 17:50
  • @sanzante thanks; each language node (Russian, French, etc) should have the same exact tables of basic phrases for translation; the basic structure or pattern of these tables will be taken directly from the English node which should serve a starting point or pattern for all other language nodes. – JohnDoea Dec 5 at 18:09
  • The content should be regular --- all content inputted by a user; nothing should be taken from Drupal (or from any other program). – JohnDoea Dec 5 at 18:09
  • Do you accept solutions with contrib modules and/or custom modules? – sanzante Dec 5 at 18:24
  • 2
    What you are describing seems like a huge workaround for what the core translation of Drupal 8 already offers. Are you aware of the lexicon building options that Drupal provides, i.e. through the "Translate Interface" interface? – Stefanos Petrakis Dec 5 at 18:26
2

I would go for the following solution, using core's content translation (this is IMO the canonical way to deal with your issue):

  1. Enable the desired languages on your Drupal installation
  2. Create a simple translatable (custom entity type or content type) called translation, having a title and a value field (and maybe a type which refers to a contextual "heading").
  3. Make your translatable content type named translations-(basket)
  4. Add an non-translatable entity reference field for each contextual heading to the translation entity (using the type of translation needs a custom Entity Reference Selection plugin)
  5. User's now could edit the translation entities, when you provide an overview (fe. using views or using the content overview)
  6. Using inline entity form makes the translations editable on the translations(-basket) node(s) in edit-mode. To expose that in the view-mode it would need a custom form (basically duplicating the edit form) showing this fields to the user.

Further information about setting up inline entity form properly:

  • Use the "Inline entity form - complex" form display for the entity reference fields and allow creation and duplication of entities
  • Gain control over the IEF Table by providing your own EntityInlineForm (by overriding getTableFields) for the translation entity

To achieve this optional enhancements a small custom module is needed holding the selection plugin, the custom entity (it's kind of tricky to make translatable ones ...), the custom EntityInlineForm and maybe the custom form to expose the edit capabilities to the node's view-mode.

If you want to go with this solution, I'm willing to showcase crucial code parts for the optional enhancements.

2

As already mentioned, this can be done with nodes and the content translation module, but I think it will be better to create a custom entity to hold this data. The reason for this is that you have to switch language to see the different translations, so they will not be shown in the same table.

So, your custom entity will have following fields:

  • Heading (contextual/dynamic value).
  • Phrase (fieldset or field group + cardinality unlimited).
    • Text field for default language.
    • Text field for each of the other languages.

I think this solution will be a clean solution and you’ll also have all the data gathered one place.

To get the functionality of writing a translation placeholder in the fields, you can create a custom field formatter that prints the field value inside a t() function, then you can translate that string in the translation interface to get the correct text shown for all languages.

For the in-line editing you can use the Inline Entity Form module as already mentioned.

NB IEF only allows you to edit the translation placeholders inline, if you want to be able to edit the translations inline you have to make some custom code, maybe a modal that gets the translation for the translation placeholder and sets the translation based on the user input. To get and set the translations you can use the translation manager, it has two methods you can use, getStringTranslation and translate.

Good luck, I’ll be happy to help you further if you choose this solution.

PS If you’re not familiar with creating custom entities you can use the Entity Construction Kit module to help you create the entity. That reduces the amount of code you have to write :)

Hope it all makes sense!

Not the answer you're looking for? Browse other questions tagged or ask your own question.