Skip to content

Globalization

Fernando Blat edited this page Apr 18, 2017 · 9 revisions

Lets do a quick analysis of the costs of implementing it. Lets add items in each category (and add any you think should be here)

Cases

(listing possibilities, not meaning we should implement everything. But to think about the cost of doing certain cases)

  • CMS Module: support localized pages, localize both title and content.
  • Site: name, entity name and html blocks
  • People module:
    • People: name, position, bio,
    • Event: name, description
    • Statement: name
    • Blog: title, content
  • Content blocks: field names are already translated, we need to translate the content
  • Budgets module:
    • when we enable budget line description, entities might want to have it in N languages
    • if a new category is imported
  • Consultations: title, description, budget lines
  • ...

Implementation

  • Each model attribute that might be translated could be localized in any of the locales of the Site
  • There's always a fallback to the site default locale
  • Application should never raise an error if there's a missing translation
  • Priorities:
    1. CMS Pages (simplest scenario)
    2. Site
    3. People module
    4. Content blocks
    5. Consultations or Budgets

Design

We should try to define a homogeneous patten in the form controls to:

  • allow users to translate a field in multiple locales in a simple way (JS switch between locales, without having to submit the form each time)
  • allow users to know in which locales the content has been translated and which are pending

Markup

Code

The most popular option is https://github.com/globalize/globalize. Globalize fits very smoothly in Rails models.

There's another option for PostgreSQL that uses JSONB columns: https://github.com/cfabianski/json_translate and implements an API inspired by Globalize.

Content blocks might require more thinking, because they are not a common model, they serialize the content, and we might need a custom solution (for example: serialize the content for each locale)

Briefly the process should be:

  1. Implement localization in admin forms
  2. Use localized attributes in the front
  3. Migrate all the current content to a locale (the default site locale)

Issues

Clone this wiki locally