Procedure consigliate per lo sviluppo di applicazioni internazionali

  • Articolo

In questa sezione vengono forniti alcuni suggerimenti da seguire per lo sviluppo di applicazioni internazionali.

Procedure consigliate per la globalizzazione

  1. Fare in modo che l’applicazione si basi internamente sulla codifica Unicode.

  2. Utilizzare classi con il supporto delle impostazioni cultura fornite dallo spazio dei nomi System.Globalization per modificare e formattare i dati.

    • Per l'ordinamento, utilizzare le classi SortKey e CompareInfo.
    • Per i confronti di stringhe, utilizzare la classe CompareInfo.
    • Per la formattazione di data e ora, utilizzare la classe DateTimeFormatInfo.
    • Per la formattazione dei numeri, utilizzare la classe NumberFormatInfo.
    • Per i calendari gregoriano e non gregoriano, utilizzare la classe Calendar o una delle implementazioni specifiche del calendario.

  3. Utilizzare le impostazioni delle proprietà relative alle impostazioni cultura fornite dalla classe System.Globalization.CultureInfo nelle situazioni appropriate. Utilizzare la proprietà CultureInfo.CurrentCulture per le attività di formattazione, ad esempio per la formattazione della data e dell'ora o dei numeri. Utilizzare la proprietà CultureInfo.CurrentUICulture per recuperare le risorse. Si noti che le proprietà CurrentCulture e CurrentUICulture possono essere impostate per ogni thread.

  4. Impostare l'applicazione in modo da consentire la lettura e scrittura di dati da e verso una vasta gamma di codifiche, utilizzando le classi di codifica nello spazio dei nomi System.Text. Non utilizzare dati ASCII. Partire dal presupposto che verranno forniti caratteri internazionali in qualsiasi punto in cui un utente può immettere testo. L'applicazione deve, ad esempio, accettare i caratteri internazionali in nomi di server, directory, nomi file, nomi utente e URL.

  5. Quando si utilizza la classe UTF8Encoding, per motivi di sicurezza utilizzare la funzionalità di rilevamento degli errori offerta da questa classe. Per attivare la funzionalità di rilevamento degli errori, creare un'istanza della classe usando il costruttore che accetta un parametro throwOnInvalidBytes e impostare il valore di questo parametro su true.

  6. Quando possibile, gestire le stringhe come unità intere e non come serie di caratteri singoli. Questo metodo di gestione è particolarmente importante quando si ordinano o si cercano sottostringhe. In questo modo non si verificheranno problemi associati all'analisi dei caratteri combinati. È anche possibile operare con unità di testo invece che con caratteri singoli usando la classe System.Globalization.StringInfo.

  7. Visualizzare il testo utilizzando le classi fornite dallo spazio dei nomi System.Drawing.

  8. Per garantire l'uniformità tra i sistemi operativi, non consentire l'override di CultureInfo da parte delle impostazioni utente. Utilizzare il costruttore di CultureInfo che accetta un parametro useUserOverride e impostarlo su false.

  9. Eseguire il test della funzionalità dell'applicazione in versioni internazionali dei sistemi operativi utilizzando dati internazionali.

  10. Se una decisione relativa alla sicurezza è basata sul risultato di un confronto di stringhe o di un'operazione di modifica delle lettere maiuscole e minuscole, usare un'operazione stringa indipendente dalle impostazioni cultura. In questo modo è possibile verificare che il valore di CultureInfo.CurrentCulture non influisca sul risultato. Per un esempio che illustra come i confronti tra stringhe dipendenti dalle impostazioni cultura possono produrre risultati non coerenti, vedere la sezione "Confronti tra stringhe che usano le impostazioni cultura correnti" in Procedure consigliate per l'uso delle stringhe.

  11. Per qualsiasi elemento usato per l'interscambio, ad esempio un campo in un documento JSON in una chiamata API, o per l'archiviazione, usare CultureInfo. È inoltre necessario specificare in modo esplicito un formato di round trip, ad esempio l'identificatore di formato di data e ora"O", "o". Sebbene le stringhe di formato per le impostazioni cultura inglese non dipendenti da paese/area geografica siano stabili e con poca probabilità di modifica, la specifica di una stringa di formato esplicita consente di chiarire la finalità del codice.

    • Per gli elementi di data/ora, prendere in considerazione i consigli e le osservazioni di Jon Skeet, autore di Noda Time, che condivide preziose informazioni dettagliate. Per altre informazioni, vedere Jon Skeet: Storing UTC is not a silver bullet.

  12. I dati di globalizzazione non sono stabili ed è consigliabile scrivere l'applicazione e i rispettivi test tenendo presente questo aspetto. Vengono aggiornati più volte all'anno tramite canali del sistema operativo host in tutte le piattaforme supportate. Questi dati non vengono in genere distribuiti con il runtime.

Procedure consigliate per la localizzazione

  1. Spostare tutte le risorse localizzabili in DLL distinte di sole risorse. Le risorse localizzabili includono gli elementi dell'interfaccia utente quali stringhe, messaggi di errore, finestre di dialogo, menu e risorse di oggetti incorporati.

  2. Non impostare stringhe o risorse dell'interfaccia utente come hardcoded.

  3. Non collocare le risorse non localizzabili nelle DLL di sole risorse. Questo confonde i traduttori.

  4. Non utilizzate stringhe composte che sono compilate in fase di esecuzione da frasi concatenate. Le stringhe composte sono difficili da localizzare, in quanto richiedono spesso un ordine grammaticale in inglese che non è valido per tutte le lingue.

  5. Evitare costrutti ambigui, come ad esempio "Empty Folder" in cui le stringhe possono essere tradotte in modo diverso in base alle regole grammaticali dei componenti stringa. La stringa "empty", ad esempio, può essere un verbo o un aggettivo e può essere tradotta in modo diverso in alcune lingue, come ad esempio l'italiano o il francese.

  6. Evitare l'utilizzo di immagini e icone contenenti testo all'interno dell'applicazione, in quanto sono costose da localizzare.

  7. Lasciare sufficiente spazio vuoto per consentire l'espansione della lunghezza delle stringhe nell'interfaccia utente. In alcune lingue le frasi possono richiedere il 50-75% di spazio in più rispetto ad altre lingue.

  8. Utilizzare la classe System.Resources.ResourceManager per recuperare le risorse in base alle impostazioni cultura.

  9. Usare Visual Studio per creare finestre di dialogo Windows Form in modo che possano essere localizzate tramite l'Editor risorse di Windows Form (Winres.exe). Non codificare manualmente le finestre di dialogo di Windows Form.

  10. Assegnare la localizzazione (traduzione) a professionisti.

  11. Per una descrizione completa della creazione e localizzazione delle risorse, vedere Risorse nelle app .NET.

Procedure consigliate per la globalizzazione per ASP.NET e altre applicazioni server

Suggerimento

