Globalizzazione e localizzazione di soluzioni Excel
Questa sezione contiene considerazioni speciali per le soluzioni Microsoft Office Excel eseguite in computer che hanno impostazioni di Windows non in inglese. 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 generali, vedere Globalizzare e localizzare le applicazioni.
Per impostazione predefinita, i controlli host in Microsoft Office Excel funzionano correttamente con tutte le impostazioni internazionali di Windows, a condizione che tutti i dati passati o modificati tramite codice gestito vengano formattati usando la formattazione per la lingua inglese (Stati Uniti). Nei progetti destinati a .NET Framework 4 o .NET Framework 4.5, questo comportamento è controllato da Common Language Runtime (CLR).
Si applica a: le informazioni contenute in questo argomento si applicano ai progetti a livello di documento e ai progetti di componente aggiuntivo VSTO per Excel. Per altre informazioni, vedere Funzionalità disponibili per app Office lication e tipo di progetto.
Formattare i dati in Excel con varie impostazioni internazionali
Tutti i dati con formattazione dipendente dalle impostazioni locali, ad esempio le date e la valuta, devono essere formattati usando il formato dati inglese (Stati Uniti) con ID delle impostazioni locali 1033 prima di essere passati a Microsoft Office Excel o prima che vengano letti dal codice del progetto di Office.
Per impostazione predefinita, quando si sviluppa una soluzione Office in Visual Studio, il modello a oggetti di Excel si aspetta la formattazione dei dati secondo l'ID delle impostazioni locali 1033 (tale operazione viene anche definita blocco del modello a oggetti sull'ID delle impostazioni locali 1033). Questo comportamento corrisponde alla modalità di funzionamento di Visual Basic, Applications Edition. Tuttavia, questo comportamento può essere modificato nelle soluzioni Office.
Informazioni sul modo in cui il modello a oggetti di Excel prevede sempre l'ID delle impostazioni locali 1033
Per impostazione predefinita, le impostazioni locali dell'utente finale non hanno effetto sulle soluzioni Office create con Visual Studio, il cui comportamento rimane sempre quello relativo alle impostazioni locali per la lingua inglese (Stati Uniti). Ad esempio, se si ottiene o si imposta la proprietà Value2 in Excel, i dati devono essere formattati nel modo previsto dall'ID delle impostazioni locali 1033. Se si usa un formato dati diverso, si potrebbero ottenere risultati imprevisti.
Anche se si usa il formato inglese (Stati Uniti) per i dati passati o modificati da codice gestito, Excel interpreta e visualizza i dati correttamente in base alle impostazioni locali dell'utente finale. In Excel i dati vengono formattati in maniera corretta perché il codice gestito passa l'ID delle impostazioni locali 1033 insieme ai dati, a indicare che i dati sono nel formato inglese (Stati Uniti) e quindi devono essere riformattati in modo da corrispondere alle impostazioni locali dell'utente.
Se ad esempio le opzioni internazionali degli utenti finali sono impostate sulle impostazioni locali per la lingua tedesca (Germania), ci si aspetta che la data 29 giugno 2005 sia formattata come segue: 29.06.2005. Tuttavia, se la soluzione passa la data a Excel sotto forma di stringa, è necessario formattare la data in base al formato inglese (Stati Uniti): 6/29/2005. Se la cella viene formattata come una cella di data, Excel visualizzerà la data nel formato della lingua tedesca (Germania).
Passare altri ID impostazioni locali al modello a oggetti di Excel
Common Language Runtime (CLR) passa automaticamente l'ID delle impostazioni locali 1033 a tutti i metodi e le proprietà nel modello a oggetti di Excel che accettano i dati dipendenti dalle impostazioni locali. Non è possibile modificare automaticamente questo comportamento per tutte le chiamate nel modello a oggetti. Tuttavia, è possibile passare un ID delle impostazioni locali diverso a un metodo specifico usando InvokeMember per chiamare il metodo e passando l'ID delle impostazioni locali al parametro culture del metodo.
Localizzare il testo del documento
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.
Direzione del testo
In Excel, è possibile impostare una proprietà del foglio di lavoro per il rendering del testo da destra a sinistra. I controlli host o qualsiasi controllo con una RightToLeft proprietà posizionata nella finestra di progettazione corrisponde automaticamente a queste impostazioni in fase di esecuzione. Word non dispone di un'impostazione del documento per il testo bidirezionale (è sufficiente modificare l'allineamento del testo), quindi i controlli non possono essere mappati a questa impostazione. che devono quindi essere impostati individualmente. È possibile scrivere codice per esaminare tutti i controlli e imporre il rendering del testo da destra a sinistra.
Modificare le impostazioni cultura
Il codice di personalizzazione a livello di documento in genere condivide il thread principale dell'interfaccia utente di Excel, per cui tutte le modifiche apportate alle impostazioni cultura del thread influiscono su qualsiasi altro elemento in esecuzione su tale thread. La modifica non è limitata alla personalizzazione.
I controlli Windows Form vengono inizializzati prima dell'avvio dei componenti aggiuntivi VSTO a livello di applicazione da parte dell'applicazione host. In queste situazioni, le impostazioni cultura devono essere modificate prima dell'impostazione dei controlli dell'interfaccia utente.
Installare i Language Pack
Se sono disponibili impostazioni non in lingua inglese per Windows, è possibile installare il Strumenti di Visual Studio per i Language Pack di runtime di Office per visualizzare Strumenti di Visual Studio per i messaggi di runtime di Office nella stessa lingua di Windows. Se gli utenti finali eseguono le soluzioni con le impostazioni non in lingua inglese per Windows, devono avere il Language Pack corretto per visualizzare i messaggi di runtime nella stessa lingua di Windows. Le Strumenti di Visual Studio per i Language Pack di runtime di 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 di .NET Framework sono disponibili nell'Area download Microsoft.
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, usa la proprietà CurrentCulture (impostazioni locali) che corrisponde alle impostazioni locali del thread corrente, che per impostazione predefinita vengono ereditate dalle impostazioni internazionali dell'utente. Tuttavia, quando si effettua una chiamata nel modello a oggetti di Excel da una soluzione Excel creata tramite gli strumenti di sviluppo di Office in Visual Studio, il formato dati inglese (Stati Uniti) con ID delle impostazioni locali 1033 viene passato automaticamente al modello a oggetti di Excel. Tutti i dati con formattazione dipendente dalle impostazioni locali, ad esempio le date e la valuta, devono essere formattati usando il formato dati inglese (Stati Uniti) prima di essere passati a Microsoft Office Excel o prima che vengano letti dal codice del progetto.
Considerazioni per l'archiviazione dei dati
Per garantire che i dati vengano interpretati e visualizzati correttamente, è necessario considerare anche i problemi che possono verificarsi quando un'applicazione archivia i dati, come le formule dei fogli di lavoro di Excel, in valori letterali stringa (hardcoded) anziché in oggetti fortemente tipizzati. È consigliabile usare i dati formattati presumendo uno stile indipendente dalle impostazioni cultura o impostato sulla lingua inglese (Stati Uniti) con ID delle impostazioni locali 1033.
Applicazioni che usano valori letterali stringa
Tra i valori che potrebbero essere specificati a livello di codice (hardcoded) 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'altra possibilità potrebbe essere una stringa hardcoded contenente un numero come "1,000". In alcune impostazioni cultura questo numero viene interpretato come "mille", mentre in altre come "uno virgola zero". I calcoli e i confronti eseguiti con un formato errato possono produrre dati non corretti.
Excel interpreta ogni stringa in base all'ID delle impostazioni locali passato con la stringa. Ciò può rappresentare un problema se il formato della stringa non corrisponde all'ID delle impostazioni locali passato. Le soluzioni Excel create tramite gli strumenti di sviluppo di Office in Visual Studio usano l'ID delle impostazioni locali 1033 (en-US) quando vengono passati tutti i dati. Excel visualizza i dati in base alle impostazioni internazionali e alla lingua dell'interfaccia utente di Excel. Visual Basic, Applications Edition (VBA) funziona allo stesso modo. Le stringhe vengono formattate come en-US e VBA passa quasi sempre 0 (valore che indica l'indipendenza dalla lingua) come LCID. Ad esempio, il codice VBA seguente visualizza un valore formattato correttamente per il 12 maggio 2004, in base all'impostazione delle impostazioni locali dell'utente corrente:
'VBA
Application.ActiveCell.Value2 = "05/12/04"
Lo stesso codice, se usato in una soluzione creata tramite gli strumenti di sviluppo di Office in Visual Studio e passato a Excel tramite l'interoperabilità COM, produce gli stessi risultati quando la data viene formattata in stile en-US.
Ad esempio:
Quando possibile, si consiglia di usare dati fortemente tipizzati invece di valori letterali stringa. Ad esempio, invece di archiviare una data in un valore letterale stringa, archiviarla come valore Double, quindi convertirla in un oggetto DateTime per la modifica.
L'esempio di codice seguente accetta una data immessa dall'utente nella cella A5, quindi la archivia come valore Double, infine la converte in un oggetto DateTime per la visualizzazione nella cella A7. La cella A7 deve essere formattata per la visualizzazione della data.
private void ConvertDate_Click(object sender, EventArgs e)
{
try
{
double dbl = (double)(this.Range["A5"].Value2);
System.DateTime dt = System.DateTime.FromOADate(dbl);
this.Range["A7"].Value2 = dt;
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
}
Funzioni del foglio 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, a causa di potenziali problemi di interoperabilità COM e lingua, è consigliabile usare solo nomi di funzione in inglese nel codice.
Applicazioni che usano dati esterni
Anche il codice che apre o usa in altro modo dati esterni, ad esempio file che includono valori separati da virgole (CSV) esportati da un sistema legacy, può essere interessato se tali file vengono esportati in un altro formato diverso da en-US. L'accesso al database potrebbe non essere influenzato, in quanto si presuppone che tutti i valori siano in formato binario, a meno che il database non archivi date sotto forma di stringhe o esegua operazioni che non usano il formato binario. Inoltre, se si creano query SQL mediante i dati di Excel, a seconda della funzione usata potrebbe essere necessario verificare che siano in formato en-US.