ateapick

Un'alternativa a Globalize: GetText + Model Localization Plugin

Globalize è un ottimo plugin che copre tutti gli aspetti legati all’internazionalizzazione di un’applicazione Rails, tra cui:

  • Traduzione dei testi “statici” (View Translations)
  • Traduzione dei testi “dinamici” (Model Translations)
  • Localizzazione di date, numeri, valute etc…

Il setup del plugin provvede alla crazione di 3 tabelle sul database già popolate con le informazioni di localizzazione relative a 239 paesi e con le traduzioni comuni (es. giorni della settimana) in 186 lingue.

Sia le View Translations che le Model Translations vengono scritte sul database ed è possibile, quindi, creare un’area (riservata) dell’applicazione che si occupi esclusivamente del CRUD delle traduzioni, gestibili quindi in autonomia dall’utente finale.

La necessità di un’alternativa a Globalize è nata col tempo a partire da alcune considerazioni:

  • “Ho veramente bisogno delle informazioni di localizzazione di 239 paesi e 186 lingue se il mio sito supporterà al massimo le 5 lingue europee più comuni?”
  • “E’ corretto gestire nello stesso modo la traduzione delle parti statiche e dinamiche di un sito?”
  • “Sono realmente necessari tutti gli accessi al database effettuati da Globalize per la localizzazione?”

Le risposte, nel mio caso, credo siano a questo punto evidenti; in particolare ritengo che ci sia una sostanziale differenza tra i due tipi di traduzioni che giustifica la ricerca di due soluzioni diverse.

Per le traduzioni statiche ho scelto (ad oggi con soddisfazione) di utilizzare GetText e la sua implementazione in ruby. A questo indirizzo è disponibilie una guida molto chiara da cui iniziare.

Per le traduzioni dinamiche non sono riuscito a trovare niente di adeguato alle mie esigenze per cui ho scritto un plugin per la localizzazione dei modelli che, unito a GetText, completa la soluzione all’internazionalizzazione da me adottata.

Il suo funzionamento è molto semplice. Supponiamo di avere il model Task con un attributo name che vogliamo rendere traducibile in inglese e francese.

Attraverso una migrazione aggiungiamo gli attributi che conterranno le 2 traduzioni:

    1 class AddTranslationsToTaskName < ActiveRecord::Migration
    2   def self.up
    3     add_column :tasks, :name_en, :string
    4     add_column :tasks, :name_fr, :string
    5   end
    6 
    7   def self.down
    8     remove_column :tasks, :name_en
    9     remove_column :tasks, :name_fr
   10   end
   11 end

Il plugin estende ActiveRecord definendo il metodo localize che si usa così:

    1 class Task < ActiveRecord::Base
    2   localize :name
    3 end

A questo punto basterà utilizzare l’attributo preceduto da un underscore (in perfetto stile GetText) sia nelle form, per la modifica (riga 5):

    1 <h1>Editing task</h1>
    2 
    3 <% form_for(@task) do |f| %>
    4   <%= f.error_messages %>
    5   <p><%= f.text_field :_name %></p>
    6   <p>
    7     <%= f.submit "Update" %>
    8   </p>
    9 <% end %>
   10 
   11 <%= link_to 'Show', @task %> |
   12 <%= link_to 'Back', tasks_path %>

che in visualizzazione (riga 3):

    1 <h1>Showing task</h1>
    2 
    3 <p><%=@task._name%></p>
    4 
    5 <%= link_to 'Edit', edit_task_path(@task) %> |
    6 <%= link_to 'Back', tasks_path %>

La lingua in cui viene modificato o visualizzato l’attributo è la lingua corrente.

Chiaramente nel momento in cui dovessi affrontare lo sviluppo di un’applicazione in 20 lingue, tra cui l’arabo e il giapponese, tornerei a prendere in seria considerazione l’adozione di Globalize!

I commenti per questo articolo sono stati chiusi.