Soporte de la globalización

Tiendas de inicio

Las tiendas de inicio proporcionan una base para crear la tienda. Todas las tiendas de inicio le muestran cómo puede crear y mantener un sitio globalizado.

Las tiendas de inicio permiten a los clientes seleccionar el idioma en el que desean ver el sitio. La lista se visualiza en una lista en el marco de la izquierda de todo el sitio. Los clientes pueden navegar por el sitio y visualizarlo en el idioma que seleccionen.

Las tiendas de inicio utilizan una sola plantilla para el modelo de programación de todas las tiendas e idiomas. Cada uno de los idiomas soportados tiene su propio archivo de propiedades, que contiene el texto traducido y los mensajes para dicho idioma. Todos los archivadores de tiendas contienen: publishNLS.properties y publishNLS_en_US.properties. Se utilizan simplemente en el asistente de publicación.

En el archivo de propiedades, se han traducido varios elementos de la página:

Texto

Contenido textual de la página.

Etiquetas

Etiquetas de campos del formulario.

Mensajes

Mensajes de error, estado y confirmación.

Texto alternativo

Para imágenes, Java applets y otros objetos intercalados.

Paquetes de recursos

En el contexto de mandatos, se utiliza el entorno local para recuperar el objeto java de propiedades storetext, que obtiene sus valores del archivo storetext_locale en el directorio específico del entorno local adecuado. A continuación, la plantilla tiene acceso a cada una de las propiedades necesarias, utilizando el método getString() del objeto ResourceBundle.

Determinación del juego de caracteres

El juego de caracteres en el que se visualiza el texto en un navegador se define en el archivo de propiedades utilizando la propiedad ENCODESTATEMENT. Por ejemplo, el archivo storetext_en_US.properties contiene la declaración:

ENCODESTATEMENT = text/html; charset=ISO_8859-1

Dado que la codificación se especifica en el archivo de propiedades en lugar de en la plantilla JSP, el juego de caracteres puede ser diferente para cada idioma. La codificación de caracteres predeterminada para WebSphere Application Server se encuentra en:

• WAS_installdir\bin\wsinstance\propdefaults\encoding.properties

La codificación de caracteres de la página JSP generada se establece utilizando la sentencia siguiente en la plantilla JSP:

<%response.setContentType(storetext.getString("ENCODESTATEMENT"));%>

Para JTSL:

<c:set property="contentType"
target="${pageContext.response}">
<fmt:message key="ENCODESTATEMENT" bundle="${storeText}" />
</c:set>

Nota: Se llama a setLocal utilizando:

(<fmt:setLocale value="${CommandContext.locale}" />)

la codificación de caracteres predeterminada se selecciona en WebSphere Application Server. JSTL toma el último conjunto de codificación de caracteres como la codificación devuelta que se enviará al navegador web. En la mayoría de los casos, las personas no tendrán ningún problema con esto. Solo tienen problemas al tratar con idiomas bidi en los que pueden tener varias codificaciones de caracteres ISO por entorno local.

Durante la ejecución, cada archivo JSP (JavaServer Page) incluye el archivo EnvironmentSetup.jsp o EnvironmentSetup.jspf. El contexto de mandato se recupera de este archivo.

Visualización de las imágenes traducidas

El entorno local y el idioma se recuperan durante la ejecución para determinar la carpeta correcta en la que se ha de buscar el archivo de imágenes. Es posible que la plantilla busque el archivo ConsumerDirect\ language_Locale\images\go_button.gif, en el que language_Locale se sustituye por el formato de visualización del contexto de mandatos. Por ejemplo, la página de resultados mostrará la imagen: ConsumerDirect\en_US\images\colors\color1\go_button.gif.

Visualización del contenido del catálogo

El catálogo contiene varias traducciones, una para cada entorno local soportado. Durante la ejecución, se envía el contexto de mandatos mediante un bean de datos para determinar la traducción se ha de recuperar de la base de datos y visualizar la página.

Paquetes de recursos y archivos de propiedades

