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
- Não temos uma lista de todas as strings de tradução.
- 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.
- 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
- Precisamos de uma fonte de dados, um modelo, que me diga quais strings de tradução atuais temos e qual é o contexto delas -
- 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.
- 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
- O idioma de destino não pode estar no modelo, que é decidido pelo URL. Supondo que a cadeia de caracteres deva suportar qualquer idioma.
- 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 ~
wgetou o que for. Hackish, mas você disse que isso era permitido (: