Compartilhar via

Localização

  • Artigo

Browse sample. Navegue pelo exemplo

Localização é o processo de adaptação de um aplicativo para atender aos requisitos específicos de idioma ou cultura de um mercado-alvo. Para localizar um aplicativo, seu texto e imagens talvez precisem ser traduzidos para vários idiomas. Um aplicativo localizado exibe automaticamente o texto traduzido com base nas configurações de cultura do dispositivo.

O .NET inclui um mecanismo para localizar aplicativos usando arquivos de recursos. Um arquivo de recurso armazena texto e outro conteúdo como pares nome/valor que permitem que o aplicativo recupere conteúdo de uma chave fornecida. Os arquivos de recurso permitem que o conteúdo localizado seja separado do código do aplicativo. Além de armazenar texto, os arquivos de recursos também podem armazenar imagens e dados binários. No entanto, os dispositivos têm uma variedade de tamanhos e densidades de tela e cada plataforma tem funcionalidade para exibir imagens dependentes da densidade. Portanto, a funcionalidade da plataforma deve ser usada para localizar imagens em vez de armazená-las em arquivos de recursos.

Para localizar um aplicativo .NET Multi-platform App UI (.NET MAUI), você deve:

  1. Crie arquivos de recursos para armazenar cadeias de caracteres. Para obter mais informações, consulte Criar arquivos de recurso para armazenar cadeias de caracteres.
  2. Especifique o idioma neutro do aplicativo. Para obter mais informações, consulte Especificar o idioma neutro do aplicativo.
  3. Execute a configuração da plataforma. Para obter mais informações, consulte Executar a configuração da plataforma.
  4. Localize texto. Para obter mais informações, consulte Localizar texto.
  5. Localize imagens. Para obter mais informações, consulte Localizar imagens.
  6. Localize o nome do aplicativo. Para obter mais informações, consulte Localizar o nome do aplicativo.
  7. Localização de teste. Para obter mais informações, consulte Localização de teste.

Além disso, a direção do layout de um aplicativo pode ser especificada. Para obter mais informações, consulte Localização da direita para a esquerda.

Criar arquivos de recursos para armazenar cadeias de caracteres

Arquivos de recurso .NET são arquivos XML com uma extensão .resx que são compilados em arquivos de recurso binário (.resources) durante o processo de compilação. Um aplicativo localizado normalmente contém um arquivo de recurso padrão com todas as cadeias de caracteres usadas no aplicativo e arquivos de recurso para cada idioma com suporte.

Os arquivos de recurso contêm as seguintes informações para cada item:

  • Name especifica a chave usada para acessar o texto no código.
  • Value especifica o texto traduzido.
  • Comentário é um campo opcional que contém informações adicionais.

Um arquivo de recurso pode ser adicionado com a caixa de diálogo Adicionar Novo Item no Visual Studio:

Screenshot of adding a resource file in Visual Studio.

Depois que o arquivo é adicionado, linhas podem ser adicionadas para cada recurso de texto:

Screenshot of the default strings for the app.

O Access Modifier drop-down determina como o Visual Studio gera a classe usada para acessar recursos. Definir o modificador de acesso como Público ou Interno resulta em uma classe gerada com o nível de acessibilidade especificado. Definir o modificador de acesso como Sem geração de código não gera um arquivo de classe. O arquivo de recurso padrão deve ser configurado para gerar um arquivo de classe, o que resulta em um arquivo com o . Designer.cs extensão sendo adicionada ao projeto.

Depois que o arquivo de recurso padrão é criado, arquivos adicionais podem ser criados para cada localidade que o aplicativo suporta. Cada arquivo de recurso adicional deve ter o mesmo nome de arquivo raiz que o arquivo de recurso padrão, mas também deve incluir o idioma e a cultura opcional no nome do arquivo. Por exemplo, se você adicionar um arquivo de recurso chamado AppResources.resx, também poderá criar arquivos de recurso chamados AppResources.en-US.resx e AppResources.fr-FR.resx para armazenar recursos localizados para as culturas inglesa (Estados Unidos) e francesa (França), respectivamente. Além disso, você deve definir o modificador de acesso para cada arquivo de recurso adicional como Sem geração de código.

Em tempo de execução, seu aplicativo tenta resolver uma solicitação de recurso em ordem de especificidade. Por exemplo, se a cultura do dispositivo for en-US , o aplicativo procurará arquivos de recursos nesta ordem:

  1. AppResources.pt-BR.resx
  2. AppResources.pt.resx
  3. AppResources.resx (padrão)

A captura de tela a seguir mostra um arquivo de tradução em espanhol chamado AppResources.es.resx:

Screenshot of the Spanish strings for the app.

O arquivo de recurso localizado usa os mesmos valores de Nome especificados no arquivo padrão, mas contém cadeias de caracteres de idioma espanhol na coluna Valor . Além disso, o modificador de acesso é definido como nenhuma geração de código.

Especificar o idioma neutro do aplicativo