Le procedure consigliate seguenti sono per le app di ASP.NET Framework. Per le app di ASP.NET Core, vedere Globalizzazione e localizzazione in ASP.NET Core.

  1. Impostare in modo esplicito le proprietà CurrentUICulture e CurrentCulture nell'applicazione in uso. Non utilizzare i valori predefiniti.

  2. Si noti che le applicazioni ASP.NET sono applicazioni gestite e possono utilizzare le stesse classi delle altre applicazioni gestite per il recupero, la visualizzazione e la manipolazione delle informazioni in base alle impostazioni cultura.

  3. Tenere presente che in ASP.NET è possibile specificare i tre tipi di codifiche descritti di seguito.

    • requestEncoding specifica la codifica ricevuta dal browser del client.
    • responseEncoding specifica la codifica da inviare al browser client. Nella maggior parte dei casi, questa codifica deve essere uguale a quella specificata per requestEncoding.
    • fileEncoding specifica la codifica predefinita per l'analisi dei file .aspx, asmx e asax.

  4. Specificare i valori per gli attributi requestEncoding, responseEncoding, fileEncoding, culture e uiCulture nelle tre posizioni seguenti in un'applicazione ASP.NET:

    • Nella sezione globalizzazione di un file Web.config. Questo file è esterno all'applicazione ASP.NET. Per ulteriori informazioni, vedere <elemento> globalizzazione.
    • In un'istruzione di pagina. Si noti che quando in un'applicazione viene visualizzata una pagina, il file è già stato letto, pertanto non è più possibile specificare fileEncoding e requestEncoding. Solo uiCulture, culture e responseEncoding possono essere specificati in una direttiva di pagina.
    • A livello di codice, nel codice dell'applicazione. Questa impostazione può variare in base alla richiesta. Come per una direttiva di pagina, quando viene raggiunto il codice dell'applicazione è troppo tardi per specificare fileEncoding e requestEncoding. Solo uiCulture, culture e responseEncoding possono essere specificati nel codice dell'applicazione.

  5. Si noti che il valore di uiCulture può essere impostato sulla lingua del browser.

  6. Per le applicazioni distribuite, che consentono aggiornamenti senza tempi di inattività, ad esempio App contenitore di Azure, o applicazioni simili è necessario eseguire la pianificazoine per situazioni in cui possono essere presenti più istanze dell'applicazione con regole di formato diverse o altri dati relativi alle impostazioni cultura, in particolare regole del fuso orario.

    • Se la distribuzione dell'applicazione include un database, tenere presente che il database avrà regole di globalizzazione proprie. Nella maggior parte dei casi è consigliabile evitare di eseguire funzioni correlate alla globalizzazione nel database.
    • Se la distribuzione dell'applicazione include un'applicazione client o un front-end Web che usa risorse di globalizzazione client, si supponga che le risorse client differiscano dalle risorse disponibili per il server. Prendere in considerazione l'esecuzione esclusiva di funzioni di globalizzazione nel client.

Raccomandazioni per test affidabili

  1. Per rendere le dipendenze più esplicite e i test potenzialmente più semplici e parallelizzabili, è consigliabile considerare il passaggio esplicito di impostazioni rilevanti per le impostazioni cultura, ad esempio parametri CultureInfo ai metodi che eseguono la formattazione e TimeZoneInfo ai metodi che usano valori relativi a date e ore. È anche consigliabile usare TimeProvider o un tipo simile quando si recupera l'ora.

  2. Per la maggior parte dei test è consigliabile non convalidare in modo esplicito l'output esatto di una determinata operazione di formattazione o l'offset esatto di un fuso orario. La formattazione e i dati del fuso orario possono cambiare in qualsiasi momento e possono variare tra due istanze altrimenti identiche di un sistema operativo e potenzialmente processi diversi nello stesso computer. L'affidamento a un valore esatto rende i test fragili.

    • In genere, la convalida della ricezione di alcuni output sarà sufficiente, ad esempio, stringhe non vuote durante la formattazione.
    • Per alcuni elementi e formati di dati, è possibile usare in alternativa la convalida dell'analisi dei dati in base al valore di input (roundtripping). È necessario prestare attenzione ai casi in cui i campi vengono eliminati, ad esempio l'anno per alcuni campi correlati alla data, o il valore viene troncato o arrotondato, ad esempio per l'output a virgola mobile.
    • Se si hanno requisiti espliciti per convalidare tutti gli output del formato localizzato, è consigliabile prendere in considerazione la creazione e l'uso di impostazioni cultura personalizzate durante la configurazione dei test. Per i casi più semplici è possibile ottenere questo risultato creando un'istanza di un oggetto CultureInfo con il relativo costruttore new CultureInfo(..) e impostando le proprietà DateTimeFormat e NumberFormat. Per casi più complessi l'inserimento del tipo in una sottoclasse consente l'override di proprietà aggiuntive. Questo approccio comporta potenziali vantaggi aggiuntivi, ad esempio l'abilitazione della pseudolocalizzazione con i file di risorse.
    • Se sono presenti requisiti espliciti per convalidare i risultati di tutte le operazioni di data/ora, è consigliabile prendere in considerazione la creazione e l'uso di un'istanza di TimeZoneInfo personalizzata durante la configurazione dei test. Questo approccio comporta potenziali vantaggi aggiuntivi, ad esempio l'abilitazione di test stabili di determinati casi limite, come le modifiche alle regole DST.

Vedi anche