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.
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
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.
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.
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:
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 V.
Il giorno mercoled 22 agosto 2012, alle ore 11:40, Marco M. ha
scritto:
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!
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
