La parte "modello" di MVC deve occuparsi del livello di internazionalizzazione?

Risposta breve

Internazionalizzazione e localizzazione (vedi definizioni del W3C ) non è qualcosa di monolitico. Comprende un'intera serie di funzionalità, alcune delle quali sono rilevanti per la vista, alcune per il controller e altre per il modello.

Risposta lunga

Localizzazione

Localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale).

In genere, si tratta di formattare numeri, date e ora e di utilizzare la lingua dell'utente nel layout dello schermo e nei menu. Tutto questo è in genere pertinente per la vista .

Interpretazione delle scorciatoie da tastiera, tasti funzione (ad esempio, la freccia sinistra e destra non significano lo stesso se si utilizza una lingua da sinistra a destra o una da destra a sinistra) o i comandi degli utenti sono in linea di principio una responsabilità di il controller ( disclaimer: intendo il controller nel senso di pattern MVC originale ; alcune varianti moderne potrebbero rimandare anche alla vista ).

Dalla localizzazione all'internazionalizzazione

Molto presto tuttavia, la localizzazione potrebbe riguardare aspetti più delicati. Ad esempio:

• Valuta: se hai un valore in USD nel tuo modello, non sarà sufficiente visualizzare l'etichetta EUR, GBP o JPY della valuta locale! Valori valutari generalmente richiedono una conversione adeguata. Ma usando quale tasso: il tasso storico al momento in cui l'importo è stato registrato? o il tasso del giorno precedente? o la frequenza intraday al secondo esatto del display si aggiorna? Nei pacchetti di contabilità avanzati è possibile lavorare anche con più valute in parallelo: la valuta del gruppo, la valuta della filiale per la segnalazione alle autorità locali e la valuta della transazione (che potrebbe obbedire a regole di conversione diverse per il gruppo e il valute della controllata). Ecco perché la valuta è in linea di principio nel modello .
• Unità di misura: le misure possono essere espresse in metri (litri, metri, centimetri, ...) e il sistema imperiale (galloni, iarde, pollici, ...). Fortunatamente, è più semplice della valuta: non esiste un tasso di conversione giornaliero. Quindi potresti benissimo assumere un sistema nel tuo modello e convertirlo nel flusso nell'altro al livello vista (ma puoi distruggi un satellite con le ipotesi sbagliate ). Per alcune applicazioni è sufficiente. Ma se si dispone di un software aziendale che sommerà molte unità di misure, la somma convertita arrotondata potrebbe non corrispondere alla somma degli articoli convertiti arrotondati. Per evitare tali incoerenze, potrebbe essere necessario risolverlo nel modello .
• Alcuni sistemi sono progettati per essere multilingue. Ad esempio, un sistema di vendita può gestire prodotti con una descrizione per ciascuna lingua supportata, in modo che un cliente tedesco visualizzi la descrizione tedesca sulla sua fattura e il cliente giapponese vedrà il testo giapponese. In questo caso, devi aggiungere la lingua al tuo modello .

Internazionalizzazione

Internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.

In base a questa definizione, puoi progettare la tua applicazione dall'inizio per l'internazionalizzazione. Quindi hai la scelta su dove metterlo:

• Puoi entrare molto bene come dettagli di implementazione della vista e usare i file di configurazione (linux), le risorse stringa incorporate (macOS) o le DLL aggiuntive (windows).
• Ma potresti scegliere di renderli dati / contenuti come gli altri, con casi d'uso per la sua gestione. Gran parte della localizzazione verrebbe quindi eliminata nel modello . Non sarebbe la mia prima spontanea scelta personale, perché potrebbe offuscare le linee forti tra vista e modello e rendere il software estremamente complesso da gestire.

Nonostante la mia preferenza, non sarò dogmatico: alla fine dipende dal contesto, dai costi e dai benefici attesi. Se sei per esempio un importante fornitore di ERP a livello mondiale e consideri questa una caratteristica di differenziazione di mercato fondamentale, potresti benissimo prenderla in considerazione.

In un'applicazione MVC, l'internazionalizzazione appartiene principalmente alle visualizzazioni. Se un modello o un servizio ha bisogno di tradurre alcune stringhe, non c'è niente di sbagliato nell'usare anche i componenti di internazionalizzazione.

L'alternativa sta costringendo il modello a gestire tutte le stringhe. Ciò farebbe sì che il modello abbia un gran numero di codice boilerplate senza vantaggi reali.

Per gli elementi che trattano la presentazione, come i componenti dell'interfaccia utente e i messaggi di errore, la vista sembra il posto logico per me.

Ma l'internazionalizzazione è più, come le regole di pagamento e fiscali possono differire tra i vari paesi. O opzioni di consegna, politica di restituzione, leggi sulla privacy ecc. Ognuno dovrebbe essere preso in considerazione e reso parte del sistema.

Alcuni di questi argomenti, come l'interfaccia utente, appartengono alla vista. Altri come le descrizioni dei prodotti in più lingue sembrano posizionati meglio nel modello.

E applicare le regole appropriate per fornire un servizio in base alle leggi locali assomiglia alle regole aziendali.

Internazionalizzazione, ( I18n ), è davvero un dettaglio di implementazione ma l'approccio "migliore" che ho visto è l'uso di strumenti come gettext che consente al codice sorgente di contenere qualsiasi stringa richiesta nella lingua preferita dagli sviluppatori ma contrassegnata per sostituzione del tempo di esecuzione e per l'estrazione e la traduzione in risorse esterne specifiche per lingua / locale.

In gettext il tuo esempio potrebbe essere:

printf(_("Hello")); // Greeting marked for I18n

Quindi gli strumenti gettext estrarrebbero questo, con testo marcato in modo simile, in un file .pot , questo sarebbe convertito in un file .po per il francese chiamato fr.po e le traduzioni aggiunte e quindi compilate in un .mo file. Se questo è stato spedito con il tuo programma e inserito nella posizione corretta, l'utente, se la sua lingua era impostata su francese, vede Bonjour piuttosto che Hello.

Dove questo è un grande vantaggio è che:

• Non è necessario creare versioni specifiche del tuo software
• I tuoi traduttori non vedono il tuo codice
• Puoi aggiungere traduzioni senza ricostruire e persino spedirle separatamente
• Se un utente non è soddisfatto della lingua, può semplicemente cambiare la lingua
• Se viene selezionata una locale non supportata, vengono visualizzati i messaggi originali.
• Il tuo codice sorgente rimane leggibile.
• La localizzazione è una questione separata gestita dagli strumenti gettext & biblioteca.