Content localization Proposal

How to configure:

var Article = new keystone.List('Article', {
	autokey: { from: 'name', path: 'key', unique: true }
});

Article.add({`
    name: { type: String, required: true, translatable: true },
    description: { type: String, translatable: true },
    href: { type: String, translatable: false}`
});

DB structure possibilities:

1. Put all localized fields into one main document

• + no reference traversal
• + might be easily implemented with virtuals
• - big documents
• - growing documents
• ? impact on indexing

1. store an embedded document per field with sub-fields per language (keyed by language code)

1. **language-code keys**
  
  - **+** dead simple
  - **-** bloat through many keys (on the good side, language codes are very short and compress well)
  - **-** many projection criteria (one per translated field) when retrieving localised document

  article_links:
  
      {
        _id: 'fhdsjfs',
        href: 'http://some.website/some/page',
        name:
        {
          en: 'Great Article',
          de: 'Toller Artikel'
        },
        description:
        {
          en: 'This is the best article I've ever read!',
          de: 'Das ist der beste Artikel, den ich jemals gelesen habe!'
        }
      }

2. **index-based language coding**

  - **+** no key bloat
  - **-** change in translated languages might require big database update
  - **-** many projection criteria (one per translated field) if retrieving localized fields
  - **?** impact on indexing 
  
  l10n:
  
      {
        languages: [ 'en', 'de' ]
      }
  
  article_links:
  
      {
        _id: 'fhdsjfs',
        href: 'http://some.website/some/page',
        name: [ 'Great Article', 'Toller Artikel' ],
        description:[ 'This is the best article I've ever read!', 'Das ist der beste Artikel, den ich jemals gelesen habe!' ]
      }

2. store an embedded document per language with sub-fields per translatable field

- **+** quite simple
- **+** simple projection criterion when retrieving localised document
- **-** bloat through many keys (field keys can be any length, but compress well)

article_links:

    {
      _id: 'fhdsjfs',
      href: 'http://some.website/some/page',
      l10n:
      {
        en:
        {
          name: 'Great Article',
          description: 'This is the best article I've ever read!'
        },
        de:
        {
          name: 'Toller Artikel',
          description: 'Das ist der beste Artikel, den ich jemals gelesen habe!'
        }
      }
    }

2. Put localized fields into one or more extra collections

• + no growing documents
• - additional overhead through referencing (when indexing on anything but the main _id)
• ? impact on indexing
• ? harder to implement

1. one collection for translations containing one document per language and main document

article_links:
  
    {
      _id: 'fhdsjfs',
      href: 'http://some.website/some/page'
    }

article_links_l10n:

    {
      article_links_id: 'fhdsjfs',
      language: 'en',
      name: 'Great Article',
      description: 'This is the best article I've ever read!'
    }

    {
      article_links_id: 'fhdsjfs',
      language: 'de',
      name: 'Toller Artikel',
      description: 'Das ist der beste Artikel, den ich jemals gelesen habe!'
    }

2. one collection per language containing one document per main document

- **-** many collections

article_links:
  
    {
      _id: 'fhdsjfs',
      href: 'http://some.website/some/page'
    }

article_links_en:
  
    {
      article_links_id: 'fhdsjfs',
      name: 'Great Article',
      description: 'This is the best article I've ever read!'
    }

article_links_de:

    {`
      article_links_id: 'fhdsjfs',
      name: 'Toller Artikel',
      description: 'Das ist der beste Artikel, den ich jemals gelesen habe!'
    }