Compartilhar via

Práticas recomendadas para desenvolver aplicativos prontos para o mundo

Esta seção descreve as práticas recomendadas a seguir ao desenvolver aplicativos prontos para o mundo.

Práticas recomendadas de globalização

  1. Torne seu aplicativo Unicode internamente.

  2. Use as classes com reconhecimento de cultura fornecidas pelo System.Globalization namespace para manipular e formatar dados.

    • Para classificação, use a SortKey classe e a CompareInfo classe.
    • Para comparações de cadeia de caracteres, use a CompareInfo classe.
    • Para formatação de data e hora, use a DateTimeFormatInfo classe.
    • Para formatação numérica, use a NumberFormatInfo classe.
    • Para calendários gregorianos e não gregorianos, use a Calendar classe ou uma das implementações de calendário específicas.

  3. Use as configurações de propriedade de cultura fornecidas pela classe System.Globalization.CultureInfo nas situações apropriadas. Use a CultureInfo.CurrentCulture propriedade para formatar tarefas, como data e hora ou formatação numérica. Utilize a propriedade CultureInfo.CurrentUICulture para recuperação de recursos. Observe que as propriedades CurrentCulture e CurrentUICulture podem ser definidas para cada thread.

  4. Habilite seu aplicativo para ler e gravar dados de e para uma variedade de codificações usando as classes de codificação no System.Text namespace. Não suponha dados ASCII. Suponha que caracteres internacionais serão fornecidos em qualquer lugar em que um usuário possa inserir texto. Por exemplo, o aplicativo deve aceitar caracteres internacionais em nomes de servidor, diretórios, nomes de arquivo, nomes de usuário e URLs.

  5. Ao usar a UTF8Encoding classe, por motivos de segurança, use o recurso de detecção de erros oferecido por essa classe. Para ativar o recurso de detecção de erros, crie uma instância da classe usando o construtor que usa um throwOnInvalidBytes parâmetro e defina o valor desse parâmetro como true.

  6. Sempre que possível, manipule cadeias de caracteres como cadeias de caracteres inteiras em vez de como uma série de caracteres individuais. Isso é especialmente importante ao classificar ou procurar subcadeias de caracteres. Isso evitará problemas associados à análise de caracteres combinados. Você também pode trabalhar com unidades de texto em vez de caracteres únicos usando a System.Globalization.StringInfo classe.

  7. Exibir texto usando as classes fornecidas pelo System.Drawing namespace.

  8. Para consistência em sistemas operacionais, não permita que as configurações do usuário substituam CultureInfo. Use o CultureInfo construtor que aceita um useUserOverride parâmetro e defina-o como false.

  9. Teste a funcionalidade do aplicativo em versões do sistema operacional internacional usando dados internacionais.

  10. Se uma decisão de segurança for baseada no resultado de uma comparação de cadeia de caracteres ou de uma operação de alteração entre maiúsculas e minúsculas, use uma operação de cadeia de caracteres sem detecção de cultura. Essa prática garante que o resultado não seja afetado pelo valor de CultureInfo.CurrentCulture. Consulte a seção "Comparações de cadeia de caracteres que usam a cultura atual" das práticas recomendadas para usar cadeias de caracteres para obter um exemplo que demonstra como comparações de cadeias de caracteres sensíveis à cultura podem produzir resultados inconsistentes.

  11. Para qualquer elemento que esteja sendo usado para intercâmbio (por exemplo, um campo em um documento JSON em uma chamada à API) ou armazenamento, use o CultureInfo; além disso, você deve especificar explicitamente um formato de ida e volta (como o "O""o" especificador de formato de data e hora). Embora as cadeias de caracteres de formato para a cultura invariável sejam estáveis e improváveis de serem alteradas, especificar uma cadeia de caracteres de formato explícita ajuda a esclarecer a intenção do código.

  12. Os dados de globalização não são estáveis e você deve escrever seu aplicativo e seus testes com isso em mente. Eles são atualizados várias vezes por ano por meio de canais de SO host em todas as plataformas com suporte. Normalmente, esses dados não são distribuídos com o runtime.

Práticas recomendadas de localização

  1. Mova todos os recursos localizáveis para separar DLLs somente de recursos. Os recursos localizáveis incluem elementos de interface do usuário, como cadeias de caracteres, mensagens de erro, caixas de diálogo, menus e recursos de objeto inserido.

  2. Não codifique cadeias de caracteres ou recursos de interface do usuário.

  3. Não coloque recursos não localizáveis em DLLs somente de recursos. Isso confunde tradutores.

  4. Não use cadeias de caracteres compostas que são criadas em runtime a partir de frases concatenadas. Cadeias de caracteres compostas são difíceis de localizar porque geralmente assumem uma ordem gramatical em inglês que não se aplica a todos os idiomas.

  5. Evite construções ambíguas, como "Pasta Vazia", em que as cadeias de caracteres podem ser traduzidas de forma diferente, dependendo das funções gramaticais dos componentes da cadeia de caracteres. Por exemplo, "vazio" pode ser um verbo ou um adjetivo, o que pode levar a traduções diferentes em idiomas como italiano ou francês.

  6. Evite usar imagens e ícones que contêm texto em seu aplicativo. Eles são caros para localizar.

  7. Garanta espaço suficiente para que o comprimento das strings possa expandir-se na interface do usuário. Em alguns idiomas, as frases podem exigir de 50 a 75% mais espaço do que precisam em outros idiomas.

  8. Use a System.Resources.ResourceManager classe para recuperar recursos com base na cultura.

  9. Use o Visual Studio para criar caixas de diálogo do Windows Forms para que possam ser localizadas usando o Editor de Recursos do Windows Forms (Winres.exe). Não codifique caixas de diálogo do Windows Forms manualmente.

  10. Procure um profissional de localização (tradução).

  11. Para obter uma descrição completa da criação e localização de recursos, consulte Recursos em aplicativos .NET.

Práticas recomendadas de globalização para ASP.NET e outros aplicativos de servidor

Dica

As práticas recomendadas a seguir são para aplicativos ASP.NET Framework. Para aplicativos ASP.NET Core, consulte Globalização e localização no ASP.NET Core.

  1. Defina explicitamente as propriedades CurrentUICulture e CurrentCulture no seu aplicativo. Não confie em padrões.

  2. Observe que ASP.NET aplicativos são aplicativos gerenciados e, portanto, podem usar as mesmas classes que outros aplicativos gerenciados para recuperar, exibir e manipular informações com base na cultura.

  3. Lembre-se de que você pode especificar os três seguintes tipos de codificações em ASP.NET:

    • requestEncoding especifica a codificação recebida do navegador do cliente.
    • responseEncoding especifica a codificação a ser enviada para o navegador do cliente. Na maioria das situações, essa codificação deve ser a mesma especificada para requestEncoding.
    • fileEncoding especifica a codificação padrão para .aspx, .asmx e análise de arquivo .asax .

  4. Especifique os valores para os atributos requestEncoding, responseEncoding, fileEncoding, culture e uiCulture nos seguintes três locais em um aplicativo ASP.NET.

    • Na seção de globalização de um arquivo Web.config. Esse arquivo é externo ao aplicativo ASP.NET. Para obter mais informações, consulte o <globalization> elemento.
    • Em uma diretiva de página. Observe que, quando um aplicativo está em uma página, o arquivo já foi lido. Portanto, é tarde demais para especificar fileEncoding e requestEncoding. Somente uiCulture, culturee responseEncoding pode ser especificado em uma diretiva de página.
    • No código do aplicativo de forma programática. Essa configuração pode variar por solicitação. Assim como acontece com uma diretiva de página, quando o código do aplicativo é atingido, é tarde demais para especificar fileEncoding e requestEncoding. Somente uiCulture, culturee responseEncoding pode ser especificado no código do aplicativo.

  5. Observe que o valor da uiCulture pode ser definido como o idioma de aceitação do navegador.

  6. Para aplicativos distribuídos, é importante permitir que ocorram atualizações sem tempo de inatividade (por exemplo, Aplicativos de Contêiner do Azure). Ou seja, você deve planejar situações em que possa haver várias instâncias do aplicativo com regras de formatação diferentes ou outros dados de cultura, especialmente regras de fuso horário.

    • Se a implantação do aplicativo incluir um banco de dados, lembre-se de que o banco de dados terá suas próprias regras de globalização. Na maioria dos casos, você deve evitar executar quaisquer funções relacionadas à globalização no banco de dados.
    • Se a implantação do aplicativo incluir um aplicativo cliente ou front-end da Web usando recursos de globalização do cliente, suponha que os recursos do cliente diferem dos recursos disponíveis para o servidor. Considere executar exclusivamente funções de globalização no cliente.

Recomendações para testes robustos

  1. Para tornar as dependências mais explícitas e o teste potencialmente mais fácil e paralelizável, você pode considerar passar explicitamente configurações relevantes à cultura, como CultureInfo parâmetros, para métodos que executam a formatação e TimeZoneInfo para métodos que funcionam com datas e horas. Você também deve usar TimeProvider ou um tipo semelhante ao recuperar a hora.

  2. Para a maioria dos testes, você não deve validar explicitamente a saída exata de uma determinada operação de formatação ou o deslocamento exato de um fuso horário. A formatação e os dados de fuso horário podem ser alterados a qualquer momento e podem diferir entre duas instâncias idênticas de um sistema operacional (e processos potencialmente diferentes no mesmo computador). Depender de um valor exato torna os testes frágeis.

    • Em geral, a validação de que alguma saída foi recebida será suficiente (por exemplo, cadeias de caracteres não vazias ao formatar).
    • Para alguns elementos e formatos de dados, a validação de que os dados analisam o valor de entrada pode ser usada em vez disso (arredondamento). É necessário ter cuidado para os casos em que os campos são descartados (por exemplo, ano para alguns campos relacionados à data) ou o valor truncado ou arredondado (como para saída de ponto flutuante).
    • Se você tiver requisitos explícitos para validar toda a saída de formato localizado, considere criar e usar uma cultura personalizada durante a instalação do teste. Para a maioria dos casos simples, isso pode ser feito instanciando um CultureInfo objeto com seu construtor new CultureInfo(..) e definindo as propriedades DateTimeFormat e NumberFormat. Para casos mais complicados, a subclasse do tipo permite substituir propriedades adicionais. Há possíveis benefícios adicionais para isso, como habilitar a pseudolocalização com arquivos de recursos.
    • Se você tiver requisitos explícitos para validar os resultados de todas as operações de data/hora, considere criar e usar uma instância personalizada TimeZoneInfo durante a instalação do teste. Há benefícios adicionais potenciais para isso, como habilitar testes estáveis para determinados casos extremos (por exemplo, alterações nas regras de horário de verão).

Consulte também

  • Last updated on