dvodvo

dvodvo

dvodvo

dvodvo

dvodvo

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

dvodvo

This is intended as a 'minimal amount of steps' to get Mobility running properly

• rails generate mobility:install
• edit `config/initializers/mobility.rb` 
   - uncomment `dirty`</li>
   - uncomment `locale_accessors` and set desired locales
• rails db:migrate
• setup model
  extend Mobility
  translates :synopsis, type: :string

dvodvo

Any form, no object, just data to send, all you need is the target action route
       form_with url: posts_path do |form| 

Form for object, you add it **generically** to the tag.  But `@post` still needs to be defined in the controller action
       form_with scope: :post, url: posts_path do |form|

Form for object, safe for both post and patch paths.  define `@post` in the controller action
       form_with(model: @post) do |form|

Form for object, but you want to be lazy and not define `@post` in the controller action