Para que os arquivos de recursos do .NET funcionem corretamente, o aplicativo deve ter uma linguagem neutra especificada. Esse é o idioma cujos recursos são usados se os recursos de uma localidade não puderem ser encontrados. Para especificar a linguagem neutra:

  1. No Gerenciador de Soluções, clique com o botão direito do mouse em seu projeto de aplicativo .NET MAUI e selecione Propriedades.

  2. Selecione a página de propriedades Geral do Pacote > e selecione o idioma e a cultura apropriados na lista suspensa Idioma neutro do assembly:

    Screenshot of setting the neutral language for the assembly.

  3. Salve suas alterações.

Como alternativa, adicione o elemento ao primeiro <PropertyGroup> no arquivo de projeto e especifique a <NeutralLanguage> localidade escolhida como seu valor:

<NeutralLanguage>en-US</NeutralLanguage>

Aviso

Se você não especificar um idioma neutro, a ResourceManager classe retornará null valores para qualquer idioma sem um arquivo de recurso. Quando um idioma neutro é especificado, a ResourceManager classe retorna resultados do arquivo de recurso de linguagem neutra para idiomas sem suporte. Portanto, é recomendável que você sempre especifique um idioma neutro para que o texto seja exibido para idiomas sem suporte.

Executar a configuração da plataforma

É necessária uma configuração adicional no iOS, Mac Catalyst e Windows, para que todos os controles .NET MAUI sejam localizados.

iOS e Mac Catalyst

No iOS e no Mac Catalyst, você deve declarar todos os idiomas com suporte no arquivo Info.plist da plataforma em seu projeto de aplicativo .NET MAUI. Para fazer isso, abra o arquivo Info.plist para a plataforma escolhida em um editor XML e crie uma matriz para a CFBundleLocalizations chave. Em seguida, forneça valores de matriz que correspondam aos arquivos de recurso. Além disso, certifique-se de definir um idioma esperado por meio da CFBundleDevelopmentRegion chave:

<key>CFBundleLocalizations</key>
<array>
    <string>de</string>
    <string>es</string>
    <string>fr</string>
    <string>ja</string>
    <string>pt</string> <!-- Brazil -->
    <string>pt-PT</string> <!-- Portugal -->
    <string>ru</string>
    <string>zh-Hans</string>
    <string>zh-Hant</string>
</array>
<key>CFBundleDevelopmentRegion</key>
<string>en</string>

Como alternativa, no Gerenciador de Soluções no Visual Studio, abra o arquivo Info.plist para a plataforma escolhida no Editor PList genérico. Em seguida, crie uma matriz para a CFBundleLocalizations chave e forneça valores de matriz que correspondam aos arquivos de recurso. Além disso, certifique-se de definir um idioma esperado por meio da CFBundleDevelopmentRegion chave:

Screenshot of the supported locales for the app in the generic Info.plist editor.

Para obter mais informações sobre o arquivo Info.plist , consulte Lista de propriedades de informações.

Windows

Para oferecer suporte a vários idiomas em um aplicativo .NET MAUI no Windows, você deve declarar cada idioma com suporte no arquivo Platforms\Windows\Package.appxmanifest do seu projeto de aplicativo .NET MAUI:

  1. Abra o arquivo Package.appxmanifest em um editor de texto e localize a seguinte seção:

    <Resources>
    <Resource Language="x-generate"/>
</Resources>

  2. Substitua <Resource Language="x-generate"> por <Resource /> elementos para cada um dos idiomas suportados:

    <Resources>
    <Resource Language="en-US"/>
    <Resource Language="de-DE"/>
    <Resource Language="es-ES"/>
    <Resource Language="fr-FR"/>
    <Resource Language="ja-JP"/>
    <Resource Language="pt-BR"/>
    <Resource Language="pt-PT"/>
    <Resource Language="ru-RU"/>
    <Resource Language="zh-CN"/>
    <Resource Language="zh-TW"/>
</Resources>

  3. Salve suas alterações.

Localizar texto

O texto é localizado usando uma classe gerada a partir do arquivo de recursos padrão. A classe é nomeada com base no nome do arquivo de recurso padrão. Dado um nome de arquivo de recurso padrão de AppResources.resx, Visual Studio gera uma classe correspondente chamada AppResources contendo propriedades estáticas para cada entrada no arquivo de recurso.

Em XAML, o texto localizado pode ser recuperado usando a extensão de x:Static marcação para acessar as propriedades estáticas geradas:

<ContentPage ...
             xmlns:strings="clr-namespace:LocalizationDemo.Resources.Strings">
    <VerticalStackLayout>
        <Label Text="{x:Static strings:AppResources.NotesLabel}" />
        <Entry Placeholder="{x:Static strings:AppResources.NotesPlaceholder}" />
        <Button Text="{x:Static strings:AppResources.AddButton}" />
    </VerticalStackLayout>
</ContentPage>

Para obter mais informações sobre a extensão de x:Static marcação, consulte x:Static markup extension.

O texto localizado também pode ser recuperado no código:

Label notesLabel = new Label();
notesLabel.Text = AppResources.NotesLabel,

Entry notesEntry = new Entry();
notesEntry.Placeholder = AppResources.NotesPlaceholder,

Button addButton = new Button();
addButton.Text = AppResources.AddButton,

As propriedades na AppResources classe usam o valor da CurrentUICulture propriedade para determinar de qual arquivo de recurso recuperar valores.

Localizar imagens

Além de armazenar texto, os arquivos de recursos também podem armazenar imagens e dados binários. No entanto, os dispositivos têm uma variedade de tamanhos e densidades de tela e cada plataforma tem funcionalidade para exibir imagens dependentes da densidade. Portanto, a funcionalidade da plataforma deve ser usada para localizar imagens em vez de armazená-las em arquivos de recursos.

Android

No Android, as imagens localizadas, conhecidas como drawables, são armazenadas usando uma convenção de nomenclatura baseada em pasta na pasta Platforms\Android\Resources . As pastas devem ser nomeadas como desenháveis com um sufixo para o idioma e a cultura. Por exemplo, a pasta de idioma espanhol é chamada drawable-es. O nome da pasta desenhável deve conter as imagens para o idioma e a cultura padrão. A ação de compilação de cada imagem deve ser definida como AndroidResource.

Observação

Em vez de definir arquivos individuais para a ação de compilação AndroidResource , o conteúdo de uma pasta específica pode ser definido para essa ação de compilação adicionando o seguinte XML ao arquivo de projeto (.csproj) do seu aplicativo:

<ItemGroup Condition="$(TargetFramework.Contains('-android'))">
  <AndroidResource Include="Platforms\Android\Resources\**" TargetPath="%(RecursiveDir)%(Filename)%(Extension)" />
</ItemGroup>

Este exemplo define qualquer conteúdo na pasta Platforms\Android\Resources , incluindo conteúdo em subpastas, para a ação de compilação AndroidResource . Ele também define o caminho de saída para cada arquivo com essa ação de compilação.

Apenas dois caracteres são necessários no nome da pasta ao especificar um idioma de nível superior, como es. No entanto, ao especificar uma localidade completa, o formato de nome da pasta requer um traço e um r minúsculo para separar o idioma da cultura. Por exemplo, a pasta Mexico locale (es-MX) deve ser nomeada drawable-es-rMX. Os nomes de arquivo de imagem em cada pasta de localidade devem ser idênticos:

Screenshot of the localized folder structure in Visual Studio for images on Android.

iOS

No iOS, as imagens localizadas são armazenadas usando uma convenção de nomenclatura baseada em pasta na pasta Platforms\iOS\Resources . As pastas devem ser nomeadas com o idioma e a cultura opcional, seguidas por .lproj. Por exemplo, a pasta de idioma espanhol é chamada es.lproj. A ação de compilação de cada imagem deve ser definida como BundleResource.

Observação

Em vez de definir arquivos individuais para a ação de compilação BundleResource , o conteúdo de uma pasta específica pode ser definido para essa ação de compilação adicionando o seguinte XML ao arquivo de projeto (.csproj) do seu aplicativo:

<ItemGroup Condition="$(TargetFramework.Contains('-ios'))">
  <BundleResource Include="Platforms\iOS\Resources\**" TargetPath="%(RecursiveDir)%(Filename)%(Extension)" />
</ItemGroup>

Este exemplo define qualquer conteúdo na pasta Platforms\iOS\Resources , incluindo conteúdo em subpastas, para a ação de compilação BundleResource . Ele também define o caminho de saída para cada arquivo com essa ação de compilação.

Apenas dois caracteres são necessários no nome da pasta ao especificar um idioma de nível superior, como es. No entanto, ao especificar uma localidade completa, o formato de nome da pasta requer um traço para separar o idioma da cultura. Por exemplo, a pasta Mexico locale (es-MX) deve ser chamada es-MX.lproj. Os nomes de arquivo de imagem em cada pasta de localidade devem ser idênticos:

Screenshot of the localized folder structure in Visual Studio for images on iOS.

Além disso, no arquivo de projeto, você deve definir a propriedade build para a IPhoneResourcePrefix pasta que contém as pastas de imagem localizadas:

<PropertyGroup Condition="$(TargetFramework.Contains('-ios'))">
  <IPhoneResourcePrefix>Platforms/iOS/Resources</IPhoneResourcePrefix>
</PropertyGroup>

Se uma imagem não estiver presente para um idioma específico, o iOS retornará à pasta de idioma nativo padrão e carregará a imagem a partir daí.

Mac Catalyst

No Mac Catalyst, as imagens localizadas são armazenadas usando uma convenção de nomenclatura baseada em pasta na pasta Platforms\MacCatalyst\Resources . As pastas devem ser nomeadas com o idioma e a cultura opcional, seguidas por .lproj. Por exemplo, a pasta de idioma espanhol é chamada es.lproj. A ação de compilação de cada imagem deve ser definida como BundleResource.

Observação

Em vez de definir arquivos individuais para a ação de compilação BundleResource , o conteúdo de uma pasta específica pode ser definido para essa ação de compilação adicionando o seguinte XML ao arquivo de projeto (.csproj) do seu aplicativo:

<ItemGroup Condition="$(TargetFramework.Contains('-maccatalyst'))">
  <BundleResource Include="Platforms\MacCatalyst\Resources\**" TargetPath="%(RecursiveDir)%(Filename)%(Extension)" />
</ItemGroup>

Este exemplo define qualquer conteúdo na pasta Platforms\MacCatalyst\Resources , incluindo conteúdo em subpastas, para a ação de compilação BundleResource . Ele também define o caminho de saída para cada arquivo com essa ação de compilação.

Apenas dois caracteres são necessários no nome da pasta ao especificar um idioma de nível superior, como es. No entanto, ao especificar uma localidade completa, o formato de nome da pasta requer um traço para separar o idioma da cultura. Por exemplo, a pasta Mexico locale (es-MX) deve ser chamada es-MX.lproj. Os nomes de arquivo de imagem em cada pasta de localidade devem ser idênticos:

Screenshot of the localized folder structure in Visual Studio for images on MacCatalyst.

Além disso, no arquivo de projeto, você deve definir a propriedade build para a IPhoneResourcePrefix pasta que contém as pastas de imagem localizadas:

<PropertyGroup Condition="$(TargetFramework.Contains('-maccatalyst'))">
  <IPhoneResourcePrefix>Platforms/MacCatalyst/Resources</IPhoneResourcePrefix>
</PropertyGroup>

Se uma imagem não estiver presente para um idioma específico, o Mac Catalyst retornará para a pasta de idioma nativo padrão e carregará a imagem a partir daí.

Windows

No Windows, as imagens localizadas são armazenadas usando uma convenção de nomenclatura baseada em pasta na pasta Platforms\Windows\Assets\Images . As pastas devem ser nomeadas com o idioma e a cultura opcional. Por exemplo, a pasta de idioma espanhol é chamada es e a pasta de localidade México deve ser chamada es-MX. A ação de compilação de cada imagem deve ser definida como Conteúdo.

Observação

Em vez de definir arquivos individuais para a ação de compilação de conteúdo, o conteúdo de uma pasta específica pode ser definido para essa ação de compilação adicionando o seguinte XML ao arquivo de projeto (.csproj) do seu aplicativo:

<ItemGroup Condition="$(TargetFramework.Contains('-windows'))">
  <Content Include="Platforms\Windows\Assets\Images\**" TargetPath="%(RecursiveDir)%(Filename)%(Extension)" />
</ItemGroup>

Este exemplo define qualquer conteúdo na pasta Platforms\Windows\Assets\Images, incluindo conteúdo em subpastas, para a ação de compilação Content. Ele também define o caminho de saída para cada arquivo com essa ação de compilação.

Apenas dois caracteres são necessários no nome da pasta ao especificar um idioma de nível superior, como es. No entanto, ao especificar uma localidade completa, o formato de nome da pasta requer um traço para separar o idioma da cultura. Por exemplo, a pasta Mexico locale (es-MX) deve ser chamada es-MX. Os nomes de arquivo de imagem em cada pasta de localidade devem ser idênticos:

Screenshot of the localized folder structure in Visual Studio for images on Windows.

Consumir imagens localizadas

No Android, iOS, Mac Catalyst e Windows, as imagens localizadas podem ser consumidas definindo a Source propriedade de an Image para o nome do arquivo da imagem:

<Image Source="flag.png" />

No entanto, para que isso funcione no Windows, é necessário modificar o arquivo de projeto do aplicativo se você tiver adicionado um <Content /> item do MSBuild para cada imagem localizada. Isso pode ser feito modificando o arquivo .csproj para remover o <Content /> item MSBuild para cada imagem. Em seguida, adicione o seguinte item MSBuild:

<ItemGroup Condition="$(TargetFramework.Contains('-windows'))">
  <Content Include="Platforms\Windows\Assets\Images\**" TargetPath="%(RecursiveDir)%(Filename)%(Extension)" />
</ItemGroup>

Isso garante que todas as imagens nas subpastas da pasta Platforms\Windows\Assets\Images sejam copiadas para a raiz do pacote do aplicativo.

Localizar o nome do aplicativo

A funcionalidade da plataforma é necessária para localizar o nome do aplicativo.

Android

No Android, o nome do aplicativo localizado pode ser armazenado usando uma convenção de nomenclatura baseada em pasta na pasta Platforms\Android\Resources . As pastas devem ser nomeadas valores com um sufixo para o idioma e a cultura. Por exemplo, a pasta de idioma espanhol é chamada values-es. Adicione um arquivo Strings.xml com uma ação de compilação de AndroidResource a cada pasta que define uma cadeia de caracteres para o nome do aplicativo localizado.

Observação

Em vez de definir arquivos individuais para a ação de compilação AndroidResource , o conteúdo de uma pasta específica pode ser definido para essa ação de compilação adicionando o seguinte XML ao arquivo de projeto (.csproj) do seu aplicativo:

<ItemGroup Condition="$(TargetFramework.Contains('-android'))">
  <AndroidResource Include="Platforms\Android\Resources\**" TargetPath="%(RecursiveDir)%(Filename)%(Extension)" />
</ItemGroup>

Este exemplo define qualquer conteúdo na pasta Platforms\Android\Resources , incluindo conteúdo em subpastas, para a ação de compilação AndroidResource . Ele também define o caminho de saída para cada arquivo com essa ação de compilação.

Apenas dois caracteres são necessários no nome da pasta ao especificar um idioma de nível superior, como es. No entanto, ao especificar uma localidade completa, o formato de nome da pasta requer um traço e um r minúsculo para separar o idioma da cultura. Por exemplo, a pasta de localidade do México (es-MX) deve ser nomeada values-es-rMX.

Cada cadeia de caracteres traduzível é um elemento XML com a ID do recurso especificada como o atributo e a cadeia de caracteres traduzida como o name valor. Você precisa escapar de sua cadeia de caracteres de acordo com as regras XML normais, e o name deve ser um ID de recurso Android válido (sem espaços ou traços).

Portanto, para localizar o nome do aplicativo, crie um arquivo Strings.xml e adicione um elemento como filho de um <resources><string> elemento. Em seguida, defina seu name atributo como um ID adequado com a cadeia de caracteres traduzida como o valor:

<resources>
    <!-- French -->
    <string name="app_name">Maison</string>
</resources>

Em seguida, para usar o nome do aplicativo localizado em seu aplicativo, adicione a Label propriedade à Activity classe do aplicativo MainActivity e defina seu valor como @string/id:

[Activity(Label = "@string/app_name", Theme = "@style/Maui.SplashTheme", MainLauncher = true, ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation | ConfigChanges.UiMode | ConfigChanges.ScreenLayout | ConfigChanges.SmallestScreenSize | ConfigChanges.Density)]
public class MainActivity : MauiAppCompatActivity
{
    protected override void OnCreate(Bundle savedInstanceState)
    {
        base.OnCreate(savedInstanceState);
    }
}

iOS

No iOS, o nome do aplicativo localizado é armazenado usando uma convenção de nomenclatura baseada em pasta na pasta Platforms\iOS\Resources . As pastas devem ser nomeadas com o idioma e a cultura opcional, seguidas por .lproj. Por exemplo, a pasta de idioma espanhol é chamada es.lproj. Adicione um arquivo InfoPlist.strings com uma ação de compilação de BundleResource a cada pasta que define a chave e o CFBundleDisplayName valor.

Observação

Em vez de definir arquivos individuais para a ação de compilação BundleResource , o conteúdo de uma pasta específica pode ser definido para essa ação de compilação adicionando o seguinte XML ao arquivo de projeto (.csproj) do seu aplicativo:

<ItemGroup Condition="$(TargetFramework.Contains('-ios'))">
  <BundleResource Include="Platforms\iOS\Resources\**" TargetPath="%(RecursiveDir)%(Filename)%(Extension)" />
</ItemGroup>

Este exemplo define qualquer conteúdo na pasta Platforms\iOS\Resources , incluindo conteúdo em subpastas, para a ação de compilação BundleResource . Ele também define o caminho de saída para cada arquivo com essa ação de compilação.

A sintaxe para valores de cadeia de caracteres localizados é:

/* comment */
"key"="localized-value";

Você deve escapar dos seguintes caracteres em cadeias de caracteres:

  • Cota de \"
  • \\ barra invertida
  • \n Newline

Portanto, para localizar o nome do aplicativo, crie um arquivo InfoPlist.strings e adicione um valor para a CFBundleDisplayName chave ao arquivo:

/* French */
CFBundleDisplayName="Maisons";

Outras chaves que você pode usar para localizar cadeias de caracteres específicas do aplicativo são:

  • CFBundleName - especifica o nome curto do pacote de aplicativos, que pode ser exibido aos usuários em situações como a ausência de um valor para CFBundleDisplayName.
  • CFBundleShortVersionString - especifica o número da versão de lançamento do pacote de aplicativos.
  • NSHumanReadableCopyright - o aviso de direitos autorais para o pacote de aplicativos.

Além disso, no arquivo de projeto, você deve definir a propriedade build para a IPhoneResourcePrefix pasta que contém as pastas localizadas:

<PropertyGroup Condition="$(TargetFramework.Contains('-ios'))">
  <IPhoneResourcePrefix>Platforms/iOS/Resources</IPhoneResourcePrefix>
</PropertyGroup>

Mac Catalyst

No Mac Catalyst, o nome do aplicativo localizado é armazenado usando uma convenção de nomenclatura baseada em pasta na pasta Platforms\MacCatalyst\Resources . As pastas devem ser nomeadas com o idioma e a cultura opcional, seguidas por .lproj. Por exemplo, a pasta de idioma espanhol é chamada es.lproj. Adicione um arquivo InfoPlist.strings com uma ação de compilação de BundleResource a cada pasta que define a chave e o CFBundleDisplayName valor.

Observação

Em vez de definir arquivos individuais para a ação de compilação BundleResource , o conteúdo de uma pasta específica pode ser definido para essa ação de compilação adicionando o seguinte XML ao arquivo de projeto (.csproj) do seu aplicativo:

<ItemGroup Condition="$(TargetFramework.Contains('-maccatalyst'))">
  <BundleResource Include="Platforms\MacCatalyst\Resources\**" TargetPath="%(RecursiveDir)%(Filename)%(Extension)" />
</ItemGroup>

Este exemplo define qualquer conteúdo na pasta Platforms\MacCatalyst\Resources , incluindo conteúdo em subpastas, para a ação de compilação BundleResource . Ele também define o caminho de saída para cada arquivo com essa ação de compilação.

A sintaxe para valores de cadeia de caracteres localizados é:

/* comment */
"key"="localized-value";

Você deve escapar dos seguintes caracteres em cadeias de caracteres:

  • Cota de \"
  • \\ barra invertida
  • \n Newline

Portanto, para localizar o nome do aplicativo, crie um arquivo InfoPlist.strings e adicione um valor para a CFBundleDisplayName chave ao arquivo:

/* French */
CFBundleDisplayName="Maisons";

Outras chaves que você pode usar para localizar cadeias de caracteres específicas do aplicativo são:

  • CFBundleName - especifica o nome curto do pacote de aplicativos, que pode ser exibido aos usuários em situações como a ausência de um valor para CFBundleDisplayName.
  • CFBundleShortVersionString - especifica o número da versão de lançamento do pacote de aplicativos.
  • NSHumanReadableCopyright - o aviso de direitos autorais para o pacote de aplicativos.

Além disso, no arquivo de projeto, você deve definir a propriedade build para a IPhoneResourcePrefix pasta que contém as pastas localizadas:

<PropertyGroup Condition="$(TargetFramework.Contains('-maccatalyst'))">
  <IPhoneResourcePrefix>Platforms/MacCatalyst/Resources</IPhoneResourcePrefix>
</PropertyGroup>

Windows

No Windows, o nome do aplicativo é definido no manifesto do pacote do aplicativo. A localização do nome do aplicativo requer que você primeiro especifique o idioma padrão para o aplicativo e, em seguida, crie um arquivo de recurso de cadeia de caracteres para cada localidade que você pretende suportar. O recurso de cadeia de caracteres que representa o nome do aplicativo localizado pode ser consumido no manifesto do pacote do aplicativo usando o esquema de ms-resource URI.

Para obter mais informações sobre como localizar cadeias de caracteres no manifesto do pacote do aplicativo, consulte Localizar cadeias de caracteres na interface do usuário e no manifesto do pacote do aplicativo.

Especificar o idioma padrão

Para localizar um nome de aplicativo, seu aplicativo do Windows deve primeiro ter um idioma padrão especificado. Este é o idioma cujos recursos são usados se nenhum recurso localizado para um idioma específico puder ser encontrado. Para especificar o idioma padrão:

  1. No Gerenciador de Soluções, abra o arquivo Packageappxmanifest no editor de manifesto do pacote.

  2. No editor de manifesto do pacote, na guia Aplicativo, defina o campo Idioma padrão para o idioma padrão escolhido:

    Screenshot of setting the default language of a Windows app in the package manifest.

  3. Salve suas alterações.

No mínimo, você precisa fornecer um recurso de cadeia de caracteres para o nome do aplicativo para o idioma padrão. Este é o recurso que é carregado se nenhuma correspondência melhor puder ser encontrada para o idioma preferido do usuário ou as configurações de idioma de exibição.

Criar arquivos de recursos do Windows

No Windows, o nome do aplicativo localizado deve ser armazenado em um arquivo de recurso do Windows para cada localidade. Um arquivo de recurso do Windows é um arquivo XML com uma extensão .resw que é compilado em um formato binário e armazenado em um arquivo .pri . O arquivo .resw para cada localidade deve ser chamado Resources.resw e armazenado usando uma convenção de nomenclatura baseada em pasta na pasta Platforms\Windows\Strings. As pastas devem ser nomeadas com o idioma e a cultura opcional. Por exemplo, a pasta de idioma espanhol é chamada es e a pasta de localidade México deve ser chamada es-MX.

No momento, não há nenhum modelo de item do Visual Studio para criar um arquivo de recurso do Windows em um aplicativo .NET MAUI. Portanto, para criar um arquivo de recurso do Windows para cada localidade:

  1. Na pasta Platforms\Windows do seu projeto de aplicativo .NET MAUI, crie uma pasta Strings.

  2. Na pasta Strings, crie uma pasta para cada localidade.

  3. Na pasta para cada localidade, crie um arquivo chamado Resources.resw que contém o seguinte XML:

    <?xml version="1.0" encoding="utf-8"?>
