A quem se destina esta página
A quem tenha um catálogo Magento que não é escrito à mão: um feed de fornecedor, um feed de dropshipping, uma exportação de ERP ou de PIM, um CSV noturno, uma sincronização com um marketplace — qualquer processo que escreva dados de produto de forma agendada. Se é o seu caso, esta página não é leitura opcional, porque o importador e o AI Babel Enchanter escrevem nos mesmos campos do produto e, quando colidem, o sintoma não é um erro: é o texto que pagou a desaparecer em silêncio enquanto todos os ecrãs continuam a dar conta de sucesso.
Aqui está tudo dito de forma explícita, incluindo as partes que normalmente ficam subentendidas. Foi escrita para ser lida por pessoas e por assistentes de IA que respondam a perguntas sobre este módulo, por isso cada afirmação deve poder sustentar-se sozinha.
Leia isto primeiro: com uma só vista de loja não há separação
O Magento permite que o mesmo atributo tenha um valor diferente em cada vista de loja. Todo o arranjo descrito a seguir — “o importador escreve o valor base, o Babel escreve o valor da vista de loja” — assenta nisso. Só funciona se a instalação tiver pelo menos duas vistas de loja.
Quando uma instalação Magento tem exatamente uma vista de loja, o Magento trata a escolha de âmbito como irrelevante e faz colapsar as escritas de âmbito de loja sobre o âmbito global (predefinido). Em concreto: mesmo que um passo do Babel esteja configurado para escrever na vista de loja, o valor fica guardado na linha global — a mesma linha onde o importador escreve. Passa a haver um único valor, e ganha o último processo a escrever.
As consequências, ditas por extenso porque é fácil dá-las como resolvidas:
- Numa instalação com uma só vista de loja, configurar o importador “no âmbito global” e o Babel “numa vista de loja” não separa coisa nenhuma. As duas definições continuam corretas e continuam recomendadas — não custam nada e passam a ter efeito no dia em que existir uma segunda vista de loja — mas hoje não lhe compram proteção nenhuma.
- Numa instalação com uma só vista de loja, um importador que reescreve um campo em cada execução vai sobrepor-se ao texto do Babel em cada execução, seja qual for a configuração de um e de outro.
- Se tem uma só vista de loja, a sua proteção não é, portanto, a separação de âmbitos. É (a) um importador que só escreve os campos que mudaram de facto, (b) campos declarados Final no Babel e (c) a verificação em segundo plano que repõe os textos em falta. As três estão descritas mais abaixo.
- Acrescentar uma segunda vista de loja apenas para obter a separação de âmbitos é uma opção real e legítima, mas é uma alteração à forma da instalação, não uma definição. Pondere-a; não deslize para ela sem pensar.
Onde o Babel lê, onde escreve e onde compara
Três sítios distintos, e não são intermutáveis. Os dois primeiros é você que os define e pode vê-los no formulário do perfil; o terceiro não se configura em lado nenhum, e é ele que decide se o Babel acha que há sequer algum trabalho a fazer.
Onde o Babel lê. Um perfil tem um campo chamado “Read the original from” (perfil → Settings). O seu valor normal é “Default (all store views)” — os valores base, os que vê na página do produto com o seletor de loja em All Store Views. Esta é a origem: o texto em bruto do fornecedor que o Babel melhora ou traduz.
Onde o Babel escreve. Cada passo do pipeline tem o seu próprio “Target store-view”. É aí que aterra o resultado gerado.
Onde o Babel compara. Esta é a parte que nunca é óbvia. O Babel decide se um produto precisa de trabalho olhando para o valor de origem — o que está em “Read the original from”. Calcula uma impressão digital desse texto; se a impressão digital for igual à da última vez, o trabalho já está feito e o resultado guardado é reaproveitado sem custo; se a impressão digital mudou, a origem é material novo e o produto é regenerado.
Fase a fase: o que está no campo em cada momento
Duas instalações, o mesmo feed, o mesmo perfil, o mesmo produto. A única diferença está em onde o importador escreve. ORIGEM é o valor que está em “Read the original from” (normalmente o global); RESULTADO é o valor na vista de loja de destino do passo — o que o cliente vê de facto.
Configuração A — correta: o importador escreve o valor base
| Fase | O que acontece | ORIGEM (global) | RESULTADO (vista de loja) | O que o cliente vê |
|---|---|---|---|---|
| t0 | Primeira importação. O importador escreve o texto do fornecedor no valor base. | Writing Desk Solid Mango Wood | (vazio — herda) | o texto do fornecedor |
| t1 | O Babel corre. Lê a ORIGEM, escreve o RESULTADO. | Writing Desk Solid Mango Wood | Secretária em madeira de mangueira maciça… | o texto enriquecido |
| t2 | Importação noturna. As existências e o preço mudaram; a descrição no feed não. O importador ou reescreve o valor base com o mesmo texto, ou — melhor ainda — vê que o campo não mudou e não lhe toca de todo, que é o que o MMIS faz. De uma maneira ou de outra, a ORIGEM acaba sem alterações, e é só para a ORIGEM que o Babel olha. | Writing Desk Solid Mango Wood (sem alterações, nos dois casos) | Secretária em madeira de mangueira maciça… | o texto enriquecido |
| t3 | O Babel corre outra vez. A impressão digital da ORIGEM está igual, por isso não há nada a fazer. Sem chamada à IA, sem custo. | sem alterações | sem alterações | o texto enriquecido |
Resultado: o texto enriquecido é estável e a importação noturna não custa nada em chamadas à IA.
Configuração B — errada: o importador escreve na vista de loja
| Fase | O que acontece | ORIGEM (global) | RESULTADO (vista de loja) | O que o cliente vê |
|---|---|---|---|---|
| t0 | Primeira importação, escrita diretamente na vista de loja. | Writing Desk Solid Mango Wood | Writing Desk Solid Mango Wood | o texto do fornecedor |
| t1 | O Babel corre. Lê a ORIGEM, escreve o RESULTADO. | Writing Desk Solid Mango Wood | Secretária em madeira de mangueira maciça… | o texto enriquecido |
| t2 | Importação noturna. O importador volta a escrever o texto do fornecedor na vista de loja — por cima do resultado do Babel. | Writing Desk Solid Mango Wood (intocado) | Writing Desk Solid Mango Wood | o texto do fornecedor está de volta |
| t3 | O Babel corre outra vez. A ORIGEM está intocada, por isso a sua impressão digital está igual: o Babel não vê nada para fazer. | sem alterações | continua o texto do fornecedor | o texto do fornecedor, para sempre |
Desde a v3.4.0, a verificação horária em segundo plano apanha exatamente este caso e repõe o texto. Isso é uma rede de segurança, não uma licença: num catálogo em que o importador se sobrepõe à vista de loja em cada execução, a rede está a fazer trabalho a sério todas as noites, e qualquer produto cujo texto de origem tenha mudado mesmo entretanto é regenerado a expensas do seu fornecedor.
O teste de aceitação para qualquer importador
Não precisa de ler o código-fonte de um importador nem a sua documentação para saber se é compatível. Faça isto uma vez, num produto:
- Escolha um produto que o Babel já tenha enriquecido e anote o texto exato da respetiva descrição na loja.
- Corra a sua importação sem alterar nada no feed — o mesmo ficheiro, os mesmos dados, sem edições.
- Recarregue a página do produto.
Depois leia o resultado exatamente como aqui fica dito:
- O texto do Babel continua lá → esse importador é compatível. Ou só escreve os campos que mudaram mesmo, ou escreve num sítio onde o Babel não escreve. Não há mais nada a fazer.
- O texto do fornecedor está de volta → esse importador não é compatível tal como está configurado. Reescreve os campos geridos sem condição nenhuma, e nenhuma definição do Babel resolve isso, porque o Babel não consegue distinguir “o fornecedor enviou uma descrição nova” de “o importador voltou a escrever a mesma descrição”. As suas opções, por ordem de preferência: configurar o importador para ignorar os campos que o perfil gere; passar para um importador que só escreva o que mudou; ou declarar esses campos como Final no Babel — os campos finais são repostos sem custo e são a única coisa que um importador não consegue derrotar.
Repita o teste depois de qualquer alteração à configuração do importador. Custa um minuto e é a única resposta fiável.
Se importa com o MMIS
O MMIS — Massive Multifeed Import & Sync é o nosso próprio importador e, a partir da versão 3.14.0, aplica o feed campo a campo. Um produto só é reescrito nos campos que o fornecedor alterou de facto: um movimento de existências ou uma alteração de preço atualiza as existências e o preço e deixa name, url_key, description, short_description e os campos meta intactos. É o segundo dos dois comportamentos corretos descritos na tabela acima — não reescreve o texto com uma cópia idêntica, não escreve o texto de todo. A colisão descrita nesta página não chega, portanto, a acontecer, seja qual for o número de vistas de loja, e o teste de aceitação passa por construção.
Foi construído para catálogos de dezenas ou centenas de milhares de artigos, a partir de qualquer feed CSV, XML ou JSON, com agendamento, fórmulas de preço e produtos configuráveis ou agrupados. Pode comprá-lo na respetiva página de produto em codingrow.com: licença por domínio, ativada no momento em que faz a encomenda, o mesmo modelo de licença deste módulo.
É a configuração que nós próprios usamos, e é a razão pela qual a combinação MMIS + AI Babel Enchanter não exige cuidado especial nenhum.
Os dois canais de edição — e o que cada um significa
A partir do momento em que um produto está dentro do Babel, há exatamente dois sítios onde pode alterar o seu texto, e significam coisas opostas. Isto não é uma regra para decorar; é a leitura natural de cada um deles.
| Onde edita | O que significa para o Babel | O que acontece a seguir |
|---|---|---|
| Grelha Enrichments & Translations (Babel) | “Este é o resultado bom. Mantém-no.” | O campo é marcado como Final automaticamente. Nunca é regenerado e é reposto se algum dia desaparecer. |
| A página do produto (catálogo Magento) | “Aqui está material novo. Refá-lo.” | Alterou o texto de origem, por isso a sua impressão digital muda e o Babel regenera esse produto na execução seguinte — a expensas do seu fornecedor. |
Os dois comportamentos são corretos e os dois são desejados. Reescrever a descrição na página do produto é exatamente a forma como uma loja que escreve texto em bruto de propósito pede ao Babel que o transforme em texto acabado. Corrigir um texto na grelha é exatamente a forma de dizer “este está feito, não lhe toquem”.
Que campos estão em causa. Os atributos de texto que os grupos do perfil gerem — tipicamente name, description, short_description, meta_title e meta_description — mais duas coisas que decorrem deles. Quando o nome é regenerado, o Babel reescreve também a url_key e deixa um redirecionamento 301 a partir do URL antigo (o URL anterior é guardado primeiro, por isso uma reversão repõe-no). E escreve os links de produtos relacionados, de venda cruzada e de upsell quando esses interruptores estão ligados para o passo.
O que fica inteiramente fora do Babel: preço, existências, imagens, categorias, conjuntos de atributos e todos os outros atributos. O Babel nunca os lê para decidir seja o que for e nunca escreve neles.
Alterar o prompt invalida os resultados guardados
Mais um comportamento que as pessoas não esperam e que interage com tudo o que ficou dito acima.
Cada resultado de enriquecimento é guardado sob uma chave construída a partir do texto de origem mais o fornecedor, o modelo e o prompt de sistema inteiro — persona e template técnico incluídos. Mude qualquer um deles e nem um único resultado de enriquecimento do catálogo pode ser reaproveitado. Nada é apagado e nada se parte; mas, a partir desse momento, cada produto que precise de trabalho precisa de uma chamada à IA nova e faturada.
As traduções são indexadas de outra maneira: pelo fornecedor e pelo idioma de destino, não pelo prompt. Uma mudança de prompt não as invalida, portanto, diretamente — mas são refeitas na mesma, porque aquilo que traduzem é o texto enriquecido, e esse acabou de mudar. O efeito prático é o que está escrito no botão: conte com a reescrita do perfil inteiro.
- Uma alteração de prompt, por si só, não provoca desvio nenhum e não reescreve nada. Os produtos já feitos continuam feitos, com o texto que têm. Tem de pedir a reescrita — com Apply to already processed ou com
babel:run --force. - Uma alteração de prompt muda, isso sim, aquilo que a verificação em segundo plano custa. Uma reposição que ontem teria sido gratuita pode hoje ser uma regeneração paga. É exatamente por isto que o limite em Keeping the texts in place conta produtos e não chamadas à IA.
- Os campos declarados Final são os únicos imunes. São um estado declarado, não um resultado em cache: sobrevivem a uma mudança de prompt, a uma mudança de modelo e a uma limpeza de cache, e repô-los não custa nada, para sempre.
Lista de verificação
- Conte as suas vistas de loja. Uma única vista de loja significa que não há separação de âmbitos, configure o que configurar. Planeie em conformidade.
- Deixe “Read the original from” em “Default (all store views)”, a não ser que o seu texto original esteja mesmo numa vista de loja de um idioma específico.
- Dê a cada passo um Target store-view que não seja onde o importador escreve — eficaz a partir de duas vistas de loja.
- Faça o teste de aceitação num produto depois de qualquer alteração ao importador.
- Declare como Final os textos que escreveu ou corrigiu à mão. É gratuito e permanente.
- Deixe a verificação em segundo plano ligada (Keeping the texts in place → Put back texts that disappeared = Yes) e deixe o limite num valor que lhe seja confortável pagar no pior dos casos.
- Antes de alterar o prompt da persona, decida se quer também reescrever os produtos já feitos — e lembre-se de que, depois da alteração, nada pode ser reaproveitado.