Devo usare risorse ASP .resx se il sito web è disponibile in una sola lingua?

Question

Devo usare risorse ASP .resx se il sito web è disponibile in una sola lingua?

#1 da (1 voti)
#2 da (0 voti)

0

È consigliabile archiviare sempre le stringhe nei file di risorse ASP .resx, anche quando l'applicazione non è localizzata in base alla cultura dell'utente ? (Le pagine Web verranno visualizzate in francese.)
Esistono motivi per utilizzare risorse diverse da quelle di fornire pagine in lingue diverse facilmente?

A favore delle risorse, qualcosa "odora male" o "sembra brutto" riguardo alla scrittura di codice che mescola stringhe HTML, ASP / Razor e hard-coded:

@Html.LabelFor(Model.FirstName, "Votre prénom :");
...
<input type="submit" value="Modifier votre profil" />
...
<div class="error">Une erreur est survenue</div>

O peggio, mescolando codice .NET / C # e stringhe hard-coded:

[Display(Name = "Le salaire actuel de l'employé")]
public int Salary { get; set; }

A favore di stringhe hard-coded, l'utilizzo di risorse quando non sono necessarie è un ulteriore lavoro extra per lo sviluppatore e (sembra) violazione di YAGNI.

programming-practices asp.net-mvc localization

posta Clément 10.12.2014 - 15:31

fonte

2 risposte

0

Non c'è una risposta definitiva. Personalmente sono strongmente contrario all'internazionalizzazione quando non ne hai bisogno. Ho fatto un sacco di siti web aziendali e posso dire con certezza che fare l'internazionalizzazione consuma più tempo di quanto immagini inizialmente. Evento quando si utilizzano metodi più avanzati e meno noiosi di quelli forniti dal file di risorse.

Tieni presente che puoi avere una sorta di database nel testo, nel tuo back-end, nei messaggi di convalida JS, ecc. Non tutto è traducibile con le risorse. E non dimenticare i casi in cui il browser dell'utente ha una cultura diversa da quella del tuo server (ad esempio 0,3 è valido nel browser, ma non riesce nel back-end).

Avere il testo codificato nei modelli di visualizzazione e utilizzare la cultura fissa è una vera gioia e relax:)

risposta data 11.12.2014 - 11:13

fonte

Leggi altre domande sui tag programming-practices asp.net-mvc localization

Utilizzo di classi non progettate per più sessioni nel servlet Il percorso più breve per visitare tutti i nodi [duplicato]

score 1 · Accepted Answer

La cosa bella di YAGNI è che può essere quantificato . Ci sono anche tre metriche:

Il tempo risparmiato applicando YAGNI e non implementando qualcosa in anticipo.
La probabilità che l'applicazione debba essere riscritta
Il tempo necessario per riscrivere l'applicazione un paio di anni nel futuro.

Quando time saved > time needed for rewriting × probability of rewrite , allora è vantaggioso non investire in un'architettura più flessibile in questo momento. YAGNI può essere interpretato come un euristico che dice "la probabilità di una riscrittura è vicina allo zero, quindi può essere generalmente ignorata".

Ma qui abbiamo un caso in cui il tempo risparmiato è molto piccolo rispetto al tempo necessario per una riscrittura di tutti i tuoi modelli, e la probabilità di una riscrittura probabilmente non è nulla - quali sono le probabilità che il sito web vorrebbe offrire la navigazione in inglese qualche volta durante i prossimi cinque anni? Sembra un requisito ragionevole per la maggior parte dei siti.

Quindi, invece di dover riscrivere l'applicazione in un secondo momento, potresti voler farlo correttamente la prima volta.

Naturalmente, l'utilizzo della localizzazione offre vantaggi che vanno oltre il supporto di più lingue, ad esempio una corretta formattazione di numeri e virgolette. Inoltre, non inserire testo nei modelli aiuta a separare l'implementazione dalla progettazione dal contenuto. Idealmente, un non-programmatore sarebbe in grado di cambiare il testo di un pulsante e non dovrebbe cercare attraverso un file di modello. Tali considerazioni distorcono ulteriormente il vantaggio di utilizzare un design adeguato anche quando sembra eccessivo.

Recentemente ho scritto un piccolo sito Web (utilizzando un diverso stack tecnologico) e ho esaminato queste considerazioni. Alla fine, ho scoperto che nel mio caso la probabilità di dover supportare lingue aggiuntive era trascurabile, quindi non ho scelto l'internazionalizzazione. Tuttavia, ho preso un po 'di debito tecnico attraverso questa decisione perché i miei file template sono certamente un po' confusi. L'utilizzo dei file di localizzazione non avrebbe risolto completamente questo problema, ma avrebbe contribuito a tenere separati i diversi problemi. Stimo che la mia decisione di lesinare sui file di localizzazione non è valsa la pena, perché dovrò comunque riscrivere i template.