Esistono problemi di prestazioni o avvertimenti con file di risorse (.resx)?

Question

I file di risorse sembrano grandi per la localizzazione di etichette e messaggi, ma sono perfetti?

Ad esempio:

1. Esiste una soluzione migliore se non v'è una quantità enorme di risorse? Come 100.000 stringhe in un file .resx? (In teoria, in realtà non ho questo problema)
2. È un buon metodo per archiviare gli altri tipi di dati, come immagini, icone, file audio, file normali, ecc.?
3. È consigliabile archiviare i file .resx in un progetto autonomo per semplificare gli aggiornamenti/la compilazione?
4. Ci sono altri problemi che si sono incontrati durante l'utilizzo di file .resx?

Answer 1

  1. C'è una soluzione migliore se c'è un'enorme quantità di risorse? Come 100.000 stringhe in un file .resx? (Teoricamente, in realtà non ho questo problema)

Ho usato Alfresco come repository di contenuti alternativi su progetti Java. I file RESX, da un punto di vista maintaince (a causa di problemi di codifica, credo) possono davvero puzzare.

  2. È questo un buon metodo per memorizzare gli altri tipi di dati, come immagini, icone, file audio, file regolari, ecc?

L'ho visto funzionare con le immagini ... ma è tutto. (Non sono sicuro con altri mezzi di comunicazione/file)

  3. E 'una buona pratica per memorizzare i file RESX in un progetto autonomo per gli aggiornamenti più facili/compilazione?

Non ce l'ho, ma è possibile modificare un file resx su un sito live e quindi modificare passerà attraverso, credo. Certamente è così che funziona nello sviluppo (ad eccezione del resx globale, penso)

  4.Ci sono altri problemi che hai incontrato durante l'utilizzo di file .resx?

Oltre ad essere davvero noioso da mantenere, e il fatto che lo studio visivo non fornisce gli strumenti più perfetti per lavorare con loro ... no.

Answer 2

Ecco il mio prendere su file di risorse:

1. Parto dal presupposto che se c'è una quantità GRANDE di corda, che l'utilizzo di un database potrebbe essere il metodo migliore per consentire la ricerca e l'ordinamento di i dati. Probabilmente non sarebbe troppo difficile tenere conto di più lingue in una tabella di risorse e la velocità dovrebbe accelerare al meglio.

2. Penso che questo sia un buon metodo per l'archiviazione di risorse statiche o cose che potrebbero essere modificate da un client. Per quanto riguarda le risorse dinamiche, potrebbe essere preferibile utilizzare un database, da solo o in combinazione con il file system. Penso che nel nuovo SQL Server esista un nuovo tipo che sia un ibrido ottimale per l'utilizzo di un database e del file system.

3. Ho letto in un'altra domanda (non so quale) che l'utilizzo di file di risorse in un progetto esterno è una buona pratica, perché non è necessario ricompilare un intero progetto quando le risorse cambiano. Basta ricompilare il progetto delle risorse. Ciò consentirebbe anche alle (abbastanza) facili modifiche da parte dei clienti, dove avrebbero solo bisogno di "codice sorgente" per il progetto di risorse, e non del tuo altro codice reale (codice API, ecc.).

4. Non ho utilizzato i file di risorse abbastanza per fare affermazioni sulla loro affidabilità, estensibilità o eventuali problemi potenziali che potresti avere quando lavori con loro.

Answer 3

Per il punto n.
Ho usato file .resx per tutte le stringhe sul nostro sito che devono essere localizzate in molte lingue e non hanno avuto grossi problemi con loro.

L'unica cosa a cui devi pensare è se vuoi che questo testo sia ricercabile. Per alcuni dei siti su cui lavoro ci sono alcune risorse localizzate che devono essere ricercabili, quindi devo tenerle nel database. Tuttavia, quando ho la scelta preferisco il file .resx per ragioni simili menzionate sopra.

Answer 4

Aggiungo semplicemente che si dovrebbe cercare implementazioni personalizzate (o di proprietà dell'utente) del fornitore di risorse (modello di provider come il provider di appartenenze) per memorizzare le risorse in un database. Questo è quello che abbiamo fatto per il nostro CMS ed è molto utile.

Quando abbiamo cercato per la prima volta un esempio, abbiamo trovato Creating a Data Driven ASP.NET Localization Resource Provider and Editor.

Answer 5

Ho avuto due problemi con i file di risorse, sia sulle prestazioni dei traduttori (persone), piuttosto che sulla velocità di ricerca delle stringhe.

Il personale di vendita presso l'ufficio oversee che ha fatto i traduttori non poteva far fronte con l'editing XML o imparare qualsiasi nuovo strumento.

Quindi hanno appena usato Excel per modificare le traduzioni. Pertanto, potremmo anche aver memorizzato le stringhe tradotte come file CVS, evitando così di dover copiare le stringhe tradotte nei file di risorse.

Una nuova build deve essere eseguita in modo che abbia l'effetto di qualsiasi traduzione.

Ancora una volta se le stringhe tradotte sono state memorizzate come file CSV, potremmo averle memorizzate nella cache di ASP.NET. Quindi eventuali modifiche alle traduzioni verrebbero visualizzate al caricamento della pagina successiva.

---

Così abbiamo potuto usare un'implementazione personalizzata del provider di risorse e mantenere il sistema di ricerca di risorse ASP.NET standard. Oppure ignora semplicemente il sistema di ricerca delle risorse standard se non ti aiuta nel tuo caso - dipende da come sono scritte le tue pagine.

---

Si possono trovare ad un certo punto che si desidera essere in grado di sostituire le stringhe per un singolo cliente , in tal caso avrete bisogno di un sistema di ricerca a più stadi. In caso contrario, è necessario unire le stringhe personalizzate del cliente con la stringa tradotta ogni volta che si invia una nuova versione del sistema.

Answer 6

Abbiamo utilizzato file di risorse su un'applicazione .NET Windows di dimensioni relativamente grandi (oltre 500 moduli diversi, circa 20 stringhe di risorse per modulo) e non abbiamo riscontrato problemi di prestazioni relativi alle risorse dai file .resx. Abbiamo usato Babylon.NET come strumento per la gestione delle traduzioni (ha una versione gratuita solo per i traduttori). Non hai specificato se il tuo progetto sarà un'applicazione web o desktop. Una funzionalità che i file di risorse offrono per le applicazioni desktop è la possibilità di localizzare anche posizioni di controllo e dimensioni che IMHO non è possibile utilizzando altri strumenti (a meno che non si utilizzi qualcosa come il controllo del layout DevExpress con dimensionamento automatico).

Answer 7

Recentemente ho utilizzato un file .resx con 5 milioni di stringhe (lunghezza normale, come questa frase), compilato in DLL diverse circa 1   GB di dimensioni. Funziona ancora bene in un progetto Web di Azure.

Il tempo di caricamento è sconosciuto, forse pochi secondi o giù di lì, poiché è sempre possibile riscaldare gradualmente, non l'ho mai notato.