Su requisito:
para que mi sitio funcione en varios idiomas
como usuario autenticado
, necesito poder traducir de inmediato todas y cada una de las llamadas de traducción encontradas en la base de código de mi sitio que se realizaron con la función t ().
¿Es esa descripción del requisito incluso cercana 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) por lo tanto, no buscamos mantener una lista de páginas para rastrear; 3) no queremos usar un rastreador, punto. Eww. Solo, eww. ¿Derecho?
El problema
- No tenemos una lista de todas las cadenas de traducción.
- Drupal / PHP es un lenguaje dinámico a diferencia de C que se compila. Por lo tanto, no podemos ir y decir, por ejemplo: compilar toda esta base de código, luego encontrarme todas las instancias de esta función
t(), luego registrar esas instancias en la base de datos, luego traducir todas esas instancias registradas de t()una vez. No creo que sea una opción que tengamos en nuestra mesa.
- Una herramienta de análisis de código estático sería inútil por la misma razón que un rastreador sería inútil. Encontré esto
t()en este archivo. ¡Excelente! ¿En qué URL se usa? ¿Cuál 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 -> t()llamadas), parece un callejón sin salida aquí. Es posible que debamos pensar un poco fuera de la caja.
Lo que necesitamos
- Necesitamos una fuente de datos, un modelo, que me diga qué cadenas de traducción actuales tenemos y cuál es su contexto.
- Modelo de datos proactivo. El modelo de datos actual es reactivo (el modelo se actualiza cada vez que
t()ocurre una llamada ). Necesitamos un modelo de datos proactivo, uno en el que la aplicación se encargue de buscar t()instancias antes de que el cliente las ejecute realmente.
- Necesitamos contexto.
t()solo no es suficiente, porque no sabemos que estamos traduciendo 'foo', pero el idioma de destino al que estamos traduciendo depende de la URL de dónde t()ocurre. Incluso si pudiéramos codificar el idioma de destino en la t()llamada, digamos, usando una llamada envolvente, no funcionaría para sus propósitos.
He identificado algunas de las herramientas que, si las tuviéramos, ayudarían a nuestro problema. Con estas herramientas podríamos entrar en el modelo de datos y decir: dame todas las cadenas envueltas t()que aún no se han poblado. Ahora inserte estas traducciones. Gracias.
Y la próxima vez que venga el cliente, las traducciones estarán ahí.
¿Cómo podríamos ... construir estas herramientas?
Restricciones
- El idioma de destino no puede estar en la plantilla, eso lo decide la URL. Suponiendo que la cadena debe admitir cualquier idioma.
- 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 cualquier solución disponible, o en hacer soluciones personalizadas.
Lluvia de ideas sobre soluciones
Necesito algo que vincule "todo". ¿Qué pasa con ... una entidad?
- Una entidad puede mantener 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 de URL predeterminada del producto.
- Los tokens se pueden usar para especificar ubicaciones alternativas (¿idiomas?) En las que aparecerá el producto.
- Las entidades nos proporcionan 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 luego toma /pl/product/200, usted viaja a la base de datos, busca el producto 200 y toma la pltraducción 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 aquí en términos de qué módulo de traducción está utilizando. Muy bien podría terminar usando 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 visto D8) son reactivos, no proactivos.
En una palabra
En teoría, las herramientas para construir lo que necesita están allí, siendo las entidades el componente clave que uniría todo: - datos (cadena de traducción), - idiomas de destino. No tiene que estar en la Entidad misma, preferiblemente un vocabulario de taxonomía, digamos para los idiomas de los productos. o tal vez una taxonomía genérica para otras entidades también. - 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 productentidades, vaya al URL aliascampo, obtenga el token de taxonomía, recorra todas las combinaciones de términos posibles, presente todas las combinaciones al usuario actual usando 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 es exactamente la 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 el código y los datos más ordenados y fáciles.
Construyéndolo: posibles soluciones
- D8MI (Iniciativa multilingüe Drupal 8)
- Código personalizado: traducciones "indexadas" disponibles en plantillas por t () mediante consultas programáticas y renderizando 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 lenguaje central asociado con el producto),
renderice la entidad,
para detectar sus cadenas de traducción t ()
, renderice el tema de llamadas (), que maneja la capa de presentación multilingüe de el 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 del idioma predeterminado para cada llamada.
- Los parámetros t () en 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 el rol 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:
- ¿Cuál es el contexto? Si hago una llamada programática a theme () para cada paquete de entidad "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, teorizar y seudocódigo solo es bueno para una lluvia de ideas. Pero en el desarrollo apenas sabremos a qué nos enfrentamos realmente hasta que empecemos 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 de trabajo. Algunas de las preguntas abiertas anteriores solo se pueden responder de esta manera, y cuanto antes creamos prototipos (independientemente del éxito o el fracaso), podemos comenzar a responder algunas de esas preguntas, o cambiar el enfoque por completo. Estén atentos ~
wgeto lo que sea. Hackish, pero dijiste que estaba permitido (: