Esiste un modo migliore per gestire le stringhe localizzate?

Lavoro su un prodotto in cui dobbiamo preoccuparci un po 'della localizzazione. Attualmente, questo è il flusso di lavoro per quando devo usare (o aggiungere) una stringa localizzata:Esiste un modo migliore per gestire le stringhe localizzate?

file Cerca Resources.resx (che ha centinaia di articoli)
Se trovato, quindi copiare il nome. In caso contrario, aggiungere una nuova stringa e copiare il nome
Quindi, utilizzare ResourceFactory.ResourceMgr.GetString("MY_MAGIC_STRING") (dove ResourceMgr è solo un campo statico ad un ResourceManager)

Questo processo in 3 step per le stringhe è un vero e proprio dolore. Ci sono schemi o modi per semplificare questo processo?

fonte

2013-01-14 Earlz

Fare attenzione a riutilizzare la stessa stringa, ci sono frasi/frasi/parole che devono essere tradotte in altre lingue, a seconda del contesto. Per esempio. coniugazione dei verbi in lingue slave a seconda del tema della frase. – svick

@svick ovviamente. Di solito cerchiamo di mantenere le cose tutte insieme (specialmente usando stringhe di stile String.Format) e lasciamo che i traduttori ci dica quando c'è qualcosa che dobbiamo cambiare – Earlz

Se si tratta di un codice pulito o di eseguirlo più velocemente? – Paparazzi

I file generati automaticamente con accesso a ogni singola stringa sono molto più facili da utilizzare: impostare "Strumento personalizzato" per il file RESX su PublicResXFileCodeGenerator.

codice sarà simile:

using MyProject.Resources; 
... 
localizedText = Resources.SomeReasonableName;

note collaterali:

avere più file RESX insieme con gli ID generati automaticamente avere ulteriore vantaggio di intellisense dando ragionevole numero di scelte.
a seconda di come viene gestita la traduzione, potrebbe essere meglio non preoccuparsi del testo duplicato nel file RESX (eccetto forse OK/annulla il tipo di stringhe). Potrebbe essere più semplice gestire stringhe duplicate al momento della traduzione.

fonte

2013-01-14 17:32:37

Ma questo renderà il passaggio 3 solo leggermente migliore, quindi non è un grande miglioramento, no? – svick

@svick, la tua chiamata. "Leggermente" come in "tempo di compilazione rispetto ai controlli di runtime". Anche se le stringhe sono organizzate in file per feature, si ottiene intellisense che con un ragionevole numero di scelte, se tutte in un file, non così tanto. Ma almeno ottieni errori di compilazione nel tempo anziché in fase di esecuzione. –

C'è questa soluzione Java che potrebbe dare qualche idea: http://rodionmoiseev.github.com/c10n/

L'idea è traduzioni negozio nel codice sorgente stessa per, utilizzando le annotazioni sui metodi di interfaccia. Quindi, utilizzando un'utilità speciale, è possibile creare dinamicamente i proxy (classi che implementano dinamicamente l'interfaccia) che restituirebbero il valore stringa localizzato quando si richiama il metodo dell'interfaccia.

In questo modo, "MY_MAGIC_STRING" viene sostituito con una chiamata al metodo MyMagicString(), che offre una certa sicurezza di ortografia/tipo e rende più amichevole il refactoring.

fonte

2013-01-15 14:42:52 rodion

Pubblicare una risposta che contiene solo un collegamento non è molto utile. Potresti aggiungere una breve spiegazione di cosa fa la biblioteca? – svick

Sapevo che sarebbe successo: S Spero che ora sia un po 'più chiaro. – rodion

Esiste un modo migliore per gestire le stringhe localizzate?

risposta

Problemi correlati