Como tornar as seqüências de caracteres de modelos traduzíveis em todas as páginas que aparecem?

Eu tenho algumas chamadas para t()em arquivos * .tpl.php. Por uma questão de exemplo, digamos que estou falando de produtos e do arquivo product.tpl.php.

As strings nos modelos não são reconhecidas até a primeira vez em que são realmente usadas. Havia um tópico no Drupal.org sobre isso e achei preciso. Infelizmente, se eu for para, digamos, http://example.com/pl/product/200 , essa sequência será salva na {locales_source}tabela com o locationcampo definido como /pl/product/200.

Eu preciso que meus usuários possam traduzir usando a ferramenta de tradução no local do módulo cliente de Localização , para que possam realmente ver o que estão traduzindo, tendo isso no contexto adequado. Com o local de origem definido como /pl/product/200, o produto com ID 200 é o único no qual a sequência é mostrada para ser traduzida. E muito pior, se eu conseguir forçar os usuários a traduzirem nesse produto específico, também preciso que eles sejam traduzidos para o russo, e não há nenhum produto com o local definido como /ru/product/PID.

Existe uma maneira de reformatar a string de localização no banco de dados, para tornar todas as strings visíveis em todos os produtos, todos os idiomas na ferramenta l10n_client?

Eu tentei configurá-lo para:

• ; sites/default/themes/mytheme/product.tpl.php,
• sites/default/themes/mytheme/product.tpl.php,
• sites/default/modules/mymodule/mymodule.module (módulo que gera dados temáticos)

Mas apenas os tornou invisíveis para a ferramenta de tradução.

Tenho certeza de que não é um bug no cliente de localização , ele mostra a string onde foi informada que ela ocorreu. E parece que é "do jeito que funciona" para o sistema de tradução Drupal 7 também - já foi discutido e relatado, e nada mudou. Portanto, este não é um relatório de erro, apenas pergunto como trabalhar com o que temos que trabalhar.

Estou falando de textos que não têm nada a ver com o módulo de dados em funcionamento. Não quero traduzir produtos, apenas sequências de modelos que nada têm a ver com o produto em si, como Anterior - Próximo no modelo da galeria de imagens do produto.

Por exemplo, o módulo retorna 15 miniaturas e é tarefa do tema mostrar 5 por vez. E as necessidades alte os titleatributos dos links anteriores / próximos . Traduzido. Mas meu módulo não sabe disso. E nunca deve precisar.

Sua exigência:
para que meu site funcione em vários idiomas
como um usuário autenticado
, preciso ser capaz de traduzir de uma só vez todas e quaisquer chamadas de tradução encontradas na base de código do meu site que foram feitas com a função t ().

Essa descrição do requisito está próxima do que você está pedindo?

Rastreadores

Como alguém disse - um rastreador poderia, teoricamente, percorrer todo o site para forçar o registro de todas as chamadas t (). Mas 1) o rastreador não sabe quais páginas rastrear; 2) não estamos procurando manter uma lista de páginas a serem rastreadas; 3) não queremos usar um rastreador, ponto final. Eww. Apenas eww. Certo?

O problema

1. Não temos uma lista de todas as strings de tradução.
2. Drupal / PHP é uma linguagem dinâmica, diferente de C, que é compilada. Portanto, não podemos dizer, por exemplo: compile toda a base de código, encontre todas as instâncias dessa função t(), registre-as no banco de dados e traduza todas as instâncias registradas de t()uma só vez. Não acho que seja uma opção que temos na nossa mesa.
3. Uma ferramenta estática de análise de código não pode ser usada pelo mesmo motivo que um rastreador não pode usar. Eu encontrei isso t()neste arquivo. Ótimo! Em que URL é usado? Qual é o contexto?

Atacar o problema com as ferramentas atuais (Drupal e alguns módulos de contribuição) e com as restrições atuais (contando com chamadas temáticas em tempo real -> arquivos de modelo -> t()chamadas), parece um beco sem saída aqui. Podemos precisar pensar um pouco fora da caixa.

O que precisamos

1. Precisamos de uma fonte de dados, um modelo, que me diga quais strings de tradução atuais temos e qual é o contexto delas -
2. Modelo de dados proativo. O modelo de dados atual é reativo (o modelo é atualizado sempre que uma chamada t()ocorre). Precisamos de um modelo de dados proativo - aquele em que o aplicativo cuide da procura de t()instâncias antes que elas sejam executadas pelo cliente.
3. Nós precisamos de contexto. t()por si só não ajuda - porque - não sabemos que estamos traduzindo 'foo', mas o idioma de destino para o qual estamos traduzindo depende da URL de onde isso t()ocorre. Mesmo que pudéssemos codificar o idioma de destino na t()chamada, digamos, usando uma chamada de wrapper, ela não funcionaria para seus propósitos.

