drupal 7 – ¿Cómo hacer que las cadenas de las plantillas sean traducibles en todas las páginas en las que aparecen?

Pregunta:

Tengo algunas llamadas a t() en archivos * .tpl.php. Por el bien de ejemplo, digamos que estoy hablando de productos y del archivo product.tpl.php.

Las cadenas de las plantillas no se reconocen hasta la primera vez que se utilizan. Había un hilo en Drupal.org sobre eso y lo encontré exacto. Lamentablemente, si voy a, digamos, http://example.com/pl/product/200 , esa cadena se guardará en la tabla {locales_source} con el campo de location establecido en /pl/product/200 .

Necesito que mis usuarios puedan traducir utilizando la herramienta de traducción en el sitio del módulo del cliente de localización , para que puedan ver realmente lo que están traduciendo, en el contexto adecuado. Con la ubicación de origen establecida en /pl/product/200 , el producto con ID 200 es el único en el que se muestra la cadena para traducir. Y lo que es mucho peor, si puedo obligar a los usuarios a traducir en ese producto en particular, también los necesito para poder traducir al ruso, y no hay ningún producto con la ubicación configurada en /ru/product/PID .

¿Hay alguna manera de volver a formatear la cadena de ubicación en la base de datos, para hacer que todas las cadenas sean visibles en todos los productos, todos los idiomas en la herramienta l10n_client?

Intenté configurarlo en:

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

Pero solo los hizo invisibles para la herramienta de traducción.

Estoy bastante seguro de que no es un error en el cliente de localización , muestra la cadena donde se dice que ocurrió esta cadena. Y parece que es "simplemente la forma en que funciona" para el sistema de traducción Drupal 7, también – ya se discutió e informó, y nada cambió. Así que este no es un informe de error, solo pregunto cómo trabajar con lo que tenemos que trabajar.


Me refiero a textos que nada tienen que ver con el módulo de datos en el que opera. No quiero traducir productos, solo cadenas de plantillas que no tienen nada que ver con el producto en sí, como Anterior – Siguiente en la plantilla de la galería de imágenes del producto.

Por ejemplo, el módulo devuelve 15 miniaturas y el trabajo de un tema es mostrar 5 a la vez. Y los enlaces anterior / siguiente necesitan atributos alt y title . Traducido. Pero mi módulo no lo sabe. Y nunca debería necesitarlo.

Respuesta:

Su requerimiento:
Para que mi sitio funcione en varios idiomas
como usuario autenticado
Necesito poder traducir a la vez todas y cada una de las llamadas de traducción encontradas en el código base de mi sitio que se realizaron con la función t ().

¿Esa descripción del requisito se acerca incluso a lo que está pidiendo?


Rastreadores

Como alguien dijo, un rastreador teóricamente podría recorrer todo el sitio para forzar el registro de todas las llamadas t (). Pero 1) el rastreador no sabe qué páginas rastrear; 2) no buscamos mantener una lista de páginas para rastrear, por lo tanto; 3) no queremos usar un rastreador, punto. Eww. Solo, eww. ¿Correcto?


El problema

  1. No tenemos una lista de todas las cadenas de traducción.
  2. Drupal / PHP es un lenguaje dinámico a diferencia de C que está compilado. Entonces no podemos ir y decir, por ejemplo: compile todo este código base, luego búsqueme todas las instancias de esta función t() , luego registre esas instancias en la base de datos, luego traduzca todas esas instancias registradas de t() de una sola vez. No creo que sea una opción que tengamos sobre la mesa.
  3. Una herramienta de análisis de código estático sería indefenso por la misma razón que un rastreador estaría indefenso. Encontré este t() en este archivo. ¡Estupendo! ¿En qué URL se utiliza? Cual es el contexto?

Atacar el problema con las herramientas actuales (Drupal y algunos módulos contrib), y con las restricciones actuales (confiando en llamadas de tema en tiempo real -> archivos de plantilla -> llamadas t() ), parece un callejón sin salida aquí. Es posible que debamos pensar un poco fuera de la caja.


Lo que necesitamos

  1. Necesitamos una fuente de datos, un modelo, que me diga qué cadenas de traducción actuales tenemos y cuál es su contexto.
  2. Modelo de datos proactivo. El modelo de datos actual es reactivo (el modelo se actualiza cada vez que ocurre una llamada a t() ). Necesitamos un modelo de datos proactivo, uno en el que la aplicación se encargue de buscar instancias t() antes de que el cliente las ejecute.
  3. Necesitamos contexto. t() por sí solo no es suficiente, porque no sabemos que estamos traduciendo 'foo', pero el idioma de destino al que estamos traduciendo depende de la URL en la que aparece t() . Incluso si pudiéramos codificar el idioma de destino en la llamada t() , digamos, usando una llamada contenedora, no funcionaría para sus propósitos.

He identificado algunas de las herramientas que, si las tuviéramos, ayudarían con nuestro problema. Con estas herramientas podríamos ir al modelo de datos y decir: dame todas las cadenas envueltas en t() que aún no se hayan poblado. Ahora inserte estas traducciones. Gracias.

Y la próxima vez que venga el cliente, las traducciones estarán allí.

¿Cómo podríamos … construir estas herramientas?


