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

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.

Se aplica a: la información de este tema se aplica a los proyectos de nivel de documento y los proyectos de nivel de aplicación para Microsoft Office 2010 y 2007 Microsoft Office System. Para obtener más información, vea Características disponibles por aplicación y tipo de proyecto de Office.

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, el código de personalización de nivel de documento comparte el subproceso de la interfaz de usuario 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 Windows Forms se inicializan antes de que la aplicación host inicie los complementos de nivel de aplicación. En estas situaciones, la referencia cultural se debe cambiar antes de establecer los controles de la interfaz de usuario.

Instalar paquetes de idioma

Si usa una configuración para Windows que no corresponde al inglés, puede instalar los paquetes de idioma de Motor en tiempo de ejecución de Microsoft Visual Studio Tools para Office para ver los mensajes en tiempo de ejecución de Motor en tiempo de ejecución de Microsoft 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 Motor en tiempo de ejecución de Microsoft 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, al realizar una llamada en el modelo de objetos de Excel desde una solución de Excel creada con las herramientas de desarrollo de Office en Visual Studio, el formato de datos de Inglés (Estados Unidos) (identificador de configuración regional 1033) se pasa automáticamente al modelo de objetos de Excel. Debe dar formato a todos los datos con formato sensible a la configuración regional, como fechas y divisa, con el formato de datos Inglés (Estados Unidos) antes de pasarlos a Microsoft Office Excel, o bien leer los datos del código del proyecto. Para obtener más información, vea Aplicar formato a datos de Excel con varias configuraciones regionales.

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 usar datos con un formato en el que se suponga una referencia cultural de todos los idiomas o Inglés (Estados Unidos) (valor de LCID 1033).

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. Las soluciones de Excel creadas con las herramientas de desarrollo de Office en Visual Studio usan 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) también funciona de esta manera; a las cadenas se les aplica el formato en-US y VBA pasa casi siempre 0 (independiente del idioma) 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 usa en una solución creada con las herramientas de desarrollo de Office en Visual Studio y se pasa a Excel a través de la interoperabilidad COM, genera los mismos resultados si se da formato a la fecha con el estilo de 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.

Vea también

Last updated on 2011-08-10