Compartilhar via

Solucionar problemas de localização do ASP.NET Core

Por Hisham Bin Ateya

Este artigo fornece instruções sobre como diagnosticar problemas de localização de aplicativo do ASP.NET Core.

Problemas de configuração de localização

Ordem do middleware de localização
O aplicativo pode não ser localizado porque o middleware de localização não é ordenado conforme o esperado.

Para resolver esse problema, verifique se o middleware de localização está registrado antes do middleware MVC. Caso contrário, o middleware de localização não será aplicado.

public void ConfigureServices(IServiceCollection services)
{
    services.AddLocalization(options => options.ResourcesPath = "Resources");

    services.AddMvc();
}

Caminho de recursos de localização não encontrado

As culturas com suporte no RequestCultureProvider não correspondem às registradas anteriormente

Problemas de nomenclatura de arquivo de recurso

ASP.NET Core tem regras e diretrizes predefinidas para nomenclatura de arquivo de recursos de localização, que são descritas na Globalização e localização no ASP.NET Core.

Recursos ausentes

As causas comuns dos recursos não encontrados incluem:

  • Os nomes de recursos são escritos incorretamente no arquivo de recurso XML do .NET (.resx) ou na solicitação do localizador.
  • O recurso está ausente do arquivo de recurso para alguns idiomas, mas existe em outros.
  • Se você ainda estiver tendo problemas, verifique as mensagens de log de localização (registradas no nível do Debug log) para obter mais detalhes sobre os recursos ausentes.

Dica

Ao usar CookieRequestCultureProvider, verifique se as aspas simples não são usadas com as culturas dentro do valor de localização cookie . Por exemplo, c='en-UK'|uic='en-US' é um valor inválido cookie , embora c=en-UK|uic=en-US seja válido.

Problemas de recursos e bibliotecas de classes

ASP.NET Core por padrão fornece uma maneira de permitir que as bibliotecas de classes encontrem seus arquivos de recurso por meio de ResourceLocationAttribute.

Os problemas comuns com bibliotecas de classes incluem:

CustomRequestCultureProvider não funciona conforme o esperado

A RequestLocalizationOptions classe tem três provedores padrão:

O CustomRequestCultureProvider permite personalizar como a cultura de localização é fornecida. O CustomRequestCultureProvider é usado quando os provedores padrão não atendem aos seus requisitos.

Um motivo comum para um provedor personalizado não funcionar corretamente é que ele não é o primeiro provedor na RequestCultureProviders lista. Para resolver o problema:

  • Insira o provedor personalizado na posição zero na RequestCultureProviders lista:

    options.AddInitialRequestCultureProvider(
    new CustomRequestCultureProvider(async context =>
    {
        // My custom request culture logic
        return new ProviderCultureResult("en");
    }));

  • Insira o provedor personalizado na posição zero na RequestCultureProviders lista:

    options.RequestCultureProviders.Insert(0, 
    new CustomRequestCultureProvider(async context =>
    {
        // My custom request culture logic
        return new ProviderCultureResult("en");
    }));

Problemas de namespace raiz

Quando o namespace raiz de um assembly é diferente do nome do assembly, a localização não funciona por padrão. Para evitar esse problema, use o RootNamespace atributo, que é descrito em Globalização e localização no ASP.NET Core.

Aviso

Um problema de namespace raiz pode ocorrer quando o nome de um projeto não é um identificador .NET válido. Por exemplo, my-project-name.csproj usa o raiz do namespace my_project_name e o nome do assembly my-project-name, o que resulta nesse erro.

Recursos e ação de compilação

Se você usar arquivos de recursos para localização, é importante que eles tenham uma ação de compilação apropriada. Usar Embedded Resource; caso contrário, ResourceStringLocalizer não consegue encontrar esses recursos.

Substituição de local usando o painel "Sensores" nas ferramentas de desenvolvedor

Ao usar a substituição de local usando o painel Sensores nas ferramentas de desenvolvedor do Google Chrome ou do Microsoft Edge, a linguagem de fallback é redefinida após a pré-renderização. Evite definir o idioma usando o painel Sensores ao testar. Defina o idioma usando as configurações de idioma do navegador.

Para obter mais informações, consulte Blazor A localização não funciona com InteractiveServer (dotnet/aspnetcore #53707).

Problemas do GitHub com dicas úteis de solução de problemas

  • Last updated on