Globalisation et localisation de solutions Office

Article
04/28/2010

Mise à jour : novembre 2007

La plupart des aspects relatifs à la globalisation et la localisation de solutions Microsoft Office sont identiques à ceux que vous pouvez rencontrer lors de la création d'autres types de solutions à l'aide de Visual Studio. Pour obtenir des informations générales, consultez Globalisation et localisation d'applications. Des informations relatives à la globalisation et à la localisation sont également disponibles sur la page Web MSDN Problèmes de globalisation et de localisation pour les solutions créées avec les outils Microsoft Visual Studio pour Microsoft Office system.

Localisation du texte du document

Le document, le modèle ou le classeur de votre projet inclut probablement du texte statique, lequel doit être localisé de manière séparée par rapport à l'assembly et aux autres ressources managées. Une manière directe d'y parvenir consiste à créer une copie du document et à traduire le texte à l'aide de Microsoft Office Word ou Microsoft Office Excel. Ce processus fonctionne même si vous n'apportez aucune modification au code car un nombre illimité de documents peut être lié au même assembly.

Toutefois, vous devez veiller à ce que toutes les parties de votre code qui interagissent avec le texte du document continuent de correspondre à la langue du texte. Vous devez également vous assurer que les signets, plages nommées et autres champs affichés prennent en charge la remise en forme du document Office, imposée par la différence de grammaire et la longueur du texte. Pour les modèles de document qui contiennent peu de texte, vous souhaitez peut-être stocker le texte dans des fichiers de ressources, puis charger celui-ci au moment de l'exécution.

Orientation du texte

Dans Excel, vous pouvez définir une propriété de la feuille de calcul de manière à rendre le texte de droite à gauche. Les contrôles hôtes, ou tous les contrôles ayant une propriété RightToLeft, qui sont placés sur le concepteur, respectent automatiquement ces paramètres au moment de l'exécution. Word ne possède pas de paramètre de document pour le texte bidirectionnel (vous modifiez juste votre alignement de texte) ; par conséquent, les contrôles ne peuvent pas être mappés à ce paramètre. Vous devez plutôt définir l'alignement de texte pour chaque contrôle. Il est possible d'écrire du code afin de parcourir tous les contrôles et de les forcer à rendre le texte de droite à gauche.

Variations culturelles

Votre code de personnalisation partage généralement le thread d'interface utilisateur principal de Word ou Excel. Ainsi, toutes les modifications apportées à la culture du thread affectent l'ensemble des éléments exécutés sur ce thread ; les modifications ne se limitent pas à votre personnalisation.

Les contrôles Windows Forms sont initialisés avant le démarrage des compléments Visual Studio Tools pour Office par l'application hôte. Dans ces situations, la culture doit être modifiée avant la définition des contrôles d'interface utilisateur.

Installation des modules linguistiques

Si des paramètres autres que l'anglais sont disponibles pour Windows, vous pouvez installer les modules linguistiques Visual Studio Tools pour Office pour afficher les messages d'exécution de Visual Studio Tools pour Office dans la langue de Windows. Si un utilisateur final exécute vos solutions avec des paramètres autres que l'anglais pour Windows, il doit disposer du module linguistique approprié pour afficher les messages d'exécution dans la langue de Windows. Les modules linguistiques de Visual Studio Tools pour Office peuvent être téléchargés à partir du Centre de téléchargement Microsoft.

De plus, les modules linguistiques du .NET Framework redistribuables sont nécessaires pour les messages ClickOnce. Ces modules linguistiques peuvent être téléchargés à partir du Centre de téléchargement Microsoft.

Paramètres régionaux et appels COM Excel

Chaque fois qu'un client managé appelle une méthode sur un objet COM et qu'il doit passer des informations spécifiques à la culture, il utilise les CurrentCulture (paramètres régionaux) qui correspondent aux paramètres régionaux du thread courant. Les paramètres régionaux du thread courant sont hérités par défaut des paramètres régionaux de l'utilisateur. Toutefois, lorsque vous effectuez un appel dans le modèle objet Excel, Visual Studio Tools pour Office passe automatiquement un identificateur de paramètres régionaux (LCID) de culture dite indifférente. Vous devez convertir toutes les données qui présentent une mise en forme sensible aux paramètres régionaux, telles que les dates et les devises, au format de données Anglais (États-Unis) (LCID 1033) avant de les transmettre à Microsoft Office Excel ou de lire les données à partir du code de votre projet Visual Studio Tools pour Office. Pour plus d'informations, consultez Mise en forme de données dans Excel avec différents paramètres régionaux.