<root>
  <!--
    Microsoft ResX Schema

    Version 2.0

    The primary goals of this format is to allow a simple XML format
    that is mostly human readable. The generation and parsing of the
    various data types are done through the TypeConverter classes
    associated with the data types.

    Example:

    ... ado.net/XML headers & schema ...
    <resheader name="resmimetype">text/microsoft-resx</resheader>
    <resheader name="version">2.0</resheader>
    <resheader name="reader">System.Resources.ResXResourceReader, System.Windows.Forms, ...</resheader>
    <resheader name="writer">System.Resources.ResXResourceWriter, System.Windows.Forms, ...</resheader>
    <data name="Name1"><value>this is my long string</value><comment>this is a comment</comment></data>
    <data name="Color1" type="System.Drawing.Color, System.Drawing">Blue</data>
    <data name="Bitmap1" mimetype="application/x-microsoft.net.object.binary.base64">
        <value>[base64 mime encoded serialized .NET Framework object]</value>
    </data>
    <data name="Icon1" type="System.Drawing.Icon, System.Drawing" mimetype="application/x-microsoft.net.object.bytearray.base64">
        <value>[base64 mime encoded string representing a byte array form of the .NET Framework object]</value>
        <comment>This is a comment</comment>
    </data>

    There are any number of "resheader" rows that contain simple
    name/value pairs.

    Each data row contains a name, and value. The row also contains a
    type or mimetype. Type corresponds to a .NET class that support
    text/value conversion through the TypeConverter architecture.
    Classes that don't support this are serialized and stored with the
    mimetype set.

    The mimetype is used for serialized objects, and tells the
    ResXResourceReader how to depersist the object. This is currently not
    extensible. For a given mimetype the value must be set accordingly:

    Note - application/x-microsoft.net.object.binary.base64 is the format
    that the ResXResourceWriter will generate, however the reader can
    read any of the formats listed below.

    mimetype: application/x-microsoft.net.object.binary.base64
    value   : The object must be serialized with
            : System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
            : and then encoded with base64 encoding.

    mimetype: application/x-microsoft.net.object.soap.base64
    value   : The object must be serialized with
            : System.Runtime.Serialization.Formatters.Soap.SoapFormatter
            : and then encoded with base64 encoding.

    mimetype: application/x-microsoft.net.object.bytearray.base64
    value   : The object must be serialized into a byte array
            : using a System.ComponentModel.TypeConverter
            : and then encoded with base64 encoding.
    -->
  <xsd:schema id="root" xmlns="" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
    <xsd:import namespace="http://www.w3.org/XML/1998/namespace" />
    <xsd:element name="root" msdata:IsDataSet="true">
      <xsd:complexType>
        <xsd:choice maxOccurs="unbounded">
          <xsd:element name="metadata">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:element name="value" type="xsd:string" minOccurs="0" />
              </xsd:sequence>
              <xsd:attribute name="name" use="required" type="xsd:string" />
              <xsd:attribute name="type" type="xsd:string" />
              <xsd:attribute name="mimetype" type="xsd:string" />
              <xsd:attribute ref="xml:space" />
            </xsd:complexType>
          </xsd:element>
          <xsd:element name="assembly">
            <xsd:complexType>
              <xsd:attribute name="alias" type="xsd:string" />
              <xsd:attribute name="name" type="xsd:string" />
            </xsd:complexType>
          </xsd:element>
          <xsd:element name="data">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />
                <xsd:element name="comment" type="xsd:string" minOccurs="0" msdata:Ordinal="2" />
              </xsd:sequence>
              <xsd:attribute name="name" type="xsd:string" use="required" msdata:Ordinal="1" />
              <xsd:attribute name="type" type="xsd:string" msdata:Ordinal="3" />
              <xsd:attribute name="mimetype" type="xsd:string" msdata:Ordinal="4" />
              <xsd:attribute ref="xml:space" />
            </xsd:complexType>
          </xsd:element>
          <xsd:element name="resheader">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />
              </xsd:sequence>
              <xsd:attribute name="name" type="xsd:string" use="required" />
            </xsd:complexType>
          </xsd:element>
        </xsd:choice>
      </xsd:complexType>
    </xsd:element>
  </xsd:schema>
  <resheader name="resmimetype">
    <value>text/microsoft-resx</value>
  </resheader>
  <resheader name="version">
    <value>2.0</value>
  </resheader>
  <resheader name="reader">
    <value>System.Resources.ResXResourceReader, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
  </resheader>
  <resheader name="writer">
    <value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
  </resheader>
</root>

    Observação

    Os arquivos de recursos do Windows usam uma ação de compilação do PRIResource. Essa ação de compilação não precisa ser definida em cada arquivo .resw em um aplicativo .NET MAUI, porque é aplicada implicitamente.

  4. Abra cada arquivo Resources.resw e adicione um recurso de cadeia de caracteres que representa o nome do aplicativo:

    Screenshot of the resw file editor in Visual Studio on Windows.

    Observação

    Os identificadores de recursos não diferenciam maiúsculas de minúsculas e devem ser exclusivos por arquivo de recurso.

  5. Salve cada arquivo de recurso do Windows.

Um exemplo da estrutura de pastas e arquivos necessária é mostrado na captura de tela a seguir:

Screenshot of the localized folder structure in Visual Studio for strings on Windows.

Consumir o nome do aplicativo localizado

