Partilhar via

Globalização e localização de soluções Excel

  • Artigo

Esta seção contém informações sobre considerações especiais para soluções do Microsoft Office Excel que serão executadas em computadores com configurações diferentes do inglês para Windows. A maioria dos aspectos de globalização e localização de soluções do Microsoft Office são os mesmos que você encontra quando você cria outros tipos de soluções usando o Visual Studio. Para obter informações gerais, consulte Globalizar e localizar aplicativos.

Por padrão, os controles de host no Microsoft Office Excel funcionam corretamente em qualquer configuração regional do Windows, desde que todos os dados passados ou manipulados usando código gerenciado sejam formatados usando formatação em inglês (Estados Unidos). Em projetos destinados ao .NET Framework 4 ou ao .NET Framework 4.5, esse comportamento é controlado pelo CLR (Common Language Runtime).

Aplica-se a: As informações neste tópico se aplicam a projetos de nível de documento e projetos de suplemento VSTO para Excel. Para obter mais informações, consulte Recursos disponíveis por aplicativo e tipo de projeto do Office.

Formatar dados no Excel com várias configurações regionais

Você deve formatar todos os dados que têm formatação sensível à localidade, como datas e moeda, usando o formato de dados inglês (Estados Unidos) (ID de localidade 1033) antes de passá-los para o Microsoft Office Excel ou ler os dados do código em seu projeto do Office.

Por padrão, quando você desenvolve uma solução do Office no Visual Studio, o modelo de objeto do Excel espera formatação de dados de ID de localidade 1033 (isso também é chamado de bloqueio do modelo de objeto para ID de localidade 1033). Esse comportamento corresponde à maneira como o Visual Basic for Applications funciona. No entanto, você pode modificar esse comportamento em suas soluções do Office.

Entenda como o modelo de objeto do Excel sempre espera a ID de localidade 1033

Por padrão, as soluções do Office que você cria usando o Visual Studio não são afetadas pelas configurações de localidade do usuário final e sempre se comportam como se a localidade fosse inglês (Estados Unidos). Por exemplo, se você obtiver ou definir a Value2 propriedade no Excel, os dados deverão ser formatados da maneira esperada pela ID de localidade 1033. Se você usar um formato de dados diferente, poderá obter resultados inesperados.

Mesmo que você use o formato inglês (Estados Unidos) para dados que são passados ou manipulados por código gerenciado, o Excel interpreta e exibe os dados corretamente de acordo com a configuração de localidade do usuário final. O Excel pode formatar os dados corretamente porque o código gerenciado passa a ID de localidade 1033 junto com os dados, o que indica que os dados estão no formato inglês (Estados Unidos) e, portanto, devem ser reformatados para corresponder à configuração de localidade do usuário.

Por exemplo, se os usuários finais tiverem suas opções regionais definidas para a localidade alemão (Alemanha), eles esperam que a data 29 de junho de 2005 seja formatada desta maneira: 29.06.2005. No entanto, se sua solução passar a data para o Excel como uma cadeia de caracteres, você deverá formatá-la de acordo com o formato em inglês (Estados Unidos): 29/06/2005. Se a célula estiver formatada como uma célula Data, o Excel exibirá a data no formato alemão (Alemanha).

Passar outras IDs de localidade para o modelo de objeto do Excel

O CLR (Common Language Runtime) passa automaticamente a ID de localidade 1033 para todos os métodos e propriedades no modelo de objeto do Excel que aceitam dados sensíveis à localidade. Não há nenhuma maneira de alterar esse comportamento automaticamente para todas as chamadas no modelo de objeto. No entanto, você pode passar uma ID de localidade diferente para um método específico usando InvokeMember para chamar o método e passando a ID de localidade para o parâmetro de cultura do método.

Localizar texto do documento

O documento, modelo ou pasta de trabalho em seu projeto provavelmente inclui texto estático, que deve ser localizado separadamente do assembly e de outros recursos gerenciados. Uma maneira simples de fazer isso é fazer uma cópia do documento e traduzir o texto usando o Microsoft Office Word ou o Microsoft Office Excel. Esse processo funciona mesmo se você não fizer alterações no código, porque qualquer número de documentos pode ser vinculado ao mesmo assembly.

Você ainda deve certificar-se de que qualquer parte do seu código que interage com o texto do documento continua a corresponder ao idioma do texto e que os marcadores, intervalos nomeados e outros campos de exibição acomodam qualquer reformatação do documento do Office que foi necessária para ajustar para gramática e comprimento de texto diferentes. Para modelos de documento que contêm relativamente pouco texto, convém considerar armazenar o texto em arquivos de recurso e, em seguida, carregar o texto em tempo de execução.

Direção do texto

No Excel, você pode definir uma propriedade da planilha para renderizar o texto da direita para a esquerda. Os controles de host, ou qualquer controle que tenha uma RightToLeft propriedade, que é colocado no designer correspondem automaticamente a essas configurações em tempo de execução. O Word não tem uma configuração de documento para texto bidirecional (basta alterar o alinhamento do texto), portanto, os controles não podem ser mapeados para essa configuração. Em vez disso, você deve definir o alinhamento de texto para cada controle. É possível escrever código para percorrer todos os controles e forçá-los a renderizar texto da direita para a esquerda.

Mudar a cultura

Seu código de personalização em nível de documento normalmente compartilha o thread principal da interface do usuário do Excel, portanto, qualquer alteração feita na cultura de thread afeta todo o resto que está sendo executado nesse thread; A alteração não se restringe à sua personalização.

Os controles do Windows Forms são inicializados antes que os suplementos VSTO no nível do aplicativo sejam iniciados pelo aplicativo host. Nessas situações, a cultura deve ser alterada antes de definir os controles da interface do usuário.

Instalar os pacotes de idiomas

Se você tiver configurações diferentes do inglês para o Windows, poderá instalar os Pacotes de Idiomas do Visual Studio Tools for Office runtime para ver as mensagens de tempo de execução do Visual Studio Tools for Office no mesmo idioma do Windows. Se algum usuário final executar suas soluções com configurações diferentes do inglês para o Windows, ele deverá ter o pacote de idiomas correto para ver mensagens de tempo de execução no mesmo idioma do Windows. Os pacotes de idiomas de tempo de execução do Visual Studio Tools for Office estão disponíveis no centro de download da Microsoft.

Além disso, os pacotes de idiomas redistribuíveis do .NET Framework são necessários para mensagens ClickOnce. Os pacotes de idiomas do .NET Framework estão disponíveis no centro de download da Microsoft.

Configurações regionais e chamadas COM do Excel

Sempre que um cliente gerenciado chama um método em um objeto COM e precisa passar informações específicas da cultura, ele faz isso usando a CurrentCulture (localidade) que corresponde à localidade do thread atual. A localidade do thread atual é herdada das configurações regionais do usuário por padrão. No entanto, quando você faz uma chamada para o modelo de objeto do Excel de uma solução do Excel criada usando as ferramentas de desenvolvimento do Office no Visual Studio, o formato de dados em inglês (Estados Unidos) (ID de localidade 1033) é passado para o modelo de objeto do Excel automaticamente. Você deve formatar todos os dados que têm formatação sensível à localidade, como datas e moeda, usando o formato de dados inglês (Estados Unidos) antes de passá-los para o Microsoft Office Excel ou ler os dados do código do projeto.

Considerações para armazenar dados

Para garantir que seus dados sejam corretamente interpretados e exibidos, você também deve considerar que problemas podem ocorrer quando um aplicativo está armazenando dados, como fórmulas de planilha do Excel, em literais de cadeia de caracteres (embutidos em código) em vez de em objetos fortemente tipados. Você deve usar dados formatados assumindo um estilo invariante de cultura ou inglês (Estados Unidos) (o valor LCID 1033).

Aplicativos que usam literais de cadeia de caracteres

Os valores possíveis que podem ser codificados incluem literais de data escritos no formato inglês (Estados Unidos) e fórmulas de planilha do Excel que contêm nomes de função localizados. Outra possibilidade pode ser uma cadeia de caracteres codificada que contém um número como "1.000"; Em algumas culturas, isso é interpretado como mil, mas em outras culturas, representa um ponto zero. Cálculos e comparações realizados no formato errado podem resultar em dados incorretos.

O Excel interpreta todas as cadeias de caracteres de acordo com o LCID que é passado com a cadeia de caracteres. Isso pode ser um problema se o formato da cadeia de caracteres não corresponder ao LCID que é passado. As soluções do Excel criadas usando as ferramentas de desenvolvimento do Office no Visual Studio usam o LCID 1033 (en-US) ao passar todos os dados. O Excel exibe os dados de acordo com as configurações regionais e o idioma da interface do usuário do Excel. Visual Basic for Applications (VBA) também funciona dessa maneira; strings são formatadas como en-US e VBA quase sempre passa 0 (idioma neutro) como o LCID. Por exemplo, o código VBA a seguir exibe um valor formatado corretamente para 12 de maio de 2004, de acordo com a configuração de localidade do usuário atual:

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

O mesmo código, quando usado em uma solução criada usando as ferramentas de desenvolvimento do Office no Visual Studio e passado para o Excel por meio de interoperabilidade COM, produz os mesmos resultados quando a data é formatada no estilo en-US.

Por exemplo:

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

Você deve trabalhar com dados fortemente tipados em vez de literais de cadeia de caracteres sempre que possível. Por exemplo, em vez de armazenar uma data em um literal de cadeia de caracteres, armazene-a como um , em seguida, converta-a em um DoubleDateTime objeto para manipulação.

O exemplo de código a seguir usa uma data que um usuário insere na célula A5, armazena-a como um , em seguida, converte-a em um DoubleDateTime objeto para exibição na célula A7. A célula A7 deve ser formatada para exibir uma data.

private void ConvertDate_Click(object sender, EventArgs e)
{
    try
    {
        double dbl = (double)(this.Range["A5"].Value2);
        System.DateTime dt = System.DateTime.FromOADate(dbl);
        this.Range["A7"].Value2 = dt;
    }
    catch (Exception ex)
    {
        MessageBox.Show(ex.Message);
    }
}

Funções de planilha do Excel

Os nomes de função da planilha são traduzidos internamente para a maioria das versões de idioma do Excel. No entanto, devido a possíveis problemas de interoperabilidade de idioma e COM, é recomendável que você use apenas nomes de função em inglês em seu código.

Aplicativos que usam dados externos

Qualquer código que abra ou use dados externos, como arquivos que incluem valores separados por vírgulas (arquivos CSV) exportados de um sistema herdado, também pode ser afetado se esses arquivos forem exportados usando qualquer formato além do en-US. O acesso ao banco de dados pode não ser afetado porque todos os valores devem estar no formato binário, a menos que o banco de dados armazene datas como cadeias de caracteres ou execute operações que não usam o formato binário. Além disso, se você construir consultas SQL usando dados do Excel, talvez seja necessário garantir que elas estejam no formato en-US, dependendo da função usada.

Conteúdo relacionado