Globalización y localización de las soluciones de Office

Artículo
04/28/2010

Actualización: noviembre 2007

La mayoría de los aspectos relacionados con la globalización y la localización de las soluciones de Microsoft Office coinciden con los que se pueden encontrar cuando se crean otros tipos de soluciones con Visual Studio. Para obtener información general, vea Globalizar y localizar aplicaciones. También encontrará información de globalización y localización en la página web de MSDN Globalization and Localization Issues for Solutions Created with Microsoft Visual Studio Tools for the Microsoft Office System.

Localizar texto de documentos

Es probable que el documento, la plantilla o el libro del proyecto incluyan texto estático, que se debe localizar independientemente del ensamblado y de otros recursos administrados. Una forma sencilla de abordar esta cuestión consiste en realizar una copia del documento y traducir el texto con Microsoft Office Word o con Microsoft Office Excel. Este proceso funciona aunque no se efectúen cambios en el código, porque no hay límite para el número de documentos que pueden vincular al mismo ensamblado.

No obstante, conviene asegurarse de que las partes del código que interactúen con el texto del documento se ajusten al idioma del texto, y que los marcadores, los rangos con nombre y demás campos de visualización se adapten al nuevo formato del documento de Office necesario para ajustarse a las diferencias de gramática y de longitud del texto. Para plantillas de documento que contienen relativamente poco texto, podría almacenar el texto en archivos de recursos y cargarlo después en tiempo de ejecución.

Dirección del texto

En Excel, puede establecer una propiedad de hoja de cálculo para representar el texto de derecha a izquierda. Los controles de host o cualquier control con una propiedad RightToLeft que se coloquen en el diseñador responden automáticamente a esta configuración en tiempo de ejecución. Word no tiene una configuración de documento para el texto bidireccional (simplemente, se cambia la alineación del texto), por lo que los controles no se pueden asignar a esta configuración. En lugar de eso, debe establecerse la alineación del texto para cada control. Es posible escribir código para recorrer todos los controles y hacer que representen el texto de derecha a izquierda.

Cambiar la referencia cultural

Normalmente, un código de personalización comparte el subproceso de la IU principal de Word o Excel, de modo que los cambios que se realicen en la referencia cultural del subproceso afectan a todo lo demás que se esté ejecutando en dicho subproceso; el cambio no se limita a la personalización.

Los controles de formularios Windows Forms se inicializan antes de que la aplicación host inicie los complementos de Visual Studio Tools para Office. En estas situaciones, la referencia cultural se debe cambiar antes de establecer los controles de la interfaz de usuario.

Instalar paquetes de idioma

Si utiliza una configuración para Windows distinta del inglés, puede instalar los paquetes de idioma de Visual Studio Tools para Office para ver los mensajes en tiempo de ejecución de Visual Studio Tools para Office en el mismo idioma que en Windows. Si algún usuario final ejecuta sus soluciones con una configuración para Windows distinta del inglés, debe disponer del paquete de idioma correcto para ver los mensajes en tiempo de ejecución en el mismo idioma que en Windows. Los paquetes de idioma de Visual Studio Tools para Office están disponibles en el Centro de descarga de Microsoft.

Además, los paquetes de idioma redistribuibles de Microsoft .NET Framework son necesarios para los mensajes de ClickOnce. Los paquetes de idioma de .NET Framework están disponibles en el Centro de descarga de Microsoft.

Configuración regional y llamadas COM de Excel

Cuando un cliente administrado llama a un método en un objeto COM y necesita pasar información específica de la referencia cultural, lo hace mediante CurrentCulture (configuración regional) que coincide con la configuración regional del subproceso actual. La configuración regional del subproceso actual se hereda de manera predeterminada de la configuración regional del usuario. Sin embargo, cuando realiza una llamada en el modelo de objetos de Excel, Visual Studio Tools para Office pasa automáticamente un identificador de configuración regional (LCID) de referencia cultura de todos los idiomas. Debe dar formato a todos los datos con formato sensible a la configuración regional, como fechas y moneda, mediante el formato de datos Inglés (Estados Unidos) (identificador de configuración regional 1033) antes de pasarlos a Microsoft Office Excel o bien leer los datos del código de proyecto de Visual Studio Tools para Office. Para obtener más información, vea Aplicar formato a datos de Excel con varias configuraciones regionales.

