Considérations supplémentaires

Considérations relatives au transfert de fichiers

Lors du déplacement du fichier d'exportation d'un système à un autre, utilisez l'option de transfert de l'outil qui vous sert à déplacer le fichier pour que les caractères de fin de ligne ne soient pas convertis d'un style Linus à un style Windows ou inversement.

Il est recommandé d'éviter d'utiliser "txt" comme extension du fichier d'exportation (défini dans la configuration principale). En effet, cette extension de fichier par implique par défaut qu'il s'agit d'un fichier non binaire et les outils qui effectuent le transfert du fichier risquent donc de le considérer comme un fichier non binaire, sauf si cela est indiqué explicitement. En l'occurrence, il est recommandé d'utiliser l'extension "cma". Cette extension de fichier n'est pas reconnue et la plupart des outils de transfert traiteront le fichier tel quel.

Notez que si le fichier est converti, deux résultats sont possibles : une erreur de conversion numérique ou une erreur de débit insuffisant de jeton peut être reçue lors de la tentative d'importation du fichier.

Considérations relatives aux environnements multilingues

Si votre implémentation utilise une langue autre que l'anglais, cela signifie que les objets d'administration migrés peuvent comporter des lignes en plusieurs langues (l'anglais étant toujours activé). Certains points importants sont à prendre en compte en ce qui concerne les langues multiples et l'assistant de migration de contenu.

• Comme indiqué dans Langue de l'utilisateur, certaines étapes doivent être exécutées pour la prise en charge d'une langue supplémentaire. Les étapes décrites dans cette rubrique indiquent que, pour les données système, la traduction des chaînes peut être fournie via un pack de langue faisant partie du produit ou peut relever de la responsabilité de l'implémentation. Dans un cas comme dans l'autre, l'effort est non négligeable et doit suivre un plan établi. On considère que la traduction des données système est appliquée pour chaque région sur le site d'implémentation. L'assistant de configuration de contenu (CMA) ne doit pas être utilisé pour créer une nouvelle langue dans une région cible.

• Pour les données administratives/de contrôle que votre implémentation développe dans le cadre de votre projet, on considère que les descriptions pour la langue prise en charge sont saisies dans la région considérée comme la région source utilisée pour propager les modifications aux régions de la "chaîne". Par exemple, les données de contrôle sont saisies dans une région de développement et propagées à une région de test, la langue prise en charge étant activée dans les deux régions.

• Que se passe-t-il si vous exportez des données d'une région où plus de langues sont activées que dans la cible ? Ce scénario peut se présenter si la région source est une sorte de région test où une langue supplémentaire est activée pour d'autres raisons. Dans ce cas, si le code de la langue n'existe pas du tout dans la région cible, l'importation génère une erreur étant donné que le code n'est pas valide. Si le code de la langue existe mais n'est pas activé, des lignes supplémentaires sont insérées pour la langue dans la région cible et cela ne cause pas de problèmes. Elles sont simplement ignorées.

• Que se passe-t-il si vous exportez des données d'une région où moins de langues sont activées que dans la cible ? Dans ce cas, l'importation ne crée de lignes que pour les langues copiées depuis la source. Elle ne crée pas automatiquement de lignes pour les langues supplémentaires dans la cible. Dans ce cas, il est recommandé d'exécuter le programme batch Nouvelle langue (F1–LANG) qui crée les entrées de langue manquantes.