Globalisation et localisation de solutions Excel

Article
03/22/2013

Cette section contient des informations concernant des considérations spéciales pour les solutions Microsoft Office Excel qui seront exécutées sur des ordinateurs associés à des paramètres non anglais pour Windows.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.

Par défaut, les contrôles hôtes fonctionnent correctement dans Microsoft Office Excel, quels que soient les paramètres régionaux Windows, tant que l'ensemble des données passées ou manipulées à l'aide du code managé sont mises en forme en anglais (États-Unis).Dans les projets qui ciblent .NET Framework 4 ou .NET Framework 4.5, ce comportement est contrôlé par le common langage runtime (CLR).

S'applique à : Les informations contenues dans cette rubrique s'appliquent aux projets de niveau document et de niveau application pour Excel 2013 et Excel 2010. Pour en savoir plus, consultez Fonctionnalités disponibles par type d'application et de projet Office.

Données de mise en forme dans Excel avec différents paramètres régionaux

Vous devez mettre en forme toutes les données possédant un formatage qui dépend des paramètres régionaux, telles que les dates et les devises, à l'aide du format de données Anglais (États-Unis) (ID 1033) avant de les passer à Microsoft Office Excel ou de lire les données du code dans votre projet Office.

Par défaut, lorsque vous développez une solution Office dans Visual Studio, le modèle objet Excel attend la mise en forme des données avec l'ID de paramètres régionaux 1033 (procédure également appelée verrouillage du modèle objet à l'ID de paramètres régionaux 1033).Ce comportement correspond à la manière dont Visual Basic for Applications fonctionne.Toutefois, vous pouvez modifier ce comportement dans vos solutions Office.

Comment le modèle objet d'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'ID de paramètres régionaux 1033 s'y attend.Si vous utilisez un format de données différent, vous pouvez obtenir des résultats inattendus.

Bien que vous utilisiez le format Anglais (États-Unis) pour des données transmises ou manipulées par un code managé, Excel interprète et affiche correctement les données en fonction des paramètres régionaux en vigueur sur l'ordinateur de l'utilisateur final.Excel peut mettre les données en forme correctement parce que le code managé transmet l'ID de paramètres régionaux 1033 avec les données. Cet ID indique que les données sont au format Anglais (États-Unis) et que, par conséquent, elles doivent être reformatées pour correspondre aux paramètres régionaux en vigueur sur l'ordinateur de l'utilisateur.

Par exemple, si les paramètres régionaux des utilisateurs finaux sont définies sur Allemand (Allemagne), ces utilisateurs s'attendent à ce que la date du 29 juin 2005 soit mise en forme de cette façon : 29.06.2005.Toutefois, si votre solution transmet la date à Excel sous la forme d'une chaîne, vous devez mettre cette date en forme selon le format Anglais (États-Unis) : 6/29/2005.Si la cellule est mise en forme en tant que cellule de type Date, Excel affiche la date au format Allemand (Allemagne).

Passage d'autres ID de paramètres régionaux au modèle objet Excel

Le common langage 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 des données des paramètres régionaux.Il n'existe aucun moyen de changer ce comportement automatiquement pour tous les appels du modèle objet.Toutefois, vous pouvez passer un ID de paramètres régionaux différent à 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.

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 au niveau de le document partage généralement le thread d'interface utilisateur principal excel, afin que toutes les modifications que vous apportez aux affecte de culture d'amorçage tout le reste qui s'exécute sur l'amorçage ; la modification n'est pas limitée à votre personnalisation.

Les contrôles Windows Forms sont initialisés avant que les compléments d'application ne soient démarrés 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 vous utilisez des paramètres autres que l'anglais pour Windows, vous pouvez installer les modules linguistiques Visual Studio Tools pour Office Runtime pour consulter les messages Visual Studio Tools pour Office Runtime dans la même langue que celle de Windows.Si les utilisateurs finaux exécutent vos solutions avec des paramètres autres que l'anglais pour windows, ils doivent disposer du module linguistique approprié pour consulter les messages d'exécution dans la même langue que celle de windows. Les modules linguistiques d' Visual Studio Tools pour Office Runtime sont disponibles dans Le 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 passez un appel dans le modèle objet Excel d'une solution Excel créée à l'aide des outils de développement Office dans Visual Studio, le format de données Anglais (ID de paramètres régionaux 1033) (États-Unis) est passé automatiquement au modèle objet Excel.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) avant de les transmettre à Microsoft Office Excel ou de lire les données à partir du code de votre projet.

Considérations sur le stockage des données

Pour garantir que vos données sont correctement interprétées et affichées, vous devez également considérer que les problèmes peuvent se produire lorsqu'une application stocke des données, telles que les formules de feuille de calcul Excel, dans les littéraux de chaîne (codés en dur) plutôt que dans les objets fortement typés.Vous devez utiliser des données mises en forme dans un style Anglais (États-Unis) (valeur LCID 1033) ou indépendant de la culture.

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é.Les solutions Excel créées à l'aide des outils de développement Office dans Visual Studio utilisent la valeur 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 pour Applications (VBA) fonctionne également de cette façon ; les chaînes sont mises en forme en en-US et VBA passe presque toujours 0 (linguistiquement neutre) en tant que valeur 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 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 lorsque la date est mise en forme dans le style en-US.

Par exemple :

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

this.Range["A1"].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"].Value2);
        System.DateTime dt = System.DateTime.FromOADate(dbl);
        this.Range["A7"].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.

Voir aussi

Partager via