Le migliori pratiche per lo sviluppo di un sito Web ASP.NET in 30 lingue?

Question

Svilupperemo un sito Web ASP.NET in 30 lingue. Qual è la soluzione migliore per sviluppare quel sito? quale architettura usare?

Answer 1

Suggerisco di archiviare le proprietà dell'interfaccia utente nei file di risorse ( .resx ) e di avere CurrentUICulture nella lingua specifica per ogni richiesta:

<globalization culture="auto" uiCulture="auto" />

Se il tuo sito Web è per lo più orientato al contenuto piuttosto che un'applicazione orientata al business che differisce fortemente in base alla lingua, potresti prendere in considerazione l'idea di creare un set separato di pagine per ogni lingua e reindirizzare l'utente in base a un cookie o una proprietà del profilo o Request.UserLanguages ??. Non è possibile fornire una prescrizione generale per il problema della globalizzazione. La migliore architettura differisce in modo significativo in base alla natura di ogni singolo progetto.

Answer 2

NLS è un requisito ricorrente e spesso quando viene posta la domanda sulla funzionalità NLS, le persone che fanno domanda non sono consapevoli della complessità. La NLS è generalmente suddivisa in (almeno) 2 aree:

• NLS nell'interfaccia utente

• NLS nei dati

Nel tuo caso, un sito Web basato sul contenuto, puoi persino dividere il secondo punto in - dati generati dal fornitore del sito Web e - dati generati dall'utente.

Per l'interfaccia utente NLS puoi usare il meccanismo .resx come menzionato da Mehrdad, ma dovresti essere consapevole che ogni lavoro sulla localizzazione richiede sempre di modificare il codice sorgente (cioè i file resx).

Quando ho dovuto sviluppare un'app Web multi-lingua, ho quindi scelto di gestire il requisito NLS nel mio codice e ho creato un paio di tabelle specifiche NLS che rispecchiavano l'interfaccia utente (tra cui questa era la motivazione per scrivere graspx : estrae tutti i testi visibili dalla fonte aspx, come Label.Text ecc.). Esiste un'applicazione separata per caricare la definizione dell'interfaccia utente e consentire ai traduttori di svolgere il proprio lavoro. L'applicazione principale ha una funzionalità di importazione per i testi tradotti.

Il modello di dati è simile al seguente: Pagina - PageItems - PageItemTexts (con riferimento a una lingua), quindi è abbastanza semplice.

Lo stesso modello può essere applicato al contenuto: invece di Page e PageItems, hai semplicemente ContentItems, che contiene solo un PK e un identificatore, e una tabella che contiene il testo dei ContentItems associati a una lingua.

Inoltre, è possibile definire una sorta di catena di fallback della lingua, in modo che un testo non ancora tradotto sia visualizzato nella lingua originale o in un'altra lingua (strettamente correlata).

La lingua visualizzata può essere selezionata dalla lingua fornita dal browser (HTTP_ACCEPT_LANGUAGE), ma dovrebbe essere consentito all'utente di essere sovrascritto (ad esempio tramite una casella combinata). La lingua selezionata deve essere memorizzata in una variabile di sessione, in un cookie o nel database (per utenti registrati).