Conversão de nó vs. Conversão de entidade (campo)

Gostaria de saber o que vocês recomendam para um site multilíngue. Por exemplo, considere o seguinte caso: Uma página e seu conteúdo devem estar disponíveis em 3 idiomas (por exemplo, alemão, inglês e espanhol); o site usa um tipo de perfil, vários tipos e visualizações de conteúdo, taxonomia, referências de taxonomia, referências de nós, referências de usuário e campo, coleções de campos, menus e assim por diante. Todas essas informações devem ser traduzidas.

Até onde eu sei, existem duas maneiras de obter isso: com a tradução de entidades e o método "baseado em nó", ou o habitual com os módulos de internacionalização e l10n.

Qual o caminho que devo escolher? Nesse caso e por que devo considerar um método em vez do outro?

Randy Fay criou recentemente um post discutindo as possibilidades alcançadas com a Entity Translations, onde Gabor Hojtsy comentou algumas das considerações a considerar:

Algumas coisas boas oferecidas pela tradução de nó [bom e velho] incluem suporte para comentários de nó separados (por exemplo, seus comentários em alemão e inglês não serão misturados); suporte para revisões por idioma; fluxos de trabalho de publicação (por exemplo, o nó alemão pode estar em um fluxo de trabalho de revisão de pré-publicação enquanto o inglês já estiver publicado, ações coordenadas podem publicar versões de vários idiomas quando todas atingirem uma determinada etapa do fluxo de trabalho, etc.); tratamento de permissão diferente (por exemplo, certas pessoas só podem editar traduções em alemão, e não originais em inglês), graças ao excessivo sistema de acesso a nós do Drupal, etc. Pense nos menus. A maioria dos sites não planeja ter estruturas de menu 1-1 para todas as versões traduzidas.

A principal advertência que eu vejo para a tradução em nível de conteúdo / entidade / campo agora se resume ao antigo caso especial do Drupalismo: o título do nó ... Não é realmente um campo, portanto não é traduzível sem outro módulo e potencialmente algum trabalho de patch. A partir de agora, acho que a tradução de campo ainda é um campo muito "experimental", mas há mais poder para você avançar em um novo território.

A apresentação de Suzanne Kennedy e Florian Loretan na DrupalCon Denver abordou essa questão. Parece que a tradução de entidades é o caminho do futuro e, pelo menos em parte, está prevista para integração no núcleo.

A recomendação deles era usar a tradução da entidade, a menos que você precise de suporte para revisão.

Usei a tradução do Nó, mas agora, depois de experimentar a Entity Translation , é definitivamente a minha favorita!

Acho que o principal problema é a função de importação com a tradução de entidades, porque há uma longa discussão na comunidade Drupal. Caso contrário, li sobre um novo módulo, mas ainda não o tentei. Mas depois vou dar o meu feedback!

Se você combinar a Tradução de entidade com o módulo Título , poderá traduzir tudo. Eu também prefiro o módulo " Atualização de localização ".

Então você precisa instalar e ativar estes módulos contribuídos:

• Tradução de entidade .
• Título .
• Atualização de localização .

E você precisa habilitar estes módulos principais:

• Localidade.
• Tradução de conteúdo.

Boa sorte!

Eu sei que estou ressuscitando os mortos aqui, mas:

Pelo que sei, o método de conversão de nós em 6 estilos (cada tradução é um novo nó) ainda é a única maneira útil de traduzir conteúdo, tendo os benefícios de ser o que todos estão acostumados e de serem funcionalmente completos. (Os títulos dos nós não são campos em 7 e, portanto, não podem ser traduzidos em campo, entre outras deficiências tolas.)

Você sempre usará i18n / locale, a única opção (que não é realmente uma opção) é a conversão no nível do nó ou no nível do campo, da qual apenas a conversão do nó provavelmente será útil.

Editar: desde que isso foi escrito, o módulo Entity Translation + Title tornou a tradução em nível de campo muito eficaz. Se você pode usá-los, você deveria.

A tradução de entidades faz muito mais sentido na maioria dos casos do que a tradução de nós; mas infelizmente não é realmente uma opção viável para o D7, pois muitos módulos ainda não o suportam. As pessoas que fazem apresentações e mostram como é ótimo simplesmente estão fazendo um trabalho muito simples. Por exemplo, algo tão comum / popular como coleções de campos ainda não é suportado pelo ET.

Quando começamos um novo site multilíngue, sempre começamos com o ET, pois é uma ótima idéia. Continuamos com ele até encontrarmos muitos problemas com coisas que não são compatíveis. Depois, voltamos ao método D6 antigo.