Globalizzazione e localizzazione di soluzioni Office

Articolo
04/28/2010

Aggiornamento: novembre 2007

Gli aspetti da considerare per la globalizzazione e la localizzazione di soluzioni Microsoft Office sono gli stessi implicati negli altri tipi di soluzioni create con Visual Studio. Per informazioni di carattere generale, vedere Globalizzazione e localizzazione di applicazioni. Informazioni sulla globalizzazione e sulla localizzazione sono disponibili anche nella pagina Web MSDN Globalization and Localization Issues for Solutions Created with Microsoft Visual Studio Tools for the Microsoft Office System (informazioni in lingua inglese).

Localizzazione di documenti di testo

I documenti, i modelli o le cartelle di lavoro contenute in un progetto includono in genere testo statico che deve essere localizzato separatamente dall'assembly e dalle altre risorse gestite. Un metodo diretto per effettuare questa operazione consiste nell'eseguire una copia del documento e tradurre il testo in Microsoft Office Word o Microsoft Office Excel. Questo processo funziona anche se non si apportano modifiche al codice, in quanto è possibile collegare un numero illimitato di documenti allo stesso assembly.

È tuttavia necessario assicurarsi che tutte le parti del codice che interagiscono con il testo del documento continuino a corrispondere alla lingua del testo e che i segnalibri, gli intervalli denominati e gli altri campi visualizzati si adattino alle eventuali riformattazioni del documento di Office necessarie per rispettare le differenze nella grammatica e nella lunghezza del testo. Per i modelli di documenti che contengono testo relativamente breve, è possibile memorizzare il testo in file di risorse per poi caricarlo in fase di esecuzione.

Orientamento del testo

In Excel, è possibile impostare una proprietà del foglio di lavoro per il rendering del testo da destra a sinistra. I controlli host e i controlli che dispongono della proprietà RightToLeft posizionati nella finestra di progettazione riflettono automaticamente queste impostazioni in fase di esecuzione. I documenti di Word non dispongono di una specifica impostazione per il testo bidirezionale (è possibile modificare solo l'allineamento del testo) cui mappare i controlli, che devono quindi essere impostati individualmente. È possibile scrivere codice per esaminare tutti i controlli e imporre il rendering del testo da destra a sinistra.

Modifica delle impostazioni cultura

Poiché il codice di personalizzazione in genere condivide il thread principale di interfaccia utente di Word o Excel, le modifiche apportate alle impostazioni cultura del thread influiscono su tutti gli oggetti eseguiti su tale thread: la modifica non è limitata alla personalizzazione.

I controlli Windows Form vengono inizializzati prima dell'avvio dei componenti aggiuntivi di Visual Studio Tools per Office da parte dell'applicazione host. In queste situazioni, le impostazioni cultura devono essere modificate prima dell'impostazione dei controlli di interfaccia utente.

Installazione dei Language Pack

Se Windows è impostato su una lingua diversa dall'inglese, è possibile installare i Language Pack°per°Visual Studio Tools per Office in modo da visualizzare i messaggi di Visual Studio Tools per Office Runtime nella stessa lingua di Windows. Se un utente finale esegue le soluzioni con Windows impostato su una lingua diversa dall'inglese, deve disporre del Language Pack corretto per visualizzare i messaggi di runtime nella stessa lingua di Windows. I Language Pack per°Visual Studio Tools per Office sono disponibili nell'Area download Microsoft.

Inoltre, sono necessari i Language Pack per .NET Framework ridistribuibili per i messaggi di ClickOnce. I Language Pack per .NET Framework sono disponibili in Microsoft Download Center (informazioni in lingua inglese).

Impostazioni internazionali e chiamate COM di Excel

Ogni volta che un client gestito chiama un metodo su un oggetto COM e deve passare informazioni specifiche delle impostazioni cultura, utilizza l'oggetto CurrentCulture (impostazioni locali) che corrisponde alle impostazioni locali del thread corrente. Queste, per impostazione predefinita, vengono ereditate dalle impostazioni internazionali dell'utente. Tuttavia, quando si effettua una chiamata nel modello a oggetti di Excel, Visual Studio Tools per Office°passa automaticamente un identificatore delle impostazioni locali (LCID) della lingua inglese. Tutti i dati con formattazione dipendente dalle impostazioni locali, ad esempio le date e la valuta, devono essere formattati utilizzando il formato dati inglese (Stati Uniti) con LCID 1033 prima di essere passati a Microsoft Office Excel o prima che vengano letti i dati dal codice del progetto°Visual Studio Tools per Office. Per ulteriori informazioni, vedere Formattazione di dati in Excel con varie impostazioni internazionali.

Questo comportamento viene controllato dall'attributo ExcelLocale1033Attribute. È possibile modificare il comportamento in modo che i dati vengano passati utilizzando l'LCID del thread corrente tramite l'impostazione della classe ExcelLocale1033Attribute su false. Sarà quindi possibile scrivere il proprio codice per gestire l'interazione tra Excel e il codice gestito. Per ulteriori informazioni, vedere Procedura: specificare stringhe letterali indipendenti dalle impostazioni internazionali in Excel mediante la reflection.

Considerazioni relative all'archiviazione di dati

Per garantire la corretta interpretazione e visualizzazione dei dati, è necessario considerare anche i potenziali problemi che possono verificarsi quando un'applicazione memorizza dati, incluse le formule dei fogli di lavoro di Excel, in stringhe letterali (hardcoded) invece che in oggetti fortemente tipizzati. Sarà opportuno utilizzare dati formattati presumendo uno stile indipendente dalle impostazioni cultura o impostato sulla lingua inglese (Stati Uniti) (valore di LCID en-US).

Applicazioni che utilizzano stringhe letterali

Tra i valori che potrebbero essere specificati a livello di codice (hard-coded) sono inclusi i valori letterali data scritti in formato inglese (Stati Uniti) e le formule dei fogli di lavoro di Excel che contengono nomi di funzioni localizzati. Un altro valore di questo tipo potrebbe essere rappresentato da una stringa hardcoded contenente un numero come "1,000": in alcune culture, questo numero viene interpretato come "mille", in altre come "uno virgola zero". I calcoli e i confronti eseguiti con un formato errato possono produrre dati non corretti.

In Excel, ogni stringa viene interpretata in base all'LCID passato con essa. Può trattarsi di un problema se il formato della stringa non corrisponde all'LCID passato. In Visual Studio Tools per Office viene utilizzato l'LCID 1033 (en-US) per il passaggio di tutti i dati. In Excel, i dati sono visualizzati in base alle impostazioni internazionali e alla lingua dell'interfaccia utente dell'applicazione. In Visual Basic, Applications Edition (VBA), le stringhe sono formattate nello stile en-US e come LCID viene quasi sempre passato 0 (valore che indica l'indipendenza dalla lingua). Ad esempio, nel codice VBA riportato di seguito viene visualizzato un valore formattato correttamente per la data 12 maggio 2004, in base alle impostazioni locali correnti dell'utente.

