internationalization for rails platform

gistfile1.md

Strategy for internationalization of rails platform

Configuration of I18n module:

I18n basic configuration already done in CircuitVerse platform.Changes can be done according to file structure of locales we will use

Locale Setup:

can be done in two ways : 1> define explicitly or by inferring locale

• Using HTTP GET parameters for setting up locale
• Using domain name
• Setup locale according to user preference (Via forms and UI widgets)
• Using subdomain
• Using routing scopes
• Through HTTP accept_ language_header
• Geolocation using geocoder gem
• Setting locale using user sessions and cookies

Different areas to handle to translate circuitverse platform::

Quality translation for strings::(addon)

machine translation or computer assisted translation or human translation .

Strategy for key management::

• naming should be explicit - helps to find the location of keys easily, finding and debugging will be easier, reduce collision of keys.(lazy lookups can be used wherever it is necessary).

  eg: considering page.views.index.title will be good than '.title'

• keys can be divided into two types - general keys with prefix "general" and normal keys

  • general keys - for general words repeating throughout the apps (sign up login etc).

    eg: all general keys will start with prefix as 'general' i.e general.save, general.edit, general.search

  • normal keys - for all other translations naming will be done according to what the current field represents or by purpose of key. In case content is edited in future then the key will be still in sync with content.

    eg:home.user_welcome_text

    i am trying here to keep nesting upto max level 3 in worst case.

• style of key - snake case or camel case.

Dividing translation process according to different sections of rails::

• views and mailers - most of the static strings present here. descriptive lookup preferred using meaningful namespaces than lazy lookups.

• model - model attributes and validation error messages with appropriate namespaces. model attributes will have a separate translation model to store their translated version. namespace for validation error messages can be created like "errors.messages.*".

• forms - labels input_text field and submit - all three elements using helper method names as namespace can be translated.

• controllers - mostly contain flash messages . prefix can be their purpose or method they are encapsulated in.

             ```	eg:user.create.success ```
  

• helpers - meaningful names used which defines a purpose of key and not that it is a helper key.

  eg:project.name considering as good namespace over helper.project.name

Styles for translation function

can be found in four different styles.

• defining keys explicitly - short but meaningful

  t('landing_page.how_things_work')

• introducing defaultMessage attribute in translation function

     key: 'landing_page.how_things_work', 
     defaultMessage: "Things explained"
    }) ```
    
  

• straight forward: word which is translated used as a key

  t('How things work')

• using symbol instead of strings-

  t(:app_name) this equivalent to t('app_name')

  there are many other lookup techniques like lazy lookup ,use case can be considered where required

Documenting rules followed for localization::

We need to discuss and define localization rules by using above points for CircuitVerse so that same rules can be used during project implementation and by future contributors too. documentation of rules will help to introduce new keys and modify existing ones easily without any conflicts

Tests (test for integrity)::

we can put code for integrity test of yml files against current locale which is set, to cross check correct yml is served for current locale which is set this is very common case where sometimes wrong translation can get served for different locale

File organization/Namespace/Nesting

• for views - in three ways locale can be organized in views we have different folders (consider "user" folder) in user there can be different folders (consider "sessions" folder in "user" folder)

  • views/users/sessions - this will be more modular approach, keys for files present in sessions folder will be in "users.sessions.*" namespace

     eg:
     user: 
      sessions:
    <all strings present in sessions folder>
    

  • views/user - all the keys for all the folders present in the "user" folder can be in one namespace "user.*" without further division for subfolders present in user folders

    eg
    user:
    <keys for all strings present in user folder>
    

  • /views - all the keys for views in any one particular namespace (hard to managed)

    2nd approach seems more fine to me as some subfolders can have more or less keys and decrease the level of nesting.

• models - can be done in two ways

  • adding a localized form of attribute (a separate column) for each attribute in each model. not preferred as it is not scalable and very hard to manage db tables
  • Adding a separate translation model for each base model . it is preferred as it is scalable and easy to manage

Gems to be used:

• i18n gem - already been used by circuitverse
• i18n-js -already been used by circuitverse
• mobility gem - model translation can also be done by manual method or using mobility gem .
• i18n-tasks - to correct/remove orphaned and missing keys

Some of open source tools for internationalization

https://opensource.com/article/17/6/open-source-localization-tools A list of tools can be seen here , I am researching on those tools to grab the best one according to our needs from each section.

Translation fo dynamic content::

use of mobility gem via by creating separate translation model

Passing locale used by user on site to mobile app

• adding locale attribute in user api
• mechanism for retriving locale and set for flutter user