dvodvo/gist:f7e3fac76e3db3d4adbc37448a8b709f

## gistfile1.txt
Until further notice, i.e. a documented mechanism to run **multiple backend** for an application, the following is a tactical approach to leveraging the Mobility gem.
Motive: consideration of different focus of data - assume global(or central) and local(or decentral) - leads to different polyglot and data requirements locally. One size does not necessarily fit all well.

the key_value backend has its advantages and inconveniences in this context.
*Advantages*
• easily extendible
• good for high volume of translated data
( the other advantages documented here remain true https://dejimata.com/2017/3/3/translating-with-mobility )
*Inconveniences*
• all locale data converges to a single table, which would service the multiple databases of the application
• such a table mixes local-use data with global-use data and makes eventual syncronisation difficult.

Thus, considering centralised global data - limitless locales to handle & wider scope of translatable attributes to handle.
The key_value approach is the obvious candidate.

Ideally, for local values, having a jsonb column would be ideal, as it would be populated with only the required local attributes and locales.
It is flexible in data handling and is efficiently queried.
It may still be possible, but that would require either setting up a parallel syntax (that does not conflict with Mobility)
or querying via SQL
  `SELECT "posts".* FROM "posts" WHERE (posts.title @> ('{"en":"Translating with my own handling mechanism"}')::jsonb)`
making controllers a lot more messier.  Even with a parallel syntax, controllers end up messier (mental gymnastics of what follows a given backend where...)

Thus, two options remain: table-based or column-based. It remains a working assumption that there are local-only data requirements - what attributes and locales needs to be presented. These could populate a distinct database (clarifying data management and maintenance issues).  Column-based approach is valid only if the number of attributes and locales is limited (otherwise views become geometrically difficult to manage) and not prone to too much evolution.

Two tables of translations (one for strings, one for text) with minimum attributes
• klass,
• polyglot_attribute,
• locale
will provide significant lifting capability without too much complexity.  The combo `klass, polyglot_attribute, locale` being uniq
	Until further notice, i.e. a documented mechanism to run multiple backend for an application, the following is a tactical approach to leveraging the Mobility gem.
	Motive: consideration of different focus of data - assume global(or central) and local(or decentral) - leads to different polyglot and data requirements locally. One size does not necessarily fit all well.

	the key_value backend has its advantages and inconveniences in this context.
	Advantages
	• easily extendible
	• good for high volume of translated data
	( the other advantages documented here remain true https://dejimata.com/2017/3/3/translating-with-mobility )
	Inconveniences
	• all locale data converges to a single table, which would service the multiple databases of the application
	• such a table mixes local-use data with global-use data and makes eventual syncronisation difficult.

	Thus, considering centralised global data - limitless locales to handle & wider scope of translatable attributes to handle.
	The key_value approach is the obvious candidate.

	Ideally, for local values, having a jsonb column would be ideal, as it would be populated with only the required local attributes and locales.
	It is flexible in data handling and is efficiently queried.
	It may still be possible, but that would require either setting up a parallel syntax (that does not conflict with Mobility)
	or querying via SQL
	`SELECT "posts".* FROM "posts" WHERE (posts.title @> ('{"en":"Translating with my own handling mechanism"}')::jsonb)`
	making controllers a lot more messier. Even with a parallel syntax, controllers end up messier (mental gymnastics of what follows a given backend where...)

	Thus, two options remain: table-based or column-based. It remains a working assumption that there are local-only data requirements - what attributes and locales needs to be presented. These could populate a distinct database (clarifying data management and maintenance issues). Column-based approach is valid only if the number of attributes and locales is limited (otherwise views become geometrically difficult to manage) and not prone to too much evolution.

	Two tables of translations (one for strings, one for text) with minimum attributes
	• klass,
	• polyglot_attribute,
	• locale
	will provide significant lifting capability without too much complexity. The combo `klass, polyglot_attribute, locale` being uniq