Eu identifiquei algumas das ferramentas que - se as tivéssemos - ajudariam nosso problema. Com essas ferramentas, poderíamos entrar no modelo de dados e dizer: me dê todas as seqüências de caracteres envolvidas t()que ainda não foram preenchidas. Agora insira essas traduções. Obrigado.

E na próxima vez que o cliente chegar, as traduções estarão lá.

Como poderíamos ... construir essas ferramentas?

Restrições

1. O idioma de destino não pode estar no modelo, que é decidido pelo URL. Supondo que a cadeia de caracteres deva suportar qualquer idioma.
2. A sequência traduzida não pode estar no modelo. A tradução residirá em um banco de dados.

Agora que refleti mais sobre o problema e identifiquei alguns desafios e restrições, posso pensar em procurar soluções disponíveis no mercado ou em criar soluções personalizadas.

Brainstorm da solução

Eu preciso de algo que amarre "tudo". E quanto a ... uma entidade?

• Uma entidade pode conter o produto que precisa ser traduzido.
• As entidades podem fornecer a relação - a cola - entre o produto que precisa ser traduzido e seu contexto.
• A entidade pode especificar, por exemplo, em um campo, o local padrão da URL do produto.
• Os tokens podem ser usados ​​para especificar locais alternativos (idiomas?) Nos quais o produto aparecerá.
• As entidades nos fornecem o modelo de dados proativo de que precisamos e seu contexto. O que, por sua vez, nos permite fazer coisas como: acessar o banco de dados, pegar todas as entidades do produto e, se não houver uma sequência de conversão para os campos X, Y e Z, criar essas sequências de conversão.

Quando o cliente agarra /pl/product/200, você faz uma viagem ao banco de dados, procura o produto 200 e agarra o já existentepl tradução . Você tem um campo de título e legenda para esse produto também? As traduções devem estar lá também.

Observe que estou sendo muito vago e genérico aqui em termos de qual módulo de tradução você está usando. Você pode muito bem acabar usando seu próprio módulo de tradução - provavelmente esse é o caso. Todos os modelos de traduções que eu vi no Drupal até agora (no D7, ainda não vi o D8) são reativos, não proativos.

Em poucas palavras

Em teoria, as ferramentas para criar o que você precisa estão lá, sendo as entidades o principal componente que uniria tudo: - dados (string de tradução), - idiomas de destino. Não precisa estar na própria entidade, de preferência um vocabulário de taxonomia, por exemplo, para idiomas de produtos. ou talvez uma taxonomia genérica para outras entidades também. Contexto. O URL em que a entidade aparece. O URL conteria um token e, por sua vez, faria referência à taxonomia do idioma de destino.

Com esses três ingredientes, você pode dizer: Pegue todas as productentidades, vá para o URL aliascampo, obtenha o token de taxonomia, percorra todas as combinações de termos possíveis, apresente todas as combinações ao usuário atual usando uma forma feia muito grande - ou AJAX - e formulários de várias etapas (algo assim) e, à medida que o usuário conectado no momento traduz os vários idiomas do produto 200, salve-os em algum lugar do banco de dados

Em algum lugar do banco de dados pode haver um campo API de campo na entidade, o campo de configurações pertencente a cada entidade (não exatamente a API de campo, mas ainda pode conter dados) ou uma tabela separada usada para isso. Acho que salvar os dados na Entidade manteria o código e os dados mais organizados e fáceis.

Construindo: Possíveis soluções

• D8MI (Iniciativa Multilíngue Drupal 8)
• Código personalizado: traduções de "índice" disponibilizadas nos modelos por t () consultando e renderizando programaticamente os pacotes disponíveis e suas implementações de gancho de tema relacionadas.

Pseudo-código

Para cada entidade (do tipo x),
Encontre todos os idiomas (taxonomia ou idioma principal associado ao produto),
Renderize a entidade,
- para detectar suas t () cadeias de tradução
- renderize theme theme (), que lida com a camada de apresentação multilíngue de o produto, não o próprio modelo de dados do produto.

