Partilhar via

Práticas recomendadas para o desenvolvimento de aplicativos prontos para o mundo

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

Melhores práticas de globalização

  1. Configure a aplicação para usar Unicode internamente.

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

    • Para classificar, 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. Utilize as definições de cultura fornecidas pela classe System.Globalization.CultureInfo nas situações adequadas. Use a CultureInfo.CurrentCulture propriedade para tarefas de formatação, como data e hora ou formatação numérica. Utilize a propriedade CultureInfo.CurrentUICulture para recuperar recursos. Observe que as CurrentCulture propriedades e CurrentUICulture podem ser definidas por 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 assuma dados ASCII. Suponha que os caracteres internacionais serão fornecidos em qualquer lugar 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 deteção de erros oferecido por essa classe. Para ativar o recurso de deteçã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 inteiras em vez de como uma série de caracteres individuais. Isso é especialmente importante ao classificar ou pesquisar por partes de cadeias 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. Exiba o texto utilizando as classes fornecidas pelo espaço de nomes System.Drawing.

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

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

  10. Se uma decisão de segurança for baseada no resultado de uma comparação de cadeia de caracteres ou operação de alteração de maiúsculas e minúsculas, utilize uma operação de cadeia de caracteres insensível à 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" de Práticas recomendadas para usar cadeias de caracteres para obter um exemplo que demonstra como comparações de cadeia 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 de API) ou armazenamento, use o CultureInfo; além disso, você deve especificar explicitamente um formato de ida e volta (como o especificador de"O" formato de "o" data e hora). Embora as cadeias de caracteres de formato para a cultura invariante sejam estáveis e improváveis de serem alteradas, especificar uma cadeia de caracteres de formato explícito ajuda a esclarecer a intenção do seu 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. É atualizado várias vezes por ano através dos canais do SO anfitrião em todas as plataformas suportadas. Esses dados normalmente não são distribuídos com o tempo de execução.

Práticas recomendadas de localização

  1. Mova todos os recursos localizáveis para DLLs separadas que contenham apenas recursos. Os recursos localizáveis incluem elementos da interface do usuário, como cadeias de caracteres, mensagens de erro, caixas de diálogo, menus e recursos de objetos incorporados.

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

  3. Não coloque recursos não localizáveis nas DLLs de somente recursos. Isto confunde os tradutores.

  4. Não use cadeias compostas construídas em tempo de execução a partir de frases concatenadas. As 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 "Empty Folder", onde 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 diferentes traduções em línguas como o italiano ou o francês.

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

  7. Permita muito espaço para o comprimento das cadeias de caracteres se expandir na interface do usuário. Em alguns idiomas, as frases podem exigir de 50% a 75% mais espaço do que 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 Windows Forms para que elas 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. Garanta a tradução e localização profissionais.

  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

Sugestão

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

  1. Defina explicitamente as CurrentUICulture propriedades e CurrentCulture em seu aplicativo. Não confie em pré-definiçõ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 tipos de codificações a seguir no 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 análise de arquivos .aspx, .asmx e .asax .

  4. Especifique os valores para os requestEncodingatributos , responseEncoding, fileEncoding, culture, e uiCulture nos três locais a seguir em um aplicativo ASP.NET:

    • Na secção de internacionalização de um arquivo Web.config. Esse arquivo é externo ao aplicativo ASP.NET. Para mais informações, consulte o elemento<globalization>.
    • 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. Apenas uiCulture, culturee responseEncoding pode ser especificado em uma diretiva de página.
    • Programaticamente no código do aplicativo. Essa configuração pode variar de acordo com a solicitação. Tal como acontece com uma diretiva de página, no momento em que o código do aplicativo é alcançado, é tarde demais para especificar fileEncoding e requestEncoding. Somente uiCulture, culturee responseEncoding pode ser especificado no código do aplicativo.

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

  6. Para aplicações que são distribuídas, que permitem atualizações sem tempo de inatividade (como Aplicações de Contêiner do Azure) ou similares, é necessário planear para situações onde possam existir múltiplas instâncias da aplicação com regras de formato diferentes ou outros dados culturais, mais relevantemente regras de zona temporal.

    • 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 frontend da Web usando recursos de globalização do cliente, suponha que os recursos do cliente sejam diferentes dos recursos disponíveis para o servidor. Considere a realização exclusiva de funções de globalização no cliente.

Recomendações para testes robustos

  1. Para tornar as dependências mais explícitas e os testes potencialmente mais fáceis e paralelizáveis, você deve considerar a passagem explícita de configurações relevantes à cultura, como CultureInfo parâmetros, para métodos que executam 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 o tempo.

  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 mudar a qualquer momento e podem diferir entre duas instâncias idênticas de um sistema operacional (e processos potencialmente diferentes na mesma máquina). Confiar em um valor exato torna os testes frágeis.

    • Geralmente, validar que alguma saída foi recebida será suficiente (por exemplo, cadeias de caracteres não vazias durante a formatação).
    • Para alguns elementos e formatos de dados, a validação de que os dados são analisados para o valor de entrada pode ser usada em vez disso (roundtripping). É necessário ter cuidado com 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 vírgula flutuante).
    • Se você tiver requisitos explícitos para validar todas as saídas de formato localizado, considere criar e usar uma cultura personalizada durante a configuração do teste. Para a maioria dos casos simples, isso pode ser feito instanciando o objeto CultureInfo com o seu construtor new CultureInfo(..) e definindo as propriedades DateTimeFormat e NumberFormat. Para casos mais complicados, a subclassificação do tipo permite substituir propriedades adicionais. Há benefícios adicionais potenciais 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 configuração do teste. Há potenciais benefícios adicionais para isso, como permitir testes estáveis de certos casos extremos (por exemplo, alterações nas regras do horário de verão).

Ver também

  • Last updated on