Partager via

Globalisation et localisation des solutions Excel

  • Article

Cette section contient des informations sur les considérations spéciales concernant les solutions Microsoft Office Excel appelées à être exécutées sur des ordinateurs dont les paramètres Windows sont autres qu’anglais. La plupart des aspects de la globalisation et de la localisation des solutions Microsoft Office sont les mêmes que ceux que vous rencontrez quand vous créez d’autres types de solutions à l’aide de Visual Studio. Pour obtenir des informations générales, consultez Globaliser et localiser des applications.

Par défaut, les contrôles hôtes dans Microsoft Office Excel fonctionnent correctement dans tous les paramètres régionaux Windows, dans la mesure où l’ensemble des données passées ou manipulées avec du code managé présentent une mise en forme Anglais (États-Unis). Dans les projets qui ciblent .NET Framework 4 ou .NET Framework 4.5, ce comportement est contrôlé par le Common Language Runtime (CLR).

S’applique à : les informations contenues dans cette rubrique s’appliquent aux projets au niveau du document et aux projets de complément VSTO pour Excel. Pour plus d’informations, consultez Fonctionnalités disponibles par application Office lication et le type de projet.

Mettre en forme des données dans Excel avec différents paramètres régionaux

Vous devez mettre en forme toutes les données ayant une mise en forme sensible aux paramètres régionaux, telles que les dates et les devises, en utilisant le format de données Anglais (États-Unis) (ID de paramètres régionaux 1033) avant de les passer à Microsoft Office Excel ou de lire ces données à partir du code de votre projet Office.

Par défaut, quand vous développez une solution Office dans Visual Studio, le modèle objet Excel attend la mise en forme de données correspondant à l’ID de paramètres régionaux 1033 (c’est ce que l’on appelle également verrouiller le modèle objet sur l’ID de paramètres régionaux 1033). Ce comportement correspond au mode de fonctionnement de Visual Basic pour Applications. Cependant, vous pouvez modifier ce comportement dans vos solutions Office.

Comprendre comment le modèle objet Excel attend toujours l’ID de paramètres régionaux 1033

Par défaut, les solutions Office que vous créez à l’aide de Visual Studio ne sont pas affectées par les paramètres régionaux de l’utilisateur final et se comportent toujours comme si les paramètres régionaux étaient Anglais (États-Unis). Par exemple, si vous obtenez ou définissez la propriété Value2 dans Excel, les données doivent être mises en forme comme l’attend l’ID de paramètres régionaux 1033. Si vous utilisez un autre format de données, vous risquez d’obtenir des résultats inattendus.

Même si vous utilisez le format Anglais (États-Unis) pour les données passées ou manipulées par du code managé, Excel interprète et affiche les données correctement en fonction des paramètres régionaux de l’utilisateur final. Excel peut mettre correctement en forme les données, car le code managé passe l’ID de paramètres régionaux 1033 en même temps que les données, ce qui indique que les données sont au format Anglais (États-Unis) et qu’elles doivent donc être remises en forme en fonction des paramètres régionaux de l’utilisateur.

Par exemple, si les utilisateurs finaux ont défini leurs options régionales sur les paramètres régionaux Allemand (Allemagne), ils s’attendent à ce que la date du 29 juin 2005 soit mise en forme de de cette façon : 29.06.2005. Or, si votre solution passe la date à Excel sous forme de chaîne, vous devez mettre en forme la date selon le format Anglais (États-Unis) : 6/29/2005. Si la cellule est mise en forme en tant que cellule de date, Excel affiche la date au format Allemand (Allemagne).

Passer d’autres ID de paramètres régionaux au modèle objet Excel

Le Common Language Runtime (CLR) passe automatiquement l’ID de paramètres régionaux 1033 à toutes les méthodes et propriétés du modèle objet Excel qui acceptent les données sensibles aux paramètres régionaux. Il n’y a aucun moyen de modifier ce comportement automatiquement pour tous les appels à destination du modèle objet. Cependant, vous pouvez passer un autre ID de paramètres régionaux à une méthode spécifique en utilisant InvokeMember pour appeler la méthode et en passant l’ID de paramètres régionaux au paramètre culture de la méthode.

Localiser le texte du document

Il est probable que le document, le modèle ou le classeur de votre projet contient du texte statique, qui doit être localisé séparément à partir de l’assembly et d’autres ressources managées. Une façon simple de procéder consiste à copier le document et à traduire le texte en utilisant Microsoft Office Word ou Microsoft Office Excel. Cette procédure fonctionne même si vous n’apportez pas de modifications au code, car vous pouvez lier n’importe quel nombre de documents à un même assembly.

Vous devez quand même vous assurer que les parties de votre code qui interagissent avec le texte du document continuent de correspondre à la langue du texte et que les signets, plages nommées et autres champs d’affichage s’accommodent de toute nouvelle mise en forme du document Office qui s’avérait nécessaire pour s’adapter à la grammaire et à la longueur de texte différentes. Pour les modèles de document qui contiennent peu de texte, vous pouvez envisager de stocker le texte dans des fichiers de ressources, puis de le charger au moment de l’exécution.

Sens du texte

Dans Excel, vous pouvez définir une propriété de la feuille de calcul pour afficher le texte de droite à gauche. Les contrôles hôtes, ou tout contrôle qui a une RightToLeft propriété, placés sur le concepteur correspondent automatiquement à ces paramètres au moment de l’exécution. Word n’a pas de paramètre de document pour le texte bidirectionnel (vous modifiez simplement votre alignement du texte), de sorte que les contrôles ne peuvent pas être mappés à ce paramètre. Au lieu de cela, vous devez définir l’alignement du texte pour chaque contrôle. Il est possible d’écrire du code qui parcoure tous les contrôles et les force à afficher le texte de droite à gauche.