O recurso de cadeia de caracteres que representa o nome do aplicativo localizado pode ser consumido usando o esquema de ms-resource URI:

  1. No Gerenciador de Soluções, abra o arquivo Packageappxmanifest no editor de manifesto do pacote.

  2. No editor de manifesto do pacote, na guia Aplicativo , defina o campo Nome para exibição como ms-resource: seguido pelo nome do recurso de cadeia de caracteres que identifica o nome do aplicativo:

    Screenshot of setting the localized app name in the package manifest on Windows.

  3. Salve suas alterações.

Importante

Se os arquivos .resw estiverem armazenados em um assembly diferente do projeto do aplicativo .NET MAUI, você precisará especificar um caminho totalmente qualificado para o nome do recurso. Isso usa o formato ms-resource:Assembly/ResourceFilename/Resource.

Localização da direita para a esquerda

Direção de fluxo, ou direção de layout, é a direção na qual os elementos da interface do usuário na página são verificados pelo olho. Alguns idiomas, como árabe e hebraico, exigem que os elementos de interface do usuário sejam dispostos em uma direção de fluxo da direita para a esquerda. Os aplicativos .NET MAUI respeitam automaticamente a direção do fluxo do dispositivo com base no idioma e na região selecionados. Para obter informações sobre como recuperar a direção do fluxo do dispositivo, com base em sua localidade, consulte Obter a direção do layout.

Para substituir a direção do fluxo de um aplicativo, defina a Window.FlowDirection propriedade. Como alternativa, defina a VisualElement.FlowDirection propriedade por elemento. Essas propriedades obtêm ou definem a direção na qual os FlowDirection elementos da interface do usuário fluem dentro de qualquer elemento pai que controla seu layout e devem ser definidas como um dos valores de enumeração:

  • LeftToRight
  • RightToLeft
  • MatchParent

Definir a propriedade como RightToLeft em um elemento define o alinhamento à direita, a ordem de leitura à direita para a esquerda e o layout do controle para fluir da direita para a FlowDirection esquerda.

Aviso

Alterar a propriedade em tempo de execução causa um processo de layout caro que afetará o FlowDirection desempenho.

O valor da propriedade padrão FlowDirection para um elemento é MatchParent. Portanto, um elemento herda o valor da propriedade FlowDirection de seu pai na árvore visual e qualquer elemento pode substituir o valor obtido de seu pai.

Dica

Se você precisar alterar a direção do fluxo, defina a FlowDirection propriedade em uma janela, página ou layout raiz. Isso faz com que todos os elementos contidos no aplicativo, página ou layout raiz respondam adequadamente à direção do fluxo.

Instalação da plataforma

A instalação da plataforma específica é necessária para habilitar localidades com leitura da direita para a esquerda.

Android

Os aplicativos criados usando o modelo de projeto de aplicativo .NET MAUI incluem automaticamente suporte para localidades da direita para a esquerda. Esse suporte é habilitado android:supportsRtl pelo atributo que está sendo definido como true no nó no <application> arquivo AndroidManifest do aplicativo.xml :

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    <application ... android:supportsRtl="true" />
    ...
</manifest>

A localização da direita para a esquerda pode ser testada alterando o dispositivo ou emulador para usar o idioma da direita para a esquerda. Como alternativa, se você ativou as opções do desenvolvedor no aplicativo Configurações, poderá habilitar Forçar direção de layout RTL em Opções do desenvolvedor de Configurações>. Para obter informações sobre como configurar opções do desenvolvedor, consulte Configurar opções do desenvolvedor no dispositivo no developer.android.com.

iOS e Mac Catalyst

A localidade com leitura da direita para a esquerda necessária deve ser adicionada como um idioma compatível aos itens de matriz da chave CFBundleLocalizations em Info.plist. O seguinte exemplo mostra o árabe adicionado à matriz da chave CFBundleLocalizations:

<key>CFBundleLocalizations</key>
<array>
    <string>en</string>
    <string>ar</string>
</array>

A localização da direita para a esquerda pode ser testada alterando o idioma e a região no dispositivo ou simulador para uma localidade da direita para a esquerda especificada em Info.plist.

Windows

Os recursos de idioma necessários devem ser especificados no nó <Resources> do arquivo Package.appxmanifest. Substitua <Resource Language="x-generate"> por <Resource /> elementos para cada um dos idiomas suportados. Por exemplo, a marcação a seguir especifica que os recursos localizados "en" e "ar" estão disponíveis:

<Resources>
    <Resource Language="en" />
    <Resource Language="ar" />
</Resources>

A localização da direita para a esquerda pode então ser testada, alterando o idioma e a região no dispositivo para a localidade da direita para a esquerda apropriada.

Localização de teste

Em tempo de execução, seu aplicativo carrega os recursos localizados apropriados por thread, com base na cultura especificada pela CurrentUICulture propriedade.

O teste de localização é melhor realizado alterando o idioma do dispositivo no aplicativo Configurações em cada dispositivo.

Aviso

Embora seja possível definir o valor de CurrentUICulture no código, o comportamento resultante é inconsistente entre plataformas, portanto, isso não é recomendado para teste.