1. Epic GamesDeveloper
  3. Visão geral da localização

Visão geral da localização

Visão geral da localização

Descrição: Visão geral dos elementos envolvidos na localização do seu projeto. Type: overview Version: 5.0 Parent: working-with-content/Localization order:0 Tags: Localização Tags: Visão geral

Localização e internacionalização

Localização e internacionalização (L10N e I18N) são dois conceitos que costumam ser combinados sob o guarda-chuva da "localização". No entanto, são duas coisas distintas, e a Unreal Engine (UE) lida com elas de maneiras diferentes. O sistema de localização na UE é baseado no tipo "texto", e o suporte para internacionalização usa a biblioteca [International Components for Unicode] (http://site.icu-project.org/).

Embora sejam separados, na UE não é possível ter localização em tempo de execução sem o suporte apropriado para a internacionalização.

ICU e suporte para internacionalização

A ICU é uma biblioteca de internacionalização avançada e robusta que a UE usa para lidar com tudo que envolve dados ou processamentos específicos da cultura, incluindo:

  • Como obter a cultura atual para a plataforma/SO.

  • Como lidar com a reserva priorizada de culturas.

  • Como lidar com a cultura da formatação correta de números (incluindo porcentagens e moedas) e datas e horas (incluindo dados de fuso horário).

  • Como lidar com a pluralidade correta de números (durante a formatação de texto).

  • Como processar transformações de texto compatíveis com Unicode (por exemplo, "ToUpper", "ToLower").

  • Como processar comparação e agrupamento de texto compatíveis com Unicode.

  • Como processar análises de limites (caracteres, palavras e quebras de linha).

  • Como processar detecção de texto bidirecional (BiDi) compatível com Unicode.

Os dados específicos da cultura que a ICU precisa para funcionar são armazenados fora da própria ICU, e a UE fornece alguns conjuntos de dados que você pode usar para minimizar o tamanho do projeto:

  • English (~1.77 MB)

  • EFIGS - Inglês, Francês, Italiano, Alemão e Espanhol (~2.38 MB)

  • EFIGSCJK - Inglês, Francês, Italiano, Alemão, Espanhol, Chinês, Japonês e Coreano (~5.99 MB)

  • CJK - Chinês, Japonês e Coreano (~5.16 MB)

  • All (~15.3 MB)

A escolha dependerá das regiões em que você localiza o projeto. Você pode definir essas opções em Project Settings. Confira o pacote de dados de localização para obter mais informações.

Culturas

As culturas na UE contêm informações de internacionalização para uma localidade específica. Os nomes de culturas são compostos de três partes separadas por hífen (uma etiqueta de idioma da IETF):

  • Um código de linguagem ISO 639-1 de duas letras (como "zh").

  • Um código opcional ISO 15924 de quatro letras (como "Hans").

  • Um código de país ISO 3166-1 opcional de duas letras (como "CN").

Quando a UE procura dados de localização para uma cultura específica, ela os processa do mais para o menos específico. Por exemplo:

  • zh-Hans-CN é processado como "zh-Hans-CN", "zh-CN", "zh-Hans" e "zh".

  • en-GB é processado como "en-GB" e, em seguida, como "en".

Para obter a maior abrangência para uma cultura específica, use o código de cultura menos específico válido. Geralmente, isso é apenas o código do idioma, mas fique atento às variações de linguagem regional que precisam ser consideradas.

Na maioria dos casos, essas variações regionais estão limitadas a um código de país específico, o que as torna fáceis de resolver. No entanto, há casos mais complexos, como mostrado a seguir.

Chinês

O chinês tem duas variantes, a simplificada e a tradicional, representadas pelos códigos de código ISO-15924 "Hans" e "Hant". Use "zh-Hans" para a localização simplificada e "zh-Hant" para a localização tradicional.

Espanhol

O espanhol tem duas variantes principais: a europeia e a latino-americana. No entanto, não há um código de script prático que possa ser usado para distinguir uma da outra. Há uma tag de idioma da IETF para o espanhol latino-americano ("es-419"), mas a maioria das plataformas não fornece isso. Em vez disso, você recebe o código do país ("es-MX").

Para resolver isso, use "es" para espanhol europeu e "es-419" para o espanhol latino-americano. Em seguida, use a funcionalidade Como remapear culturas da UE para mapear os países que falam espanhol da América Latina para "es-419".

Isso pode ser feito adicionando o seguinte ao arquivo "DefaultGame.ini":

	[Internacionalização]
	+CultureMappings="es-AR;es-419"
	+CultureMappings="es-BO;es-419"
	+CultureMappings="es-CL;es-419"
	+CultureMappings="es-CO;es-419"
	+CultureMappings="es-CR;es-419"
	+CultureMappings="es-CU;es-419"
	+CultureMappings="es-DO;es-419"
	+CultureMappings="es-EC;es-419"
	+CultureMappings="es-GT;es-419"
	+CultureMappings="es-HN;es-419"
	+CultureMappings="es-MX;es-419"
	+CultureMappings="es-NI;es-419"
	+CultureMappings="es-PA;es-419"
	+CultureMappings="es-PE;es-419"
	+CultureMappings="es-PR;es-419"
	+CultureMappings="es-PY;es-419"
	+CultureMappings="es-SV;es-419"
	+CultureMappings="es-US;es-419"
	+CultureMappings="es-UY;es-419"
	+CultureMappings="es-VE;es-419"

Destinos de localização

Localization Targets são módulos nomeados e independentes de dados de localização. Os destinos de localização têm as seguintes propriedades:

  • Possuem texto coletado de um conjunto específico de fontes;

  • São armazenados em um arquivo de manifesto;

  • São traduzidos em arquivos compactados específicos da cultura;

  • São compilados em arquivos de recursos de localização específicos da cultura, e o sistema exibe os arquivos compilados e específicos da cultura.

Um projeto pode ter um único destino de localização para simplificar, ou pode ter vários destinos de localização para dividir os dados de localização do projeto em seções. O Unreal Editor tem um destino de localização separado do resto da UE, para que o editor possa ser localizado sem distribuir esses dados de localização com jogos. Normalmente, um jogo tem um destino de localização para todos os dados de localização do projeto-base e destinos de localização adicionais para expansões.

Pipeline de localização

O pipeline de localização da UE é modelado em torno de uma abordagem de "autoria na fonte" para localização. Isso significa que, se você precisar de uma mensagem de texto dizendo "Olá, mundo!" na IU, basta digitar "Olá, mundo!" na propriedade de texto (ou usar as macros "NSLOCTEXT" ou "LOCTEXT" em C++), e o coletor de localização se encarrega de capturar o texto para que seja localizado.

A abordagem de "criação na fonte" é muito dinâmica e permite que os desenvolvedores não se preocupem muito com a localização durante o desenvolvimento. No entanto, também pode ser frustrante para equipes que desejam ter um controle rígido sobre o texto usado em seus projetos. Para resolver isso, a UE oferece suporte para tabelas de string para permitir uma abordagem de "criação uma vez e referência" para localização (embora, internamente, o pipeline trate as tabelas de string como fonte "autor na fonte").

Um método mais antigo (e que não é mais suportado) para contornar a falta de tabelas de strings nativas era usar uma cultura nativa "falsa" (provavelmente "es-US-POSIX") com IDs como texto de origem e usar a função de recolher strings que a UE tinha antes da versão 4.14 para traduzir esses IDs para cada idioma. Você pode encontrar referências a esse método em perguntas de suporte mais antigas, mas ele não deve mais ser usado. Projetos que usam esse método devem migrar para tabelas de strings.

O pipeline de localização funciona com base em destinos de localização, que são formados por duas partes: a configuração (armazenada em "Config/Localization/") e os dados (armazenados em "Content/Localization/{TargetName}/").

Se presumirmos que um destino de localização funciona com inglês ("en") e francês ("fr"), o layout na pasta "Content/Localization/" ficará assim:

	{TargetName}/
	{TargetName}.manifest
	{TargetName}.locmeta
	en/
		{TargetName}.archive
		{TargetName}.po
		{TargetName}.locres
	fr/
		{TargetName}.archive
		{TargetName}.po
		{TargetName}.locres

Todos os arquivos e pastas acima são gerados pelas diversas partes do pipeline de localização.

Pasta Descrição
{TargetName}.manifest

  • Manifestos são arquivos JSON personalizados que armazenam todo o texto coletado do código-fonte e dos ativos pelo pipeline de localização.

  • Os manifestos são gerados novamente sempre que a etapa de coleta de localização é executada e não devem ser editados manualmente.
{TargetName}.archive

  • Arquivos são arquivos JSON personalizados que armazenam traduções por cultura para o texto reunido no manifesto.

  • Os arquivos são cortados sempre que as etapas de coleta ou importação de localização são executadas para remover entradas de fontes antigas.

  • Os arquivos podem ser editados manualmente, mas sugerimos que você não faça isso. O fluxo de trabalho recomendado é editar os arquivos PO exportados e reimportá-los.
{TargetName}.po

  • Os arquivos de (objetos portáteis](https://www.gnu.org/ software/gettext/manual/html_node/PO-Files.html)) PO contêm o texto por cultura a ser traduzido, junto com as traduções atuais.

  • Arquivos PO são gerados pela etapa de localização de exportação de texto e reimportados para os arquivos pela etapa de localização de importação de texto.

  • PO é um formato comum e pode ser editado local e manualmente ou por meio de uma ferramenta de tradução como o Poedit ou de forma colaborativa por meio de algo como OneSky ou XLOC.
{TargetName}.locres

  • LocRes são arquivos binário personalizados que armazenam as traduções compiladas por cultura para uso em tempo de execução.

  • Os arquivos LocRes são gerados novamente sempre que a etapa de compilar da localização é executada e são organizados em uma compilação empacotada.

  • LocRes são os únicos arquivos dos quais seu projeto carregará dados de localização em tempo de execução (inclusive no editor). Portanto, qualquer edição ou alteração nos dados de origem (como a importação de um arquivo PO) deve ser compilada antes de entrar em efeito.
{TargetName}.locmeta

  • LocMeta são arquivos binários personalizados que armazenam os metadados do destino compilados (atualmente apenas a cultura nativa do destino) para uso em tempo de execução.

  • Os arquivos LocMeta são gerados novamente sempre que os dados de localização são compilados e são organizados em uma compilação empacotada.

Destinos de localização também especificam uma cultura "nativa", que deve ser configurada para a cultura em que você cria o conteúdo (geralmente chamada de "texto-fonte" ou "dado de origem").

As culturas nativas podem conter "traduções" como qualquer outra cultura, embora as traduções de culturas nativas existam apenas para facilitar a edição do texto sem editar o código-fonte ou os ativos diretamente.

As culturas externas usam o texto de cultura nativa como o texto de origem para tradução e se tornarão "obsoletas" se o texto de cultura nativa for alterado (há uma configuração na etapa de compilação da localização que permite traduções obsoletas, se necessário).

Para obter mais informações sobre como otimizar o pipeline de localização, consulte Otimização do pipeline.

Formato de arquivo PO

A Unreal usa o seguinte formato padrão para seus arquivos PO, dependendo do modo de recolhimento usado na exportação PO.

  • Ao usar o modo de recolhimento Identical Text Identity and Source Text:
    • "msgctxt" contém a identidade Unreal da entrada.
    • "msgid" contém a string de origem.
    • "msgstr" contém a tradução.
  • Ao usar o modo de recolhimento Identical Namespace and Source Text:
    • "msgctxt" contém o namespace da entrada na Unreal.
    • "msgid" contém a string de origem.
    • "msgstr" contém a tradução.

Também temos um formato alternativo que produz melhores resultados se você estiver usando o Crowdin para gerenciar suas traduções. No entanto, observe que esse formato não é capaz de detectar traduções obsoletas importadas de arquivos PO (já que não temos mais o arquivo original a partir do qual foi feita a tradução).

Este modo produz a mesma saída ao usar o modo de recolhimento Identical Namespace and Source Text. No entanto, para o modo Identical Text Identity e Source Text, ele produz o seguinte:

  • "msgctxt" não é usado.
  • "msgid" contém a identidade Unreal da inscrição.
  • "msgstr" contém a string de origem (para a cultura nativa) ou a tradução (para culturas externas).
  • O atributo de cabeçalho "X-Crowdin-SourceKey" especifica que "msgstr" é usado como texto de origem da cultura nativa.

Como compactar dados de localização

Para compactar os dados corretos de localização e internacionalização do projeto, é necessário ajustar algumas configurações na seção avançada Packaging das Project Settings.

As duas configurações que você quer verificar são:

  • Localizations to Package - Com essa opção, você pode escolher em quais culturas deseja organizar os dados de localização. Você pode usar a opção Show Localized para filtrar a lista e mostrar apenas culturas para as quais você tem arquivos "LocRes".

  • Internacionalization Support - Com essa opção, você pode escolher qual conjunto de dados de internacionalização do ICU deseja organizar. Essa opção deve ter sobreposição com os dados de localização que você pretende preparar.

Ask questions and help your peers Developer Forums

Write your own tutorials or read those from others Learning Library

On this page