Strategia I18n per applicazioni web java

1

Le applicazioni internazionalizzate di solito visualizzano i collegamenti nell'intestazione per la traduzione in diverse lingue, ad esempio spagnolo | Inglese | Italiana.

Questi collegamenti di solito traducono la pagina corrente nella lingua selezionata, e di solito l'url include la lingua: link .

Domande:

  1. Questo si applica solo al contenuto statico?

  2. È possibile internazionalizzare in questo modo i contenuti dinamici? Ad esempio, una pagina che risulta in qualche forma di invio, facendo clic su una lingua diversa potrebbe causare conseguenze indesiderabili. Alcune richieste dinamiche in cui le transazioni non sono coinvolte (semplici query, per esempio) potrebbero non presentare problemi con questo.

  3. Per i contenuti autorizzati, suppongo di dover richiedere la lingua nella pagina di accesso e utilizzare quella lingua, cioè non consentire la modifica delle impostazioni locali per il contenuto autorizzato, che, probabilmente, ha molte transazioni. È corretto?

  4. Come faccio a strutturare i file modello? Un JSP per ciascuna delle lingue? Un JSP con un file di proprietà per ciascuna lingua?

  5. Come si costruisce il collegamento in base alla richiesta corrente? Immagino che l'url richiesto e la stringa param debbano essere ricordati e ricostruiti in JSP.

posta Antonio Sánchez 26.07.2013 - 12:43
fonte

1 risposta

1

Una strategia i18n dipende in gran parte dal framework che si sta utilizzando, dato che molti di essi hanno incorporato il supporto per l'internazionalizzazione e non avrebbe senso personalizzare il proprio se il framework lo supporta già.

Spring MVC, ad esempio, utilizza i file delle proprietà e un resolver locale per visualizzare diverse versioni di pagine. Aggiungono ?language=xx all'URL per determinare quale file di proprietà cercare per visualizzare i messaggi.

La maggior parte dei framework Java con cui ho lavorato ha raggiunto l'internazionalizzazione in modo simile. Più file di proprietà con il suffisso del codice della lingua e quindi utilizzando i tag <message> -type per eseguire il rendering del contenuto.

Does this only apply to static content?

No. A seconda di come stai monitorando la lingua selezionata dall'utente, puoi facilmente estrarre contenuti dinamici in base a un filtro di lingua. Se stai prelevando dati da una tabella, puoi avere una colonna nella tabella che specifica la lingua. In questo modo, quando stai selezionando dalla tabella, fai semplicemente WHERE language = xx per recuperare il contenuto che corrisponde alla lingua selezionata dall'utente.

Is it possible to internationalize this way dynamic content? For instance, a page which results in some form submission, clicking a different language might result in undesirable consequences. Some dynamic requests where transactions are not involved (simple queries, for example) might present no problems with this.

Un utente che modifica la lingua preferita sul tuo sito web non dovrebbe interrompere la sua sessione corrente, indipendentemente dal fatto che stia compilando o meno un modulo. Non fare un INVIO sul modulo quando cambiano la lingua e non dovrebbe avere risultati imprevisti.

For authorized content, I guess I must ask for language in login page and use that language, i.e., disallow changing locale for authorized content, which, probably, has a lot of transactions. Is this correct?

Puoi farlo se lo desideri, dipende da come strutturi la tua app web e da come gestisci le sessioni all'interno della tua area autorizzata. Potresti chiedere a qualcuno di scegliere la loro lingua nella pagina di accesso e quindi non consentire loro di cambiare dopo.

Puoi anche permettere loro di cambiare la loro lingua in qualsiasi momento e semplicemente "aggiornare" la loro pagina corrente, estraendo il contenuto dal "nuovo" linguaggio piuttosto che costringerli a disconnettersi e rientrare di nuovo. (Questo è il modo migliore per farlo, IMO).

How do I structure template files? One JSP for each of the languages? One JSP with a properties file for each of the languages?

Anche in questo caso dipende dal framework che stai utilizzando. Non creare un JSP diverso per ogni lingua come se fosse necessario modificare la pagina che è necessario modificarla per ogni lingua. Anche se questo vale anche per i file delle proprietà, stai modificando il contenuto e non il layout / la struttura della pagina. Un file di proprietà per ciascuna lingua è il modo in cui generalmente l'ho visto e sembra essere consigliato dalla maggior parte dei framework.

How do I construct the link according to current request? I guess that url requested and param string should be remembered and reconstructed in JSP.

Hai indovinato. Una volta che un utente seleziona una lingua, salvala nel suo ambito di sessione e passaci con essa.

    
risposta data 29.07.2013 - 04:11
fonte

Leggi altre domande sui tag