Los paquetes de recursos y los archivos de propiedades le permiten mantener colecciones de objetos Java que son específicos del entorno local para las JSP (JavaServer Pages). Cuando la página necesita un recurso específico del entorno local, por ejemplo, una etiqueta de campo de formulario, un mensaje de la interfaz gráfica de usuario o un valor de un menú desplegable, la página puede cargarlo desde el archivo de propiedades o paquete de recursos apropiado para el entorno local seleccionado, lo que permite al cliente ver la página en su propio idioma. De este modo, puede crear plantillas JSP que sean totalmente independientes del entorno local del cliente, aislando toda la información específica de entorno local en los paquetes de recursos o los archivos de propiedades.

Aunque los archivos de propiedades y los paquetes de recursos efectúan funciones similares, hay algunas diferencias en cuanto al modo en que se procesan. La tabla siguiente muestra algunas de las diferencias importantes entre los paquetes de recursos y los archivos de propiedades:

Archivos de propiedades	Paquetes ListResource
Archivos de texto	Formato compilado
Ligera disminución del rendimiento	Ligero aumento del rendimiento
Si se modifica un archivo de propiedades, WebSphere Application Server debe reiniciarse para poder ver los cambios.	Si se modifica un paquete de recursos, deberá volver a compilarlo y reiniciar WebSphere Application Server para ver los cambios.
Dependiente del idioma y del entorno local. Debe existir un archivo para cada entorno local. Necesita ejecutar native2ascii en los caracteres que no pertenecen al estándar ISO-8859-1.	Dependiente del idioma y del entorno local. Debe existir un archivo para cada entorno local. Necesita ejecutar native2ascii en los caracteres que no pertenecen al estándar ISO-8859-1.

Para obtener un ejemplo de cómo se pueden utilizar los archivos de propiedades en un sitio globalizado para muchos países, consulte las tiendas de inicio.

Almacenamiento y transferencia de datos

Una sola tienda puede mostrar páginas en varios idiomas, incluso cuando utilizan diferentes juegos de caracteres. Para conseguirlo, los datos se almacenan en la base de datos de HCL Commerce con un formato universal que se puede aplicar a un amplio número de idiomas. Dado que no todos los navegadores web soportan los mismos juegos de caracteres, cuando una JavaServer Page solicita los datos, éstos se convierten al juego de caracteres adecuado.

A continuación, se describe cómo se trasladan los datos desde la base de datos al navegador:

1. Los datos de texto se almacenan en la base de datos de HCL Commerce utilizando la codificación Unicode UTF-8 o UCS-2.
2. Los controladores JDBC cargan los datos desde la base de datos y los convierte de la codificación UTF-8 a la codificación Unicode de 16 bits nativa de Java.
3. Los archivos JSP proporcionan la salida de los datos utilizando la codificación Java de 16 bits.
4. WebSphere Application Server convierte la salida del archivo JSP de la codificación Unicode de 16 bits a la codificación de destino. La codificación se puede especificar en el archivo JSP o en un archivo de propiedades. Por ejemplo, para especificar la codificación Shift-JIS para una página en japonés, debe hacer lo siguiente:
   • Archivo JSP <%@ page contentType="text/html; charset=Shift-JIS"%>.
   • Archivo de propiedades ENCODESTATEMENT = text/html; charset=Shift-JIS La codificación de caracteres del archivo JSP generado se establece utilizando la sentencia siguiente en la plantilla JSP: <%response.setContentType(fashionflowtext.getString ("ENCODESTATEMENT")); %>
   • JSTL: <c:set property="contentType" target="${pageContext.response}"> <fmt:message key="ENCODESTATEMENT" bundle="${storeText}" /> </c:set>

   Dado que no todos los navegadores pueden comprender cada esquema de codificación, le recomendamos que especifique los esquemas de codificación más conocidos como, por ejemplo, UTF-8 y Shift-JIS.

5. Los datos convertidos se devuelven al navegador.
6. El navegador interpreta la respuesta HTTP basándose en la codificación especificada en la cabecera.

   

A continuación, se describe cómo se trasladan los datos desde el navegador a la base de datos:

1. Los datos se introducen en el navegador. Se pueden entrar datos en varias lenguas utilizando un método de entrada.
2. HCL Commerce convierte los datos procedentes del navegador a la codificación Java de 16 bits utilizando el método setCharacterEncoding(). Cada LANGUAGE_ID de la tabla LANGUAGE se correlaciona con un valor de codificación utilizando la columna ENCODING. Este valor se utiliza para interpretar los datos procedentes del navegador.
3. Los datos se envían a la base de datos donde se convierten de la codificación Java de 16 bits a la codificación UTF-8 que es la forma en que se almacenan en la base de datos, como se muestra en el diagrama siguiente:

   