Ce comportement est contrôlé par l'attribut ExcelLocale1033Attribute. Vous pouvez modifier le comportement afin que les données soient passées à l'aide du LCID du thread actuel en attribuant la valeur false à ExcelLocale1033Attribute. Vous pouvez ensuite écrire votre propre code pour gérer l'interaction entre Excel et le code managé. Pour plus d'informations, consultez Comment : rendre les littéraux de chaîne sécurisés du point de vue de la région dans Excel à l'aide de la réflexion.

Considérations sur le stockage des données

Pour garantir l'interprétation et l'affichage corrects de vos données, vous devez également tenir compte des problèmes pouvant survenir lorsqu'une application stocke des données, y compris les formules de feuille de calcul Excel, dans des littéraux de chaîne (codés en dur) plutôt que dans des objets fortement typés. Vous devez utiliser des données mises en forme à l'aide d'une culture dite indifférente ou du style Anglais (États-Unis) (la valeur LCID en-US).

Applications qui utilisent des littéraux de chaîne

Les valeurs qui peuvent être codées en dur incluent les littéraux de date écrits au format Anglais (États-Unis) et les formules de feuille de calcul Excel qui contiennent des noms de fonction localisés. Une autre possibilité peut être une chaîne codée en dur qui contient un nombre tel que "1 000" ; dans certaines cultures, ce nombre est interprété comme la valeur "mille", mais dans d'autres cultures, il représente la valeur "un virgule zéro". Les calculs et les comparaisons effectués au format inapproprié peuvent générer des données incorrectes.

Excel interprète toutes les chaînes conformément au LCID qui est passé avec la chaîne. Cela peut s'avérer problématique si le format de la chaîne ne correspond pas au LCID passé. Visual Studio Tools pour Office utilise le LCID 1033 (en-US) lors du passage de toutes les données. Excel affiche les données d'après les paramètres régionaux et la langue de l'interface utilisateur Excel. Visual Basic for Applications (VBA) fonctionne de cette manière ; les chaînes sont mises en forme en tant que en-US et VBA passe presque toujours la valeur 0 (indépendant de la langue) pour le LCID. Par exemple, le code VBA suivant affiche une valeur correctement mise en forme pour le 12 mai 2004, conformément aux paramètres régionaux de l'utilisateur actuel :

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

Le même code, utilisé dans une solution Visual Studio Tools pour Office et passé à Excel via COM Interop, produit des résultats identiques lorsque la date est mise en forme selon le style en-US.

Par exemple :

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

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

Dans la mesure du possible, vous devez utiliser des données fortement typées plutôt que des littéraux de chaîne. Par exemple, au lieu de stocker une date dans un littéral de chaîne, stockez-la en tant que Double, puis convertissez-la en objet DateTime pour pouvoir la manipuler.

L'exemple de code suivant utilise une date entrée par un utilisateur dans la cellule A5, la stocke en tant que Double, puis la convertit en objet DateTime pour l'affichage dans la cellule A7. La cellule A7 doit être mise en forme pour afficher une date.

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);
    }
}

Fonctions de classeur Excel

Les noms de fonctions de classeur sont traduits en interne pour la plupart des versions linguistiques d'Excel. Toutefois, en raison des éventuels problèmes liés à la langue et à COM Interop, il est fortement recommandé d'utiliser uniquement des noms de fonction anglais dans votre code.

Applications qui utilisent des données externes

Tout code ouvrant ou utilisant des données externes, telles que des fichiers contenant des valeurs séparées par des virgules (fichiers CSV) et exportés à partir d'un système hérité (legacy), peut également être affecté si ces fichiers sont exportés avec un format autre que en-US. L'accès aux bases de données peut ne pas être affecté, car toutes les valeurs doivent être au format binaire, à moins que la base de données ne stocke des dates en tant que chaînes ou n'exécute des opérations qui n'utilisent pas le format binaire. De même, si vous créez des requêtes SQL à l'aide de données contenues dans Excel, vous devrez peut-être vérifier qu'elles sont au format en-US, selon la fonction que vous utilisez.