Consideraciones adicionales
En las secciones siguientes se describen algunas consideraciones adicionales para CMA.
Consideraciones de transferencias de ficheros
Al mover el fichero de exportación entre sistemas, use la opción de transferencia binaria de cualquier herramienta que utilice para mover el fichero, de manera que los caracteres de final de línea no se convierten de estilo Linux a Windows o viceversa.
Se recomienda evitar el uso de 'txt' como extensión del fichero de exportación (definido en la configuración maestra). Esa extensión de fichero por defecto implica un fichero no binario y las herramientas que realizan la transferencia de los ficheros pueden tratarlo como un fichero no binario, a menos que se indique explícitamente. La recomendación es definir 'cma' como extensión. Esta no es una extensión de fichero reconocida y la mayoría de las herramientas de transferencia de ficheros transferirán el fichero tal cual.
Tenga a cuenta que si se convierte el fichero, hay dos resultados posibles: un error de conversión numérica o se puede recibir un error de bajo rendimiento del búfer al intentar importar el fichero.
Consideraciones del entorno multilingüe
Si en su implantación se usa un idioma diferente al inglés, significa que los objetos de administración migrados pueden tener varias filas de idiomas, porque el inglés está siempre activado. Hay algunos puntos importantes con respecto a los diferentes idiomas y CMA:
-
Según se describe en Idioma de usuario deben seguirse diferentes pasos para soportar un idioma adicional. Los pasos descritos en ese tema indican que, para los datos del sistema, se puede proporcionar la traducción de las cadenas a través del paquete de idioma suministrado o bien puede ser responsabilidad de su implantación. En cualquier caso, este esfuerzo es significativo y tendrá su propio plan establecido. Se espera que la traducción de los datos del sistema se aplique a cada región, en su sitio de implantación. El CMA no debería utilizarse para crear un idioma nuevo en la región de destino.
-
Para los datos administrativos/de control que se desarrollan en la implantación como parte del proyecto, se espera que se introduzcan las descripciones para el idioma soportado en la región que se considera de origen, con el fin de promover los cambios en las regiones de la "cadena". Por ejemplo, los datos de control se introducen en una región de desarrollo y se someten a prueba con el idioma soportado activado en ambas regiones.
-
¿Qué sucede si se exportan los datos de una región con más idiomas activados que en su destino? Este escenario es quizás un caso en el que la región de origen es un tipo de prueba o una región corralito en la que el idioma adicional está activado para otros propósitos. En este caso, si el código de idioma no existe en la región de destino, la importación generará un error teniendo en cuenta que el código no es válido. Si el código de idioma existe pero no está activado, esto hará que se inserten filas de idioma adicionales en la región de destino, pero esto no provocará más problemas. Simplemente se ignoran.
-
¿Qué sucede si se exportan los datos de una región con menos idiomas activados que en su destino? En esta situación, el proceso de importación creará solo filas de idiomas para los idiomas que se copiaron desde el origen. No se crearán de modo automático filas de idiomas en el destino como parte de la importación. Para esta situación, la recomendación es ejecutar el programa por lotes Nuevo idioma (F1–LANG) que crea cualquier entrada de idioma que falte.