Come dovrei architettare il supporto multilingue per un gruppo di applicazioni?

5

Ho circa 8 applicazioni web (tutte basate su ASP.NET), e voglio implementare il supporto di più lingue per tutti loro e avere un'architettura che posso sfruttare su nuove applicazioni web lungo la strada. Vorrei anche provare a centralizzare il pezzo di amministrazione (dove risiedono tutte le traduzioni di testo e altre risorse specifiche della lingua), conosci qualche strumento o modello architettonico che potrebbe essere utile in questo caso?

L'unica soluzione valida che posso pensare è di avere un'applicazione web che gestisce le risorse del supporto linguistico e tutte le altre applicazioni web si connettono a questa app / servizio centralizzata, ma temo che questa soluzione abbia un impatto sulle prestazioni su tutte le applicazioni se non implementate nel modo giusto.

Apprezzerei molto qualsiasi suggerimento.

    
posta tivo 02.05.2012 - 15:27
fonte

1 risposta

1

Puoi iniziare definendo molte cose.

Definisci come identificare la cultura nella tua API (ISO-639, LS-2012, ...)

Questa scelta cambierà il modo in cui memorizzi le risorse e accedili. Inoltre, decidi come ripiegare attraverso le regioni e le culture neutrali. Alcune lingue hanno un modo molto specifico di ripiegare tra culture diverse, alcuni libri ti darebbero una visione grandiosa.

Dato che stai scegliendo ASP.NET è semplice.

Definisci come memorizzare ciascun tipo di dati (stringhe, immagini, valute ...)

Dovrai considerare diversi modi di accesso. Vuoi rimanere mobile e utilizzare file semplici? O puoi permetterti di tenere un database in un unico posto per gestire tutto?

La centralizzazione può diventare un problema: i clienti e i consulenti devono occuparsi della traduzione. L'uso di una soluzione basata su file di testo va facilmente nella revisione del controllo del codice sorgente, a condizione che il buon strumento portatile e le librerie siano grandiose ma non facili per i non esperti.

Definisci i formati di accesso per tutti i tipi di applicazione

  • è necessario esportare per una tecnologia specifica (.resx, .po, .lang, xliff ...)?
  • hai bisogno dell'accesso casuale da un'app server tramite un servizio (web)?
  • hai bisogno di un accesso unitario per fare la traduzione?

In tutti i casi, essere in grado di esportare traduzioni in un formato noto ti darà la possibilità di utilizzare i servizi di traduzione. Dovrai quindi essere in grado di unire nuove traduzioni con quelle esistenti.

Definisci come gestire le valute

Questo è più un problema di codice che la tua API non dovrà affrontare interamente. Ma le regole di impostazione per tutti gli sviluppatori sono una buona cosa.

Infine , assicurati che l'API che creerai possa essere convertita in tutte le lingue / tecnologie necessarie. L'utilizzo di formati standard sarà una scelta essenziale a causa delle librerie esistenti (gettext, xliff) e degli strumenti.

Non dimenticare di gestire moduli plurali (senza articoli, articoli, x articoli) e commenti di traduzione (informazioni contestuali per ciascuna risorsa) che risolvono molti problemi.

Scrivi tutto ciò che hai deciso in un documento condiviso per assicurarti che tutti comprendano il perché e il modo. Se stai scrivendo un'API, la documentazione è ... importante.

    
risposta data 04.05.2012 - 22:26
fonte