Restricciones

  1. El idioma de destino no puede estar en la plantilla, eso lo decide la URL. Suponiendo que la cadena debe admitir cualquier idioma.
  2. La cadena traducida no puede estar en la plantilla. La traducción residirá en una base de datos.

Ahora que he pensado más en el problema e identificado algunos desafíos y limitaciones, puedo pensar en buscar las soluciones disponibles o en crear soluciones personalizadas.

Lluvia de ideas de soluciones

Necesito algo que vincule "todo". ¿Qué pasa con … una entidad?

  • Una entidad puede tener el producto que necesita ser traducido.
  • Las entidades pueden proporcionar la relación, el pegamento, entre el producto que necesita ser traducido y su contexto.
  • La entidad puede especificar, por ejemplo, en un campo, la ubicación URL predeterminada del producto.
  • Los tokens se pueden usar para especificar ubicaciones alternativas (¿idiomas?) En las que aparecerá el producto.
  • Las entidades nos brindan el modelo de datos proactivo que necesitamos y su contexto. Lo que a su vez nos permite hacer cosas como: ir a la base de datos, tomar todas las entidades del producto y, si no tienen una cadena de traducción para los campos X, Y y Z, crear esas cadenas de traducción.

Cuando el cliente toma /pl/product/200 , usted hace un viaje a la base de datos, busca el producto 200 y toma la traducción pl ya existente. ¿También tiene un campo de título y título para ese producto? Las traducciones también deberían estar allí.

Tenga en cuenta que estoy siendo muy vago y genérico en términos del módulo de traducción que está utilizando. Es muy posible que termine utilizando su propio módulo de traducción; lo más probable es que este sea el caso. Todos los modelos de traducción que he visto en Drupal hasta ahora (a partir de D7, todavía no he mirado a D8) son reactivos, no proactivos.

En una palabra

En teoría, las herramientas para construir lo que necesita están ahí, siendo las entidades el componente clave que uniría todo: – datos (cadena de traducción), – idiomas de destino. No es necesario que esté en la entidad en sí, preferiblemente un vocabulario de taxonomía, por ejemplo, para los lenguajes de productos. o quizás también una taxonomía genérica para otras entidades. – Contexto. La URL en la que aparece la entidad. La URL contendría un token y el token, a su vez, haría referencia a la taxonomía del idioma de destino.

Con esos tres ingredientes, puede decir: tome todas las entidades del product , vaya al campo de URL alias la URL alias , obtenga el token de taxonomía, recorra todas las combinaciones de términos posibles, presente todas las combinaciones al usuario actual utilizando una forma fea muy grande – o, AJAX – y formularios de varios pasos (algo así), y como el usuario actualmente conectado traduce los distintos idiomas para el producto 200, guárdelos en algún lugar de la base de datos

En algún lugar de la base de datos podría haber un campo de API de campo en la entidad, el campo de configuración que pertenece a cada entidad (no exactamente API de campo, pero aún puede contener datos) o una tabla separada que use para esto. Creo que guardar los datos en la Entidad mantendría tanto el código como los datos más ordenados y más fáciles.


Construyéndolo: posibles soluciones

  • D8MI (iniciativa multilingüe de Drupal 8)
  • Código personalizado: traducciones de "índice" disponibles en plantillas por t () al consultar y representar mediante programación los paquetes disponibles y sus implementaciones de enlaces de temas relacionados.

Pseudocódigo

Para cada entidad (de tipo x),
Encuentre todos los idiomas (taxonomía o idioma principal asociado con el producto),
Renderizar la entidad,
– para detectar sus cadenas de traducción t ()
– render calls theme (), que maneja la capa de presentación multilingüe del producto, no el modelo de datos del producto en sí.

Resultado:
– La primera llamada para representar la plantilla de entidad en cada idioma devuelve la implementación de idioma predeterminada para cada llamada.
– Los parámetros t () de la plantilla ahora se almacenan en caché en Drupal y están listos para la traducción (para cada instancia de idioma, no para cada instancia de producto).
– El usuario con función de "traductor" ahora puede ir a la interfaz de traducción y traducir todos los parámetros t () disponibles, para cada idioma.
– El propietario del sitio no necesita esperar a que los clientes visiten cada página de producto o visitar cada página de producto manualmente, ya que esto se hizo mediante programación para él.

Preguntas abiertas:
– Cual es el contexto? Si hago una llamada programática a theme () para cada paquete de entidad de "producto", ¿registra la ubicación desde la que se realizó la llamada? ¿Registra la URL del nodo? ¿Se puede alterar el "contexto"? ¿Dónde se registra el contexto? ¿Qué sucede cuando tiene plantillas "dinámicas", es decir, cuando tiene más de una plantilla por producto y cómo detecta esas variaciones?

Como siempre, la teorización y el pseudocódigo solo sirven para generar ideas. Pero en el desarrollo, difícilmente sabremos a qué nos enfrentamos realmente hasta que comencemos a crear prototipos. Entonces, habiendo elaborado un par de restricciones, posibles soluciones y posibles problemas o preguntas, ahora puedo proceder a implementar una prueba de concepto o un prototipo funcional. Algunas de las preguntas abiertas anteriores solo se pueden responder de esta manera, y lo antes que hagamos el prototipo (independientemente del éxito o el fracaso), podemos comenzar a responder algunas de esas preguntas, o cambiar el enfoque por completo. Estén atentos ~

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım