O WPML pode ler um ficheiro de configuração que lhe diz o que precisa de tradução em temas e plugins. O ficheiro é nomeado wpml-config.xml e é colocado na pasta raiz do plugin ou tema.
Conteúdo
- O objectivo do ficheiro de configuração linguística
- Gerar automaticamente o ficheiro wpml-config.xml
- Estrutura e Sintaxe
- Utilização de ficheiro de configuração em linguagem WPML com temas infantis
Finalidade
Como parte de conseguir compatibilidade com WPML, deverá também criar um ficheiro de configuração que o ajudará a manter a compatibilidade nos seus futuros lançamentos. WPML pode traduzir qualquer coisa no seu sítio WordPress, mas precisa de lhe dizer o que precisa de tradução. Este ficheiro faz isso.
Ir para a página WPML → Configurações.
Esta página diz à WPML tudo o que precisa de saber, incluindo que campos personalizados para traduzir ou sincronizar, que postagem personalizada e taxonomias devem ser multilingues e até que textos administrativos para traduzir.
O ficheiro de configuração da língua inclui esta informação para que cada utilizador não precise de a introduzir manualmente na página de administração.
Para alguns dos temas e plugins, estamos a alojar os ficheiros de configuração linguística nos nossos servidores. Pode ver uma lista aqui. Está definido para substituir o ficheiro de configuração do idioma local que é colocado dentro da pasta raiz do tema ou plugin.
WPML também lhe permite anular manualmente quaisquer configurações carregadas por temas e ficheiros de configuração de linguagem de plugin. Isto aplica-se tanto aos ficheiros de configuração linguística dentro da pasta raiz do tema ou plugin como aos ficheiros de configuração linguística alojados nos nossos servidores.
Gerar automaticamente o ficheiro wpml-config.xml
Se não estiver familiarizado com a criação de ficheiros XML, a nossa equipa criou o plugin Ferramentas Multilingues que facilita esta tarefa. Embora tenha sido inicialmente concebido como uma ferramenta para ajudar os autores de temas e plugins a preparar os seus produtos multilingues, pode ser facilmente utilizado para gerar o seu próprio ficheiro wpml-config.xml .
Para saber mais sobre como gerar o seu ficheiro wpml-config.xml, visite a página do plugin Ferramentas Multilingues. Especificamente, veja na secção Como gerar ficheiros de configuração linguística usando Ferramentas Multilingues?
Uma vez que tenha o ficheiro de configuração, adicione-o à raiz da pasta do seu tema. Se já tiver um, não o sobreescreva. Em vez disso, edite o seu ficheiro XML original e adicione o código gerado com o plugin Ferramentas Multilingues.
Note-se que este plugin não se destina a ser utilizado nos locais de produção ao vivo.
Para ler este tutorial e construir ficheiros de configuração de linguagem para os seus temas e plugins, pode começar com este exemplo –
wpml-config.zip
.
Precisará de o editar, mas pode utilizar as secções e a estrutura deste ficheiro.
Estrutura e Sintaxe
O conteúdo do ficheiro wpml-config.xml tem de ser embrulhado nestas etiquetas
<wpml-config>
e
</wpml-config>
Actualmente, é possível configurar os seguintes dados e definições de tradução neste ficheiro de configuração:
- Conteúdo do construtor da página
- Campos personalizados
- Termos personalizados
- Tipos personalizados
- Taxonomias personalizadas
- Blocos de Gutenberg
- Textos de administração / wp_options
- Configuração do comutador de idiomas
1. Códigos curtos e conteúdo do construtor de páginas
WPML permite-lhe utilizar o ficheiro wpml-config.xml para definir os atalhos que precisam de ser adicionados à tradução de conteúdos.
Nos exemplos abaixo, mostramos-lhe como registar os atalhos do construtor de páginas. Pode utilizar a mesma estrutura de códigos para registar todos os tipos de atalhos para tradução.
1.1 Traduzir cordas
Vamos considerar um exemplo em que se adiciona um separador de texto a uma página usando o Visual Composer. Esse separador tem um título, e o seu código de atalho parece-se com isto:
[vc_text_separator title="Separator Title"]
Para traduzir o título deste separador de texto, precisamos de adicionar algumas linhas ao nosso ficheiro wpml-config.xml. Desta forma, a WPML “saberá” que o título desse separador precisa de ser traduzido. Na realidade, isto segue a mesma lógica que a utilizada para os tipos de correio personalizados, campos personalizados, e outros.
O seguinte código é um exemplo do que precisamos de adicionar ao ficheiro wpml-config.xml neste caso.
Passemos em revista a estrutura do exemplo acima:
- Comece com a etiqueta dos atalhos. Quaisquer atalhos no seu sítio que precisem de ser traduzidos devem ser colocados sob esta etiqueta.
- Depois utilizar a etiqueta de atalho para embrulhar todas as etiquetas pertencentes a um único código de atalho.
- A etiqueta chamada tag é utilizada para definir o nome do código de atalho. Neste caso, é o vc_text_separator. Pode adicionar etiquetas personalizadas opcionais para mostrar tanto no Editor de Tradução Avançado como no Editor de Tradução Clássico. Estas etiquetas estão também incluídas quando se exportam para ficheiros XLIFF. Ver o exemplo abaixo em etiquetas de identificação e atributos.
- Os códigos curtos podem ter um ou mais atributos, pelo que os envolvemos na etiqueta de atributos (plural) e utilizamos a etiqueta de atributos (singular) para definir o título de cada atributo.
Os construtores de páginas incluem (por vezes) elementos de design que têm atributos de ligação.
Pode fazer links internos apontar automaticamente para a versão traduzida desse post usando a opção wpml-config.xml file new shortcode link: type=”link”.
Pode utilizar o atributo de codificação com este. Trata da codificação especial que vários construtores de páginas utilizam. O atributo de codificação é geralmente específico do construtor de páginas utilizado. Aceita os seguintes valores:
- base64 – Visual Composer raw HTML shortcode. O HTML é armazenado como um fio base64 no código de atalho.
- vc_link – formatação de link especial para Visual Composer.
- av_link – Formatação de link especial para Enfold.
- allow_html_tags – Normalmente as tags HTML são retiradas dos atributos do código de atalho. Definir codificação para permitir_html_tags se o atributo de atalho deve permitir tags HTML. Isto deve ser usado com precaução, uma vez que permitir etiquetas HTML em algumas situações pode estragar a formatação e pode ser uma questão de segurança
Se estiver a pensar em utilizar atalhos não codificados, certifique-se de ler a página sobre Tradução de atalhos não codificados.
A adição de etiquetas à etiqueta e atributos permite a exibição de etiquetas personalizadas no Editor de Tradução Avançado ou no Editor de Tradução Clássico. Isto pode ajudar o tradutor a compreender melhor o contexto da corda.
1.2 Traduzir media
Pode usar a WPML Media Translation para traduzir imagens no conteúdo do construtor de páginas. Isto é feito através da conversão de IDs de imagem e URLs de imagem. É necessário dizer ao construtor da página que utiliza atalhos como fazer esta conversão. O seguinte código é um exemplo do que precisamos de adicionar ao ficheiro wpml-config.xml neste caso.
Pode utilizar os seguintes valores:
- conteúdo de ignorância – Pode ser usado dentro de um elemento de etiqueta. Este valor é opcional e pode ser 0 ou 1. Pode utilizar este atributo para obter compatibilidade retroactiva para novos atalhos de meios. Se o valor for definido para 1 , o conteúdo do atalho não será processado.
- tipo – Pode ser usado dentro de um elemento de etiqueta. Também pode utilizar o conteúdo de atalho que contém o URL dos meios de comunicação como valor opcional dentro do media-url.
- tipo – também pode ser utilizado dentro de um elemento de atributo. Neste caso, pode ter um dos seguintes valores opcionais:
- media-ids – uma lista separada por vírgulas dos IDs dos meios de comunicação social.
- media-url – URL dos meios de comunicação
- link – aponta para outra página do site e a WPML irá convertê-la automaticamente para o URL da tradução da página
1.3 Traduzir widgets do construtor de páginas
A partir do WPML 4.4.4, pode agora registar widgets do construtor de páginas dentro do seu ficheiro de configuração linguística. Consulte por favor a nossa página de documentação sobre como registar widgets de construção de páginas para tradução.
1.4 Conversão automática de IDs de códigos de atalho
A partir do WPML 4.5.9, pode declarar as IDs dos postos ou termos de taxonomia localizados em atributos de atalho. Estas identificações podem então ser convertidas automaticamente no front-end do seu site.
Por exemplo, ao considerar o seguinte código de atalho:
[foo_product_list product_ids="12,34,56"]
Podemos declarar que o atributo product_ids possui IDs de correio com a seguinte configuração:
<código de atalho>
<tag ignore-content="1">foo_product_list</tag>
<atributos>
<attribute type="post-ids" subtype="product">product</attribute>
</atributos>
</código de hora>
No front-end, o código de atalho será automaticamente convertido em:
[foo_product_list product_ids="13,35,57"]
Pode utilizar os seguintes atributos de configuração:
- tipo – quer pós-ideias ou taxonomia-ideias
- subtipo (opcional) – pode ser a entidade específica do tipo, se já for conhecida. Por exemplo, produto para o tipo de correio personalizado do Produto. Se não estiver definida, a entidade específica será adivinhada.
A conversão de ID é versátil e tenta adaptar-se à maioria dos formatos possíveis de IDs (ID único, lista de IDs, matriz seriada, matriz codificada JSON).
2. Campos personalizados
O nome de campo personalizado precisa de ser fornecido e também a acção que se espera que a WPML tome: traduzir, copiar, copiar, copiar, ignorar.
Este bloco terá de ser aninhado sob a tag <wpml-config>.
Pode definir as seguintes opções de tradução para campos personalizados:
- traduzir: permite ao seu utilizador traduzir o valor do campo personalizado. Estes campos são exibidos no ecrã do Editor de Tradução e podem ser enviados para qualquer um dos serviços de tradução profissional.
- cópia: esta acção copia o valor do campo personalizado da língua padrão para as línguas secundárias. Isto significa que a actualização do valor do campo personalizado da língua padrão será sempre copiada para a língua secundária. Os campos personalizados definidos para copiar não aparecem no ecrã do Editor de Tradução.
- copy-once: O valor do campo personalizado é copiado para a língua secundária no processo de tradução inicial. Os campos personalizados que utilizam a acção de copy-once não aparecerão no ecrã do Editor de Tradução. No entanto, o utilizador pode alterar o valor do campo personalizado do idioma secundário para ser diferente do idioma predefinido, utilizando o ecrã de pós-processamento. É preferível definir os campos personalizados que contêm definições como cor de fundo, cor da fonte, tamanho da fonte, e outras, para copiar. Isto permite que o utilizador tenha definições diferentes para o conteúdo traduzido do que as definidas para os posts e páginas na língua predefinida. Por exemplo, o utilizador quer que a cor de fundo do mesmo elemento seja amarelo na língua padrão e azul na língua secundária. É favor notar que a edição de um conjunto de campos para copiar não marcará o campo como necessidade de actualização. Isto porque o campo não será copiado para uma tradução existente, só é copiado quando a tradução é criada.
- ignorar: esta acção elimina o campo personalizado de ser copiado para a língua secundária.
Pode adicionar atributos às etiquetas personalizadas> do campo<. Estes atributos personalizam os textos de instrução no Editor de Tradução Avançada ou no Editor de Tradução Clássica.
- pode ser linha, área de texto ou visual, para exibir uma única linha, área de texto, ou WYSIWYG respectivamente.
- é exibido ao lado do campo.
- grupo especifica se o campo personalizado pertence a um grupo e qual deve ser a etiqueta do grupo. Quando um campo se encontra num grupo:
* o campo é removido da secção de campo personalizada
* o campo é adicionado à secção de um grupo relacionado
Pode também adicionar atributos de codificação opcionais para alterar a codificação a partir do valor por defeito(sem codificação). O atributo de codificação aceita os seguintes valores:
- json
- base64
- urlencode
O atributo permite a utilização de codificação múltipla. Nesse caso, os valores têm de ser separados com uma vírgula, por exemplo encoding="json,base64".
Quando este conteúdo wpml-config.xml é utilizado, estes campos personalizados são exibidos no Editor de Tradução Avançado ou no Editor de Tradução Clássico, como se mostra na imagem seguinte.
Etiquetas de campo personalizadas no Editor de Tradução Avançado
Etiquetas de campo personalizadas no Editor de Tradução Clássica
2.1 Tradução de subchaves em campos personalizados
WPML traduz por defeito todas as subchaves em campos personalizados. É possível contornar tal comportamento especificando quais as subchaves que devem ser traduzidas.
Também é possível utilizar os wildcards da mesma forma que são utilizados para textos administrativos:
- Corresponder todos os subcampos começando com o título – usando o código:
<key name="title-*" /> - Corresponde a todos os subcampos e é geralmente usado para corresponder a um índice de matriz usando código:
<key name="*" /> - Para obter o código de utilização
[{"title":"First title"},{"title":"Second title"}]
3. Termos personalizados
O nome do termo personalizado deve ser fornecido e também a acção que se espera que a WPML tome: traduzir, copiar, copiar, copiar, ignorar.
Este bloco terá de ser aninhado sob a tag <wpml-config>.
Pode definir as seguintes opções de tradução para campos personalizados:
- traduzir: permite ao seu utilizador traduzir o valor do termo personalizado. Estes termos são exibidos no ecrã do Editor de Tradução e podem ser enviados para qualquer um dos serviços de tradução profissional.
- cópia: esta acção copia o valor do termo personalizado da língua padrão para as línguas secundárias. Isto significa que a actualização do valor do termo personalizado da língua padrão será sempre copiada para a língua secundária. Os termos personalizados definidos para cópia não são mostrados no ecrã do Editor de Tradução.
- copy-once: O valor do termo personalizado é copiado para a língua secundária no processo de tradução inicial. Os termos personalizados que utilizam a acção de copy-once não aparecerão no ecrã do Editor de Tradução. No entanto, o utilizador pode alterar o valor do termo personalizado do idioma secundário para ser diferente do idioma predefinido, utilizando o ecrã de pós edição.
- ignorar: esta acção elimina o termo personalizado de ser copiado para a língua secundária.
4. Tipos personalizados
Os tipos de correio personalizados que a WPML deve traduzir.
Pode adicionar o atributo “exibir como traduzido” à etiqueta para mostrar os tipos de postagem na língua defleta, se não existir tradução.
Pode adicionar o atributo “automático” à etiqueta para excluir um tipo de postagem da tradução automática ao utilizar o modo Traduzir Tudo. Por favor note, se utilizar este atributo, todo o seu ficheiro de configuração linguística só funcionará para as versões WPML 4.5.0 e superiores.
5. Taxonomias personalizadas
As taxonomias personalizadas que o seu plugin possa estar a utilizar e que já estão registadas no WP.
Nota: as taxonomias que não precisam de tradução podem ser simplesmente omitidas desta lista.
Pode adicionar o atributo “exibir como traduzido” à etiqueta para mostrar as taxonomias na língua padrão, se não existir tradução.
6. Blocos de Gutenberg
Com o editor Gutenberg, constrói-se o conteúdo usando blocos.
Pode especificar que partes do seu bloco Gutenberg precisam de ser traduzidas adicionando definições ao wpml-config.xml.
Xpath é utilizado para definir partes do texto que precisam de ser traduzidas.
6.1 Registo de blocos de Gutenberg como traduzíveis
Digamos que temos uma imagem que é mostrada utilizando o seguinte código:
Queremos traduzir os valores dos atributos figcaption e alt desta imagem.
Para o conseguir, o seguinte código tem de ser inserido em wpml-config.xml:
É favor ter em conta que o tipo é core/image e não wp:image uma vez que este é o valor devolvido pelo bloco API.
Pode especificar quais os campos de bloco de Gutenberg que são ligações. A WPML irá então substituir quaisquer ligações com as suas traduções, se estas estiverem disponíveis.
6.2 Tradução dos atributos do bloco
Aqui está um exemplo de um formato para a definição de um bloco editor:
Pode usar o elemento chave da mesma forma que é usado com a configuração Admin texts / wp_options. Isto também significa que pode ter elementos chave dentro dos elementos chave dos pais.
Pode usar o atributo de etiqueta para adicionar etiquetas personalizadas opcionais que aparecem no Editor de Tradução Avançado junto aos elementos do bloco. Quando o atributo da etiqueta faz parte da etiqueta do bloco de gutenberg-block, será utilizado como etiqueta de recurso para elementos do bloco que não tenham uma etiqueta específica definida.
O método de pesquisa de atributos pode ter um de dois valores:
- wildcards (por defeito)
- regex.
Os wildcards podem ser utilizados da mesma forma que são utilizados para textos administrativos. Isto significa que um asterisco(*) pode ser utilizado no atributo do nome. Aqui está um exemplo de um bloco:
Podemos definir o bloco usando um wildcard:
Isto permitir-nos-á traduzir “O título” e “O conteúdo”, uma vez que estes são os únicos atributos que começam com myp.
O regex permite-nos ter uma expressão regular no atributo do nome. Isto pode ser extremamente útil para configurações complexas. Aqui está um exemplo de um bloco:
Podemos estabelecer a definição do bloco com uma expressão regular:
Isto permitir-nos-á traduzir “O título” e “O conteúdo”, uma vez que estes são os únicos atributos que não começam por _.
Alguns plugins de blocos guardam dados numa cadeia JSON codificada com URL dentro do atributo de um bloco. O atributo de codificação permite descodificar a string e registar as suas subchaves para tradução.
Por exemplo, o plugin LazyBlocks armazena o conteúdo do campo repetidor num cordão codificado JSON:
Pode registar o primeiro e último subchave do nome usando a seguinte configuração XML:
6.3 Espaço de Nomes de Bloco
Pode ter uma configuração global para o espaço de nomes do bloco.
Se a configuração do bloco for a mesma para todos os blocos de um namespace, pode ser escrita assim:
6.4 Conversão automática de identificações em blocos
A conversão de ID é versátil e tenta adaptar-se à maioria dos formatos possíveis de IDs (ID único, lista de IDs, matriz seriada, matriz codificada JSON).
Considerando o seguinte bloco:
<!-- wp:foo/form {"ids":[27,28]} -->
<div class="wp-block-foo-form-wrap">
<form class="foo-form" action=""" method="post">
<input type="hidden" name="foo_form_post_ids" value="27,28" />
<input type="submeter" />
</formar>
</div>
<!-- /wp:foo/form -->
Podemos declarar, como IDs de correio, os ids de atributo de bloco e o valor de atributo de tag HTML foo_form_post_ids como abaixo indicado:
<gutenberg-block type="foo/form" translate="0">
<nome chave="ids>
<key name="*" type="post-ids" subtype="post" />
</chave>
<xpath type="post-ids" subtype="post">//*[@name="foo_form_post_ids"]/@value</xpath>
</gutenberg-block>
E o bloco será convertido com a maior prioridade nos dados do filtro render_block_data como abaixo:
<!-- wp:foo/form {"ids":[42,43]} -->
<div class="wp-block-foo-form-wrap">
<form class="foo-form" action=""" method="post">
<input type="hidden" name="foo_form_post_ids" value="42,43" />
<input type="submeter" />
</formar>
</div>
<!-- /wp:foo/form →
Pode utilizar os seguintes atributos de configuração:
- tipo – pode ser pós-ideias ou taxonomia-ideias
- subtipo (opcional): pode ser a entidade específica do tipo, se já for conhecida. Por exemplo, produto para o tipo de correio personalizado do Produto. Se não estiver definida, a entidade específica será adivinhada.
7. Textos de administração / wp_options
Cordas que fazem parte das opções que os plugins ou temas guardam na tabela wp_options.
Quando os temas e plugins utilizam get_option, lêem valores da tabela wp_options. A WPML pode filtrar estas chamadas e fornecer tradução para os valores destas opções.
Isto funciona se o registo wp_option for uma sequência simples mas também quando é uma sequência seriada.
Para traduzir uma única opção, adicionar uma entrada chave em admin-texts. Para traduzir um array serializado, adicione várias chaves sob uma chave, como pode ver em my_plugin_options no exemplo abaixo.
É possível utilizar o wildcard * em sub-chaves como o seguinte caso.
É igual a este código:
Por favor note que o wildcard * NÃO funciona nas chaves dos pais:
8. Configuração do comutador de idiomas
Permite uma configuração específica para o comutador de linguagem WPML incorporado. Também pode ser utilizado para reiniciar a configuração do comutador de língua se tiver sido alterado a partir do backend (a partir dos seus valores iniciais).
Para ver novas alterações, certifique-se de clicar no botão Restaurar predefinido na parte inferior da página WPML → Languages.
Nem todas estas secções têm de estar presentes no ficheiro de configuração, mas apenas as que se aplicam ao seu plugin ou tema.
Utilização de ficheiro de configuração em linguagem WPML com temas infantis
Se estiver a utilizar um tema criança, o ficheiro de configuração da língua do tema pai sobrepõe-se ao que se encontra no tema criança. WPML fornece uma página de configuração que lhe permite facilmente anular isto com qualquer configuração personalizada.
Consideremos um exemplo em que o ficheiro de configuração linguística do tema principal está a definir o tipo de postagem personalizada “Propriedade” para ser traduzível.
Se estiver a utilizar um tema infantil e quiser definir o tipo de post personalizado “Propriedade” para não ser traduzível, navegue para a página WPML → Settings e clique no separador Custom XML Configuration. Use o editor para definir o tipo de postagem personalizada “Propriedade” para não ser traduzível. Basta definir o valor do atributo de tradução para 0 em vez de 1.
As definições no separador Configuração XML Personalizada são prioritizadas em relação às definições no ficheiro de configuração do idioma no tema principal.