Java App Multi-lingua

[simo7784]

Io avevo un esigenza analoga. Il mio dizionario pero' non era molto ampio e l'ho risolta con un unico file xml.
Ogni voce era del tipo
<voce keyword="parola">
<language value="IT">parola</language>
<language value="EN">word</language>
</voce>
Poi classe che legge l'xml con libreria JDom.

[Andrea1979]

Preferisco anch'io la soluzione multi-file, per il semplice fatto che è molto più comodo aggiungere una nuova lingua e che un utente potrebbe decidere di scaricare solo questo o quel pacchetto lingue invece che un super mega file contenente tutte le traduzioni.

[Andrea1979]

Per fortuna java, come molti altri linguaggi di programmazione, mette a disposizione delle API per maneggiare abbastanza agevolmente file in formato XML. Una libreria è ad esempio JDom, di cui si è parlato diverse volte anche qui sul forum.
Se sei a digiuno totale di jdom o manipolazione di xml con java, meglio dare una letta sui siti ufficiali

http://www.jdom.org/

Per quanto riguarda i dettagli implementativi... c'è solo da decidere come organizzare l'xml: personalmente creerei un "super-nodo" per l'interfaccia grafica, con all'interno un nodo per ogni "schermata" della tua applicazione e dentro ciascuno di essi le informazioni necessarie alla creazione degli elementi dell'interfaccia (testi dellle label, button e quant'altro). In un super-nodo a parte metterei le informazioni di debug (se servono) e i messaggi "testuali" (tipo eccezioni).

Userei un layout solido (testi in lingue diverse avranno quasi certamente lunghezze diverse, il che potrebbe dare non pochi problemi con layout null e dimensionamento in pixel).

[nether]

C'e' una ragione specifica per usare xml? A me sembra piu' comodo e immediato l'utilizzo di un file di properties (che altro non e' che un file di testo contenente coppie "chiave=valore").
Tra l'altro, la classe ResourceBundle ha dei metodi statici molto comodi per caricare il giusto file di proprieta' a partire da un determinato locale.
E' tutto spiegato nella documentazione di ResourceBundle, cmq andando a memoria potresti creare 2 files: "text_it.properties" e "text_en.properties". Poi, a seconda del Locale scelto dall'utente, carichi il file di proprieta' con una roba tipo ResourceBundle.getBundle("it.html.text", locale). Specificando solo il "basename" del tuo file di properties (nel caso "text") e un Locale, dovrebbe andare a prenderti lui automaticamente il file di proprieta' collegato al Locale da te specificato (per semplificare diciamo che aggiunge il suffisso "_it" o "_en" al tuo basename). In realta' le cose sono leggermente piu' articolate, cmq ripeto, e' scritto tutto nella documentazione della classe ResourceBundle.

[Andrea1979]

Originariamente inviato da nether
C'e' una ragione specifica per usare xml? [...]

Sì e no... nel senso che tutti i linguaggi di programmazione offrono delle ottime librerie per gestire e manipolare xml, il che consentirebbe la riscrittura del programma in un altro linguaggio evitando di dove fornire ancora i file con le traduzioni.

[nether]

Originariamente inviato da Andrea1979
Sì e no... nel senso che tutti i linguaggi di programmazione offrono delle ottime librerie per gestire e manipolare xml, il che consentirebbe la riscrittura del programma in un altro linguaggio evitando di dove fornire ancora i file con le traduzioni.

non conoscendo altri linguaggi di programmazione mi viene da chiedere se i file di properties siano una peculiarita' di java. In ogni caso non credo sarebbe un grosso problema scrivere una classe in un altro linguaggio di programmazione in grado di parsare un file di testo strutturato in maniera estremamente semplice come un file di properties.

[Andrea1979]

sì, solo che non vedo perché devo farlo. Il tempo è denaro e la roba pronta e testata e standard è la manna. Altrimenti tutti quelli che forniscono dati in formato xml sono dei polli... e non credo mica.

[interarete]

Sono d'accordo con nether. In Java il modo standard e già fornito dal linguaggio per rendere un'applicazione multilingua consiste nell'utilizzare file di properties con suffissi opportuni e sfruttare il Locale. Si tratta di un meccanismo semplicissimo e sicuramente ben testato appunto perché parte della piattaforma.
Quanto alla possibilità di riscrivere l'applicazione in un altro linguaggio, non credo che sia più semplice effettuare il parsing di un file XML rispetto ad un file di properties che utilizza l'uguale come separatore... Il fatto che tutti utilizzino file XML non significa che bisogna utilizzarli sempre, anche quando se ne può fare tranquillamente a meno.

Ciao,

[nether]

Originariamente inviato da Andrea1979
sì, solo che non vedo perché devo farlo. Il tempo è denaro e la roba pronta e testata e standard è la manna. Altrimenti tutti quelli che forniscono dati in formato xml sono dei polli... e non credo mica.

ad esempio perche' puo' essere piu' performante per dati talmente poco strutturati da non richiedere l'utilizzo del formato xml...
ad esempio perche' un file di properties e' un file che si presenta in un modo piu' semplice e immediato di un xml (niente gerarchia, o almeno non esplicita, niente tag ecc.)...
e cmq la classe per parsare il file sarebbe una cosa che basta fare una volta e puo' essere utilizzata in qualsiasi applicazione per tutta la vita (ammesso che negli altri linguaggi di programmazione non esista nulla di gia' pronto)...

Resta il fatto che non capisco l'ultimo ragionamento: i file di properties sono molto utilizzati in ambiente java, mentre tutti avrebbero potuto scegliere e seguire la strada dell'xml, se ci fossero stati solo vantaggi. Secondo me si tratta di una semplice scelta, non la vedo come una decisione da prendere a senso unico.

[Andrea1979]

stili di programmazione differente, certo non vi chiedo di cambiar parrocchia.