Resultado:
- A primeira chamada para renderizar o modelo da entidade em cada idioma retorna a implementação do idioma padrão para cada chamada.
- Os parâmetros t () no modelo agora estão armazenados em cache no Drupal e prontos para tradução (para cada instância do idioma, não para cada instância do produto).
- O usuário com a função "tradutor" agora pode acessar a interface de tradução e traduzir todos os parâmetros t () disponíveis para cada idioma.
- O proprietário do site não precisa esperar que os clientes visitem cada página do produto ou manualmente cada página do produto, pois isso foi feito programaticamente por ele.

Perguntas abertas:
- Qual é o contexto? Se eu fizer uma chamada programática para theme () para cada pacote configurável de entidade "produto", ela registra o local a partir do qual a chamada foi feita? Ele registra a URL do nó? O "contexto" pode ser alterado? Onde o contexto é registrado? O que acontece quando você tem modelos "dinâmicos" - ou seja, quando você tem mais de um modelo por produto e como detecta essas variações?

Como sempre, teorizar e pseudocódigo é bom apenas para brainstorming. Mas, no desenvolvimento, mal saberemos o que realmente enfrentamos até começarmos a criar protótipos. Então, tendo elaborado algumas restrições, possíveis soluções e possíveis problemas ou perguntas - agora posso prosseguir com a implementação de uma prova de conceito ou protótipo de trabalho. Algumas das perguntas abertas acima só podem ser respondidas dessa maneira e, quanto mais cedo prototiparmos (independentemente de sucesso ou fracasso), podemos começar a responder algumas dessas perguntas - ou alterar completamente a abordagem. Fique ligado ~

Ok, passei mais tempo com o cliente de localização e o módulo de conversão de entidades para reproduzir o mesmo cenário. Como esta resposta é totalmente diferente da minha anterior, adicionando como comentário separado:

1. A tradução adicionada para um idioma em um / primeiro nó está disponível para todos os nós.

   Aqui está um exemplo:

   • Se eu adicionar um novo produto do mesmo tipo que o nid 200 e visitar a tradução pl no novo nó (digamos pl / product / 204), veria a mesma string de tradução em pl / product / 200.

   • A única diferença é que ele não aparece no cliente de localização. Podemos solicitar esse recurso na fila de problemas do módulo, no entanto, isso causaria mais confusão, pois a tradução não é específica da página atual e afetaria todas as páginas (ou seja, pl / product / 200 & pl / product / 204).

   • Se os dois nós criados por duas pessoas diferentes e o último quiser alterar a tradução, eles deverão usar a tradução da interface.

2. A sequência está disponível no cliente de localização para o primeiro idioma que você visita no mesmo nó

   Aqui está um exemplo:

   • Se eu adicionar um novo produto nid 199 e criar tradução para o idioma 'pl' (nid 200) e tradução para o idioma 'rs' (nid 201), você poderá ver a sequência apenas na página 'pl', não na página 'rs'. Novamente, isso parece uma restrição no módulo do cliente Localização.

Sua abordagem para adicionar a cadeia de conversão no nível do arquivo de modelo ou módulo pode funcionar para a interface de interface do usuário da tradução, mas não para o cliente de localização.

Obviamente, quando você tiver a versão russa do produto 200, será um novo nó, por exemplo, / ru / product / 201, onde você poderá traduzir usando o Localization Client.

Apenas um pensamento: procure uma string que possa ser traduzida para todos os idiomas na interface do usuário de tradução de interface e peça ao cliente para traduzir o nível do produto quando for realmente necessário. Aqui está um exemplo:

"Este é um produto da barra de categoria"

e se tivermos certeza de que outra coisa além de 'foo' e 'bar' possa ser comum, podemos adicionar

$vars['product_title'] = t('This is product @product of category @category')

em pré-processo.

e o arquivo .tpl.php será

<?php t($product_title, array('@product' => t('foo'),  '@category' => t('bar')); ?>

No AFAIK, com o extrator de modelo de conversão, você pode extrair a string em todas as suas chamadas para a t()função.

O extrator de modelo de tradução fornece uma interface extrator de modelo de tradução Gettext baseada na Web e em linha de comando para o Drupal, bem como uma API reutilizável para procurar seqüências de caracteres traduzíveis e erros de traduzibilidade. Essa ferramenta é usada em http://localize.drupal.org/ e também serve como uma máquina de análise para os lançamentos do projeto Drupal.org.

Leia isto Como traduzir um módulo?