Globalisation et localisation de solutions Office

Article
08/10/2011

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.

S'applique à : Les informations contenues dans cette rubrique s'appliquent aux projets de niveau document et de niveau application pour Microsoft Office 2010 et la version 2007 de Microsoft® Office System. Pour plus d'informations, consultez Fonctionnalités disponibles par type d'application et de projet Office.

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 du document partage généralement le thread d'interface utilisateur principal de Word ou Excel ; toute modification apportée à la culture du thread affecte donc tout ce qui s'exécute sur ce thread ; la modification ne se limite pas à 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 linguistiques Windows autres que l'anglais, ils doivent disposer du module linguistique approprié pour voir les messages d'exécution dans la même langue que Windows. Les modules linguistiques de Visual Studio Tools pour Office Runtime sont disponibles au téléchargement sur 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. Pour plus d'informations, consultez Mise en forme de données dans Excel avec différents paramètres régionaux.

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 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", 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.

Voir aussi

Partager via