lucasalva87
commented
4 years ago Quindi dici di prevedere in OSM un modulo che permetta la creazione/sync del file modello catalog.pot e poi popolare il relativo file po (e mo) con le traduzioni. Il tutto da interfaccia web, un pò come fa anche questo plugin di wordpress (https://it.wordpress.org/plugins/loco-translate/#description). Sarà possibile così gestire le lingue già previste ma anche generarne di nuove in completa autonomia. Bisognerà prevedere anche la possibilità di definire i formatter. Come hai giusto analizzato sarà da prevedere qualcosa per i campi valorizzati a db come per esempio gli stati dei documenti...
La traduzione del gestionale è una caratteristica per ora considerata molto debolmente, e pertanto OpenSTAManager non permette traduzione molto rapida in altre lingue. Il sistema attuale prevedere la gestione delle stringhe di traduzione attraverso dei file .pot e .po, che vengono aggiornati ogni tanto e contengono le traduzioni dirette del testo del gestionale presente nei file fisici. Il problema sorge nel momento in cui sono necessarie traduzioni dei contenuti del gestionale salvati nel database, come nomi di moduli, plugin, stampe, widget e in generale i contenuti presentati dalle query. Dalla versione 2.3 sono stati differenziati due campi in questo contesto: name che indica il nome a cui gli sviluppatori fanno riferimento a livello di codice, title che contiene il nome visualizzato a livello grafico. Ciò però è limitato ai componenti principali del gestionale, e non ai contenuti dei moduli.
Per fare un esempio, gli stati dei documenti contengono un solo campo descrizione che viene ancora utilizzato in molte query per l'identificazione di alcuni documenti specifici.
Potrebbe essere utile quindi prevedere un'estensione più generale del sistema di traduzioni, con l'eventuale aggiunta di un modulo per la relativa gestione. Riferimento di caso d'uso: #602