Forum: Italian Ruby user group Internazionalizzazione

Ciao a tutti,

prima di mettermi a googlare e provare l'impossibile vorrei chiedervi 
quali
sono le vostre best practices in tema di internazionalizzazione di una 
web
app.

Ad esempio rails ha il backend che pesca da file YAML, ma io preferirei
pescare da un db per poter inserire nuove stringhe a run time senza 
dover
fare ogni volta un deploy (ma mi piacerebbe poter dumpare il db sui
suddetti file yml per averne una "copia fredda" che non sia il backup 
del
db).

C' poi la gemma delocalize che funziona piuttosto bene con le currency,
date ecc.

Ogni commento e link  bene accetto :)

Sante

Io ho usato in passato https://github.com/tolk/tolk di cui sono 
abbastanza
soddisfatto, bisogna per lanciare un rake task quando si cambiano le
traduzioni per fare il dump delle stringhe localizzate su yaml.

    Ju

--*
*M.Sc. Ju Liu
Card: http://zerp.ly/ju-liu
--
Societ Cooperativa weLaika - Impresa Sociale
Corso Vigevano 14/B, 10154 Torino (TO), Italy
http://welaika.com - info@welaika.com



2012/7/26 Sante Rotondi <saten.r@gmail.com>

Guarda anche http://copycopter.com/ E' da un po' che vorrei usarlo ma
non ho mai avuto l'occasione. C'è un Railscast free a
http://railscasts.com/episodes/336-copycopter

Ci sono poi dei dati che devono per forza essere internazionalizzati nel
database, ad esempio tutti quelli con cui si creano dinamicamente dei
menu e che vengono inseriti da admin ed utenti. Per quelli guarda
https://github.com/svenfuchs/globalize3

L'unico problema con globalize è che fa una chiamata al database per
ogni stringa da internazionalizzare e certe pagine si appesantiscono. In
certi casi potrebbe essere necessario introdurre del caching.

Paolo

Un modo furbo e future-proof di gestire la localizzazione in ruby e js 
mi sembra essere  https://github.com/twitter/twitter-cldr-rb

Luigi

Ciao Sante,
Per quanto riguarda il db di backend, puoi usare la mia gemma 
"redis-i18n"
( https://github.com/jodosha/redis-store/tree/master... ).

Luca

Ciao Sante,
non è detto che come dici tu risparmi sui deploy, comunque, se devi 
localizzare contenuti fissi (l'interfaccia) eviterei di appoggiarmi ad 
un db a meno che non sia estremamente veloce (vedi il suggerimento 
precedente di Luca), se devi gestire contenuti dinamici invece non hai 
scelta, a i18n continuerei a fargli gestire i contenuti fissi e 
copycopter potrebbe fare al caso tuo, se lo usi poi posta gentilmente la 
tua esperienza che nenache io sono riuscito ancora a provarlo.

Ciao,
Se non ti va di configurare un server con copycopter (dato che il 
servizio web  stato sospeso in favore della sua versione open-source) 
potresti dare un occhiata a LocaleApp (http://www.localeapp.com/), un 
app che  stata presentata ieri in un lightning talk a spreeconf  In 
pratica ti offre un'interfaccia web tramite la quale puoi modificare i 
file di traduzione (ed eventualmente invitare altri traduttori che 
dovranno svolgere il lavoro) per poi sincronizzare automaticamente i 
locale con quelli della tua applicazione. Il servizio  a pagamento oltre 
un certo numero di chiavi.  stata presentata anche una demo live e l'app 
sembrava veramente ben fatta e perfettamente funzionante.


--
Alberto Vena
http://nebulab.it/



Il giorno mercoled 22 agosto 2012, alle ore 11:40, Marco Mastrodonato ha 
scritto:

Sto facendo un pensiero sulla gemma di Luca, redis-i18n

Ho un paio di domande che ritengo di interesse generale, per cui le 
scrivo
qui invece che a lui in privato :)


Quanto performa bene questo sistema rispetto al lookup su file .yml 
locali
all'applicazione?
Esiste un'interfaccia per aggiungere le traduzioni che si appoggia a 
questo
backend?

Sante,
Il lookup per YAML non avviene direttamente dal file, bens dalla 
memoria,
ovvero le stringhe vivono nello stesso heap space della tua 
applicazione,
per l'operazione  leggermente pi veloce della lettura da Redis, dove a
penalizzarti  il protocolo TCP, che  lento se rispetto al message 
passing
di Ruby. Si parla comunque di un overhead irrisorio, se il server Redis 
ha
una latenza di rete bassa (cio geograficamente vicino).

Le cose cambiano se ad esempio clusterizzi la tua applicazione Rails,
diciamo con cinque istanze di Unicorn. Rails ha una share-nothing
architecture, il che significa che ogni worker Unicorn carica in memoria 
la
sua immagine dell'applicazione. Nell'esempio precedente avresti cinque
volte in memoria le stesse traduzioni. In pi, se fai un ampio uso di
istanze di Symbol come chiave per il lookup, sappi che queste non sono
candidate per il garbage collecting.

Per l'interfaccia di traduzione dai un'occhiata qui:
https://www.ruby-toolbox.com/categories/i18n
Ti menziono un mio vecchio plugin, semmai dovesse ispirarti un "nuovo"
approccio: https://github.com/jodosha/click-to-globalize

Ciao,
Luca

On 05/09/2012 19:58, Luca Guidi wrote:
> Sante,
> Il lookup per YAML non avviene direttamente dal file, bens dalla memoria,
> ovvero le stringhe vivono nello stesso heap space della tua applicazione,
> per l'operazione  leggermente pi veloce della lettura da Redis, dove a
> penalizzarti  il protocolo TCP, che  lento se rispetto al message passing
> di Ruby. Si parla comunque di un overhead irrisorio, se il server Redis ha
> una latenza di rete bassa (cio geograficamente vicino).

Diciamo che questo rende l'avvio dell'applicazione pi snello, non
dovendo mettere in memoria tutte le traduzioni all'avvio del processo.
Sono un po' preoccupato, per, da quante chiamate a redis si rendano
necessarie per tradurre una view con tante piccole traduzioni.
Ci sono dei benchmark in merito?


> Le cose cambiano se ad esempio clusterizzi la tua applicazione Rails,
> diciamo con cinque istanze di Unicorn. Rails ha una share-nothing
> architecture, il che significa che ogni worker Unicorn carica in memoria la
> sua immagine dell'applicazione. Nell'esempio precedente avresti cinque
> volte in memoria le stesse traduzioni. In pi, se fai un ampio uso di
> istanze di Symbol come chiave per il lookup, sappi che queste non sono
> candidate per il garbage collecting.

Naturalmente l'occupazione di ram  un trade off rispetto alla lentezza
di recuperare le traduzioni. Ovviamente bisogna valutare quanto si possa
far sentire questa lentezza, e credo che prover ;)
Una cosa che sicuramente  interessante, mancando il loading iniziale in
memoria delle traduzioni,  il fatto che queste si possono aggiungere e
modificare a run time senza dover fare un restart dei vari processi.
Questo imho  un grande plus!

Guarder anche le interfacce per la traduzione, grazie Luca!