'VBA
Application.ActiveCell.Value2 = "05/12/04"

Lo stesso codice, se utilizzato in una soluzione°Visual Studio Tools per Office e passato a Excel tramite l'interoperabilità COM, produce gli stessi risultati quando la data viene formattata in stile en-US.

Ad esempio:

Me.Range("A1").Value2 = "05/12/04"

this.Range["A1", missing].Value2 = "05/12/04";

Quando possibile, si consiglia di utilizzare dati fortemente tipizzati invece di stringhe letterali. Ad esempio, invece di memorizzare una data in una stringa letterale, memorizzarla come valore Double, quindi convertirla in un oggetto DateTime per la modifica.

Nel codice riportato di seguito, una data immessa dall'utente nella cella A5 viene accettata, quindi memorizzata come valore Double, infine convertita in un oggetto DateTime per la visualizzazione nella cella A7. La cella A7 deve essere formattata per la visualizzazione della data.

Private Sub ConvertDate_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) _
    Handles ConvertDate.Click

    Try
        Dim dbl As Double = Me.Range("A5").Value2
        Dim dt As System.DateTime = System.DateTime.FromOADate(dbl)
        Me.Range("A7").Value2 = dt

    Catch ex As Exception
        MessageBox.Show(ex.Message)
    End Try
End Sub

private void ConvertDate_Click(object sender, EventArgs e)
{
    try
    {
        double dbl = (double)(this.Range["A5", missing].Value2);
        System.DateTime dt = System.DateTime.FromOADate(dbl);
        this.Range["A7", missing].Value2 = dt;
    }
    catch (Exception ex)
    {
        MessageBox.Show(ex.Message);
    }
}

Funzioni dei fogli di lavoro di Excel

I nomi delle funzioni dei fogli di lavoro sono tradotti internamente per la maggior parte delle versioni localizzate di Excel. Tuttavia, per evitare potenziali problemi relativi alla lingua e all'interoperabilità COM, si consiglia di utilizzare nel codice solo i nomi delle funzioni per la lingua inglese.

Applicazioni in cui sono utilizzati dati esterni

Anche nel codice in base al quale vengono aperti o utilizzati in altro modo dati esterni, ad esempio file che includono valori separati da virgole (CSV) esportati da un sistema legacy, possono verificarsi problemi se tali file sono esportati utilizzando un altro formato insieme al formato en-US. L'accesso al database non dovrebbe essere influenzato, in quanto si presuppone che tutti i valori siano in formato binario, a meno che non vi siano memorizzate date sotto forma di stringhe o vi vengano eseguite operazioni per le quali non è impiegato il formato binario. Inoltre, se si creano query SQL mediante i dati di Excel, a seconda della funzione utilizzata potrebbe essere necessario verificare che siano in formato en-US.