8

I'm trying to design a schema paradigm in MongoDB which would support multilingual values for variable attributes in documents.

For example, I would have a product catalog where each product may require storing its name, title or any other attribute in various languages. This same paradigm should probably hold for other locale-specific properties, such as price/currency variations

I've been considering a key-value approach where key is the language code and value is the corresponding value:

 { 
      sku: "1011",
      name: { "en": "cheese", "de": "Käse", "es": "queso", etc... },
      price: { "usd": 30.95, "eur": 20, "aud": 40, etc... }
 } 

The problem is I believe this would deny me of using indices on multilingual fields. Eventually, I'd like a generic, yet intuitive, index-able design.

Any suggestion would be appreciated, thanks.

ChenR
  • 161
  • 2
  • 8
  • What's your final choice on this topic? @ChenR – calfzhou Aug 03 '15 at 07:56
  • @calfzhou wow, it's been so long since then :) – ChenR Aug 03 '15 at 07:59
  • 1
    @calfzhou that particular project was abruptly cut shortly after this question, In another (Meteor) project I used this pattern: ``` { sku: "1011", name: "cheese", color: "yellow", i18n: { "de": { name: "Käse", color: "Gelb" } } } ``` this pattern in Meteor allowed me to expose only the desired language by referring to the top-level 'i18n' object, and replacing the top-level properties with those inside the i18n object (where available) e.g. product.name // == "Käse" in DE mode Regardless, I still think the originally posted pattern is good – ChenR Aug 03 '15 at 08:05
  • 3
    Thanks @ChenR very much! I'm using Ruby, and mongoid as my MongoDB driver, and just found that mongoid supports [localized fields](http://docs.mongodb.org/ecosystem/tutorial/ruby-mongoid-tutorial/#localized-fields) with very simple statement: `field :description, localize: true`, which internally `stores the field as a hash of locale/value pairs`, and might be similar with your way. – calfzhou Aug 03 '15 at 14:26

1 Answers1

6

Wholesale recommendations over your schema design may be a bit broad a topic for discussion here. I can however suggest that you consider putting the elements you are showing into an Array of sub-documents, rather than the singular sub-document with fields for each item.

{ 
    sku: "1011",
    name: [{ "en": "cheese" }, {"de": "Käse"}, {"es": "queso"}, etc... ],
    price: [{ "usd": 30.95 }, { "eur": 20 }, { "aud": 40 }, etc... ]
} 

The main reason for this is consideration for access paths to your elements which should make things easier to query. This I went through in some detail here which may be worth your reading.

It could also be a possibility to expand on this for something like your name field:

    name: [
        { "lang": "en", "value": "cheese" },
        { "lang": "de", "value: "Käse"  },
        { "lang": "es", "value": "queso" },
        etc...
    ]

All would depend on your indexing and access requirements. It all really depends on what exactly your application needs, and the beauty of MongoDB is that it allows you to structure your documents to your needs.

P.S As to anything where you are storing Money values, I suggest you do some reading and start maybe with this post here:

MongoDB - What about Decimal type of value?

Community
  • 1
  • 1
Neil Lunn
  • 148,042
  • 36
  • 346
  • 317