Entrada de datos en varios idiomas

Si el navegador da soporte a Unicode, puede visualizar varios idiomas a la vez en un navegador. No obstante, es posible que el sistema operativo no tenga los caracteres que necesita para escribir el texto en algunos idiomas. Para hacerlo, es posible que necesite un editor de método de entrada. Un editor de método de entrada es un componente de software que convierte la entrada mediante pulsaciones de tecla en entrada de texto que no se puede escribir directamente. Los métodos de entrada se utilizan normalmente para el texto de entrada de idiomas que tienen más caracteres de los que caben en un teclado estándar como, por ejemplo, japonés, chino y coreano, tailandés e hindi. Una herramienta de editor de método de entrada común es Global IME (Input Method Editor) de Microsoft que está disponible en el sitio web de Microsoft: Global IME es adecuado tanto para que los clientes entren datos en las páginas de compra como para que los administradores entren datos en HCL Commerce Accelerator y en la Consola de administración.

Si opta por no utilizar un editor de método de entrada, también puede entrar datos en los diferentes idiomas proporcionados siempre que tenga una configuración de varias máquinas, cada una de las cuales utilice un idioma diferente en el sistema operativo con un navegador configurado correctamente. Un navegador dará soporte automáticamente al idioma nativo de la máquina en la que está instalado. Por ejemplo, para escribir datos en japonés y datos en alemán, puede configurar dos máquinas, una de las cuales utilice un sistema operativo alemán y el otro un sistema operativo japonés, cada uno con un navegador que pueda visualizar datos desde dicho sistema operativo. Para obtener más información sobre este tema, consulte la documentación del sistema operativo o navegador web.

Unicode

Los datos de texto de HCL Commerce se codifican utilizando el juego de caracteres Unicode. Unicode puede visualizar los caracteres utilizados en los idiomas importantes, incluidos los idiomas europeos, de Oriente Medio y Asia. En HCL Commerce, se utiliza el estándar Unicode UTF-8 para almacenar los datos en varios idiomas en la misma instancia de base de datos. Aunque los clientes no necesitan tener un navegador habilitado para Unicode para ver sitios dirigidos por HCL Commerce, es posible que los administradores necesiten uno si desean ver el sitio en más de un idioma en la misma máquina. Si desea ver el sitio en un idioma distinto al idioma inglés, necesita un navegador habilitado para Unicode. Para obtener más información sobre Unicode, visite el sitio web de Unicode.

Formatos de visualización

Los formatos de visualización permiten que una sola tienda venda a una base de clientes globalizada, de varios idiomas. Cada formato de visualización se puede identificar mediante tres factores: un idioma, una región y una variante que puede definir. Puede diseñar su sitio para que visualice diferente contenido en grupos que difieren según cualquiera de estos factores. Por ejemplo, puede utilizar el idioma y el entorno local para que tengan un formato diferente para inglés de EE.UU. y para inglés de Canadá. Estos formatos de visualización pueden tener el mismo texto pero diferentes monedas y unidades de medida. Puede añadir un formato de visualización para francés de Canadá. Este formato de visualización puede mostrar la misma moneda y unidades de medida que el inglés de Canadá pero el texto estará en francés de Canadá. Incluso puede utilizar el tercer factor para tener un formato diferente para los tipos diferentes de clientes dentro de una cultura como, por ejemplo, adolescentes, la comunidad científica o los profesionales técnicos, adaptando el sitio a sus expectativas.

Los clientes pueden seleccionar el formato en el que desea ver el sitio o puede establecer un valor predeterminado para ellos. La información relacionada con el formato se pasa mediante un parámetro de URL cuando desea cambiar el idioma. Por ejemplo, si pasa langId=-2, la sesión establecerá el idioma actual en francés. El valor de langId se almacena en la sesión. Cuando el cliente solicita una página, el formato de visualización determina los elementos web y la información de catálogo que se ha de recuperar.