2011-12-28 23 views
14

Sto lavorando a un'applicazione Rails esistente e sto utilizzando un file di localizzazione, en.yml, per conservare la maggior parte del testo dell'app. Al momento, non stiamo localizzando in altre lingue, quindi c'è solo un file, ma il fatto che stiamo mettendo translate('some.key') nelle nostre viste significa che aggiungere un'altra lingua sarà semplice come aggiungere un altro file - ad esempio, sp.ymlCome posso identificare le chiavi i18n non utilizzate?

Il problema è, en.yml è cresciuto al punto che dubito che tutti i tasti vengano utilizzati.

Oltre a git grepping per translate chiamate utilizzando ogni chiave, esiste un modo rapido per identificare le chiavi di localizzazione che non vengono chiamate esplicitamente dall'app?

risposta

0

Prendi quelli che vengono utilizzati attivamente, quindi rimuovi il resto. Questo è quello che uso.

In realtà li ho impostato a active=0, ma che potrebbe non funzionare per voi

Aggiornamento
scopre che ero poco chiaro.

Ci sono due modi per osservare questo: dai file di origine o dai file di traduzione. Se si guardano dai file di origine è necessario identificare tutte le stringhe in uso e rimuovere definitivamente tutte le stringhe inutilizzate.

Se si guarda dai file di traduzione, è necessario controllare la fonte e determinare se sono ancora utilizzati, come indicato nella domanda.

Non c'è altro modo.

+0

non capisco quello che vuoi dire. Sto parlando di linee in un file. Stai parlando delle righe del database? –

+0

Non ho esperienza con le guide, ma la maggior parte delle soluzioni i18n che conosco hanno un modo di esportare tutte le stringhe traducibili. Esportare tutte le stringhe traducibili, quindi eseguire il ciclo di tutte le stringhe e controllare quali non vengono più utilizzati (osservare nell'esportazione). –

+0

Non sto chiedendo come confrontare due file di localizzazione; Sto chiedendo come verificare quali chiavi di localizzazione sono utilizzate dal codice dell'app. –

11

Date un'occhiata a questo articolo su "Key issues internationalizing your app". Il paragrafo che ti interessa è: "Eliminare traduzioni inutilizzate".

In particolare, si consiglia di guardare attraverso il codice sorgente e anche la registrazione quali tasti traduzioni utilizzato nella vostra applicazione di produzione, come segue:

module I18n 
    module Registry 
    protected 
    def lookup(locale, key, scope = [], options = {}) 
     @log ||= Logger.new(File.join(Rails.root, 'log', 'i18n_registry.log')) 
     @log.info key 
     super 
    end 
    end 
end 

I18n::Backend::Simple.send :include, I18n::Registry 

Speranza che aiuta.

6

I18n-task gemma

Ho appena sentito parlare di questo gioiello, che include un compito di mostrare "traduzioni potenzialmente inutilizzati".

https://github.com/glebm/i18n-tasks

+3

Potenzialmente non utilizzato, nel senso che fornirà falsi positivi per casi difficili da rilevare, ad es. 'I18n.t (method_returning_the_key)'. È possibile ignorare tali chiavi con 'config/i18n-tasks.yml'. – glebm

+1

@glebm - Grazie per il chiarimento. A proposito, come hai trovato questa citazione della tua gemma così in fretta? –

+1

Ho cercato il nome su SO :) – glebm

0

Sono passati molti anni da quando sono arrivato a questa domanda come ho avuto lo stesso identico problema. Il problema non è diventato più piccolo, sono più frustrato che mai.

Qui è un progetto sperimentale, si aggancia nella ricerca tradurre e incrementa il contatore a chiave la traduzione in Redis:

https://github.com/paladinsoftware/i18n-counter

L'idea è che si può tirare le statistiche e confrontare. (WIP per il momento, mi piacerebbe aiuto OFC)

si può chiedere: "Non sarà che rallenta le ricerche"

E hai ragione, naturalmente, ma l'overhead è appena percettibile, controlla questo benchmark.

require 'benchmark' 
n = 100000 
Benchmark.bm do |x| 
    x.report { ENV['ENABLE_I18N_COUNTER'] = 'true'; n.times do ; I18n.translate('application.contract_not_available.header'); end } 
    x.report { ENV['ENABLE_I18N_COUNTER'] = 'false'; n.times do ; I18n.translate('application.contract_not_available.header'); end } 
end 

--------------------------------------------- 
| Benchmark | Seconds | Sec pr translation | 
|------------| --------- | ------------------ | 
| with redis | 48.280000 | 0.0004828   | 
| without | 9.010000 | 0.0000901   | 
--------------------------------------------- 

L'overhead è di circa 3 ms pr ricerca. Si riduce al numero di ricerche effettuate per pagina/richiesta.

Problemi correlati