Recommended design of graph DB structure for translations?

[mrtnzlml]

I am looking for a good design of a graph database structure that would deal with translations/localization. So far, my research lead me to these (not very satisfying) questions on SO:

• https://stackoverflow.com/questions/19924253/best-practice-for-storing-multi-language-property-values-in-neo4j
• https://stackoverflow.com/questions/10693508/database-modeling-for-international-and-multilingual-purposes
• https://stackoverflow.com/questions/23802834/multilingual-data-modeling-on-mongodb

How to approach it the best way? Say I have a restaurant (document vertex) in restaurants collection:

{
  "name": "El Cardenal",
  "description": "Typical local restaurant…"
}

How to approach the translations of the description (and other props but probably not the name)? Some designs suggest to have a separate vertex (with a translation edge having the actual language there):

                translation
restaurants    ------------->    restaurants_i18n

Others suggest to use the same document for translations like so (or any other structure):

{
  "name": "El Cardenal",
  "description": "Typical local restaurant…",
  "i18n": {
    "es": {
      "description": "Restaurante típico local…"
    }
  }
}

There are possibly many other interesting designs I don't know. Which one would be the one and what are pros/cons of each of them? 🤔

[michalsanger]

I like the approach where translations are in the same document. Looks like a clean approach from the document DB perspective, but I don't have much experience with document databases.

[mrtnzlml]

For the record - I am currently trying a combined approach:

1. Fields that need translations and are closely related to the object are stores as follows:

{
  "_id": "xyz",
  "something": "without translations",
  "translations": {
    "en_US": {
      "title": "Title in English",
      "description": "Description in English",
    },
    "es_MX": {
      "title": "Title in Spanish",
      "description": "Description in Spanish",
    },
  }
}

2. Fields that are common to more object are in a separate collection (so I don't have to repeat them in every document). The structure is something like this (more info: https://www.arangodb.com/docs/stable/aql/tutorial-join.html):

{
  "_id": "xyz",
  "en_US": "piece",
  "es_MX": "pieza",
}

Both of these solutions have the following in mind:

• there is no "main" language, but there has to be at least one version
• these objects can be resolved directly in DB without needing any application logic
• it works well together with the search capabilities of the DB I am using (I can search across languages or not)