Consideraciones Adicionales

Consideraciones sobre la Transferencia de Archivos

Al mover el archivo de exportación entre sistemas, utilice la opción de transferencia binaria de cualquier herramienta que use para mover el archivo, de modo que los caracteres de fin de línea no se conviertan del estilo de Linux al de Windows o viceversa.

Se recomienda evitar el uso de "txt" para la extensión del archivo de exportación (definida en la configuración principal). Esa extensión de archivo por defecto implica que un archivo no binario y las herramientas que realizan la transferencia de archivos pueden tratar a este archivo como un archivo no binario, a menos que esté establecido explícitamente. La recomendación es definir "cma" como la extensión. Esta no es una extensión de archivo reconocida, y la mayoría de las herramientas de transferencia de archivos transferirán el archivo tal como está.

Tenga en cuenta que si el archivo se convierte, hay dos resultados posibles: es posible recibir un error de conversión numérica o un error por agotamiento del buffer al intentar importar el archivo.

Consideraciones de Entorno Multilingüe

Si la implementación usa un idioma distinto del inglés, los objetos de administración migrados pueden tener múltiples filas de idioma (porque el inglés siempre está activado). A continuación, se mencionan algunos puntos importantes relativos a la multiplicidad de idiomas y el CMA:

• Como se describe en Idioma del Usuario, se deben seguir ciertos pasos para que se soporte un idioma adicional. En los pasos que se describen en el tema recién mencionado, se realza que, para los datos del sistema, es posible proporcionar la traducción de las cadenas mediante un paquete de idioma proporcionado por el producto o puede ser una responsabilidad de la implementación. En ambos casos, este no es un esfuerzo trivial, por lo que debe establecerse el plan correspondiente. Se espera que la traducción de los datos del sistema se aplique para cada región en el sitio de la implementación. No se debe usar el CMA para crear un nuevo idioma en una región de destino.

• En el caso de los datos administrativos/de control que la implementación desarrolla para el proyecto, se espera que las descripciones para el idioma soportado se ingresen en la región que es considerada como la región de origen usada para promover los cambios a las regiones en la "cadena". Por ejemplo, los datos de control se ingresan en una región de desarrollo y se promueven a una de prueba con el idioma soportado activado en ambas regiones.

• ¿Qué sucede si se exportan datos de una región con más idiomas activados que el destino? Quizá este escenario corresponde a un caso en el que la región de origen es un tipo de prueba o región de ensayo en la que el idioma adicional se activa con otras finalidades. En este caso, si el código de idioma no existe en la región de destino, la importación producirá un error dado que el código es inválido. Si el código de idioma existe, pero no está activado, las filas de idioma adicionales se insertan en la región de destino, pero no se produce ningún problema. Simplemente se ignoran.

• ¿Qué sucede si se exportan datos de una región con menos idiomas activados que el destino? En esta situación, el proceso de importación solo crea filas de idioma para los idiomas copiados desde el origen. No se crean filas de idioma automáticamente en el destino durante la importación. Para esta situación, se recomienda ejecutar el programa de lote Nuevo Idioma (F1–LANG) que crea todos los registros de idioma faltantes.