Modifier la culture

Votre code de personnalisation au niveau du document partage généralement le thread d’interface utilisateur principal d’Excel. De ce fait, toute modification que vous apportez à la culture du thread affecte tout ce qui s’exécute sur celui-ci ; la modification ne se limite pas à votre personnalisation.

Les contrôles Windows Forms sont initialisés avant que l’application hôte démarre les compléments VSTO de niveau application. En pareil cas, la culture doit être modifiée avant de définir les contrôles d’interface utilisateur.

Installer les modules linguistiques

Si vous avez des paramètres non anglais pour Windows, vous pouvez installer les modules linguistiques Visual Studio Tools pour Office runtime pour afficher Visual Studio Tools pour Office messages d’exécution dans la même langue que Windows. Si des utilisateurs finals n’exécutent pas vos solutions avec des paramètres Anglais pour Windows, ils doivent disposer du module linguistique approprié pour voir les messages du runtime dans la même langue que celle de Windows. Les modules linguistiques Visual Studio Tools pour Office runtime sont disponibles à partir du Centre de téléchargement Microsoft.

Par ailleurs, les modules linguistiques .NET Framework sont nécessaires pour les messages ClickOnce. Les modules linguistiques .NET Framework sont disponibles à 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 la propriété CurrentCulture (paramètres régionaux) qui correspond aux paramètres régionaux du thread actif. Par défaut, les paramètres régionaux du thread actif sont hérités des paramètres régionaux de l’utilisateur. Cependant, quand vous effectuez un appel dans le modèle objet Excel à partir d’une solution Excel créée à l’aide des outils de développement Office dans Visual Studio, le format de données Anglais (États-Unis) (ID de paramètres régionaux 1033) est passé automatiquement au modèle objet Excel. Vous devez mettre en forme toutes les données ayant une mise en forme sensible aux paramètres régionaux, telles que les dates et les devises, en utilisant le format de données Anglais (États-Unis) avant de les passer à Microsoft Office Excel ou de lire ces données à partir du code de votre projet.

Considérations relatives au stockage des données

Pour assurer une interprétation et une lecture correctes de vos données, vous devez aussi savoir que des problèmes peuvent survenir quand une application stocke des données (par exemple, les formules dans les feuilles de calcul Excel) dans des littéraux de chaîne (codés en dur) et non dans des objets fortement typés. Vous devez utiliser des données mises en forme dans un style indépendant de la culture ou au format Anglais (États-Unis) (valeur LCID 1033).

Applications qui utilisent des littéraux de chaîne

Parmi les valeurs qui peuvent être codées en dur figurent les littéraux de date écrits au format Anglais (États-Unis) et les formules de feuille de calcul Excel qui contiennent des noms de fonctions localisés. Une chaîne codée en dur contenant un nombre tel que « 1,000 » est une autre possibilité ; dans certaines cultures, ce nombre est interprété comme un millier, mais dans d’autres, il représente « un virgule zéro ». Les calculs et les comparaisons effectués sur un format incorrect peuvent produire des données incorrectes.

Excel interprète les chaînes conformément au LCID qui est passé avec celles-ci. Cela peut poser un problème si le format de la chaîne ne correspond pas au LCID passé. Les solutions Excel créées à l’aide des outils de développement Office dans Visual Studio utilisent le LCID 1033 (en-US) au moment de passer toutes les données. Excel affiche les données en fonction des paramètres régionaux et de la langue de l’interface utilisateur Excel. Visual Basic pour Applications (VBA) fonctionne aussi de cette façon ; les chaînes sont mises en forme au format en-US et VBA passe presque toujours 0 (indépendant de la langue) en guise de LCID. Par exemple, le code VBA suivant affiche une valeur correctement mise en forme pour le 12 mai 2004, conformément au paramètre de paramètres régionaux de l’utilisateur actuel :

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

Ce même code, quand il est utilisé dans une solution créée à l’aide des outils de développement Office dans Visual Studio et passé à Excel via COM Interop, produit les mêmes résultats quand la date est mise en forme dans le style en-US.

Par exemple :

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

Vous avez tout intérêt à utiliser des données fortement typées à la place de littéraux de chaîne chaque fois que vous en avez la possibilité. Par exemple, au lieu de stocker une date dans un littéral de chaîne, stockez-la sous forme de Double, puis convertissez-le en objet DateTime pour la manipulation.

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

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

Fonctions de feuille de calcul Excel

Les noms de fonctions de feuille de calcul sont traduits en interne pour la plupart des versions linguistiques d’Excel. Toutefois, en raison de problèmes potentiels de langue et d’interopérabilité COM, il est recommandé d’utiliser uniquement les noms de fonctions anglaises 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) exportés à partir d’un système hérité, peut aussi être affecté si ces fichiers sont exportés en utilisant un format en plus de « en-US ». Il se peut que l’accès à la base de données ne soit pas affecté, car toutes les valeurs sont censées être au format binaire, à moins que la base de données stocke les dates sous forme de chaînes ou exécute des opérations qui n’utilisent pas le format binaire. De même, si vous créez des requêtes SQL en utilisant des données à partir d’Excel, vous devrez peut-être vérifier qu’elles sont au format en-US, selon la fonction que vous utilisez.

Contenu connexe