El atributo ExcelLocale1033Attribute controla este comportamiento. Si desea cambiar el comportamiento para que los datos se pasen utilizando el LCID del subproceso actual, establezca ExcelLocale1033Attribute en false. A continuación, puede escribir su propio código para controlar la interacción entre Excel y el código administrado. Para obtener más información, vea Cómo: Garantizar la seguridad de los literales de cadena frente a la configuración regional en Excel mediante la reflexión.

Consideraciones para almacenar datos

Para asegurarse de que sus datos se interpretan y se presentan correctamente, también debe tener en cuenta que pueden producirse problemas cuando una aplicación esté almacenando datos, incluyendo fórmulas de hojas de cálculo de Excel, en literales de cadena (en el código) en lugar de en objetos con establecimiento inflexible de tipos. Debe utilizar datos con un formato que suponga un estilo de referencia cultural de todos los idiomas o de inglés (Estados Unidos) (el valor LCID en-US).

Aplicaciones que utilizan literales de cadena

Entre los valores que podrían estar especificados en el código se encuentran los literales de fecha escritos en formato inglés (Estados Unidos) y fórmulas de hoja de cálculo de Excel que contengan nombres de función traducidos. Otra posibilidad podría ser una cadena especificada en el código que contenga un número como "1,000"; en algunas referencias culturales, se interpreta uno coma cero, pero en otras referencias culturales representa el número mil. Los cálculos y las comparaciones realizados en un formato que no corresponda podrían dar como resultado datos incorrectos.

Excel interpreta cualquier cadena de acuerdo con el LCID que se pasa con la cadena. Esto puede suponer un problema si el formato de la cadena no corresponde al LCID que se pasa. Visual Studio Tools para Office utiliza el LCID 1033 (en-us) al pasar todos los datos. Excel muestra los datos según la configuración regional y el idioma de la interfaz de usuario de Excel. Visual Basic para Aplicaciones (VBA) funciona de esta manera; a las cadenas se les aplica el formato en-US y VBA pasa casi siempre 0 (idioma neutral) como LCID. Por ejemplo, con el siguiente código de VBA se muestra un valor con formato correcto para la fecha 12 de mayo de 2004, de acuerdo con la configuración regional del usuario actual:

'VBA
Application.ActiveCell.Value2 = "05/12/04"

El mismo código, cuando se utiliza en una solución de Visual Studio Tools para Office y se pasa a Excel a través de interoperabilidad COM, genera los mismos resultados cuando la fecha tiene el formato con estilo en_US.

Por ejemplo:

Me.Range("A1").Value2 = "05/12/04"

this.Range["A1", missing].Value2 = "05/12/04";

Siempre que sea posible, debe trabajar con datos con establecimiento inflexible de tipos, en lugar de hacerlo con literales de cadena. Por ejemplo, en lugar de almacenar una fecha en un literal de cadena, almacénelo como un Double y, a continuación, conviértalo en un objeto DateTime para la manipulación.

En el siguiente ejemplo de código, se toma una fecha que escribe un usuario en la celda A5, se almacena como un Double y, a continuación, se convierte en un objeto DateTime para que se muestre en la celda A7. Se debe dar formato a la celda A7 para que muestre una fecha.

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);
    }
}

Funciones de hoja de cálculo de Excel

Los nombres de función de las hojas de cálculo se traducen internamente para la mayoría de las versiones de lenguaje de Excel. Sin embargo, debido a los posibles problemas de idioma y de interoperabilidad COM, se recomienda encarecidamente utilizar sólo nombres de función en inglés en el código.

Aplicaciones que utilizan datos externos

También se podría ver afectado cualquier código que abra o utilice de algún modo datos externos, como archivos que incluyan valores separados por comas (archivos CSV) exportados de un sistema heredado, si tales archivos se exportan con cualquier formato distinto de en-US. No podría verse afectado el acceso a la base de datos porque todos los valores tendrían que estar en formato binario, a menos que la base de datos almacenase las fechas como cadenas o realizase operaciones en las que no se utilice el formato binario. Por otra parte, si crea consultas SQL con datos de Excel, quizá debería asegurarse de que están en formato en-US, según la función que utilice.