No se pueden personalizar algunos textos del sitio

Estoy intentando modificar ciertas cadenas en la página de preferencias del usuario. Navegué a Admin -\u003e Textos del sitio y busqué las claves relevantes. Sin embargo, no pude personalizar el texto específico que buscaba, ya que me indicó que no se encontraron textos.

Estoy razonablemente seguro de que la clave es válida, ya que está definida aquí:

Luego cambié el idioma de destino al inglés, pero todavía no obtuve resultados para user.username.short_instructions. Además, intenté buscar otras cadenas, como user.username.title, user.preferences.title y filters.latest.title, pero sin éxito.

2 Me gusta

Muy extraño, puedo ver la clave

Si haces clic derecho y abres el inspector del navegador, ¿hay algún error en la pestaña de la consola?

1 me gusta

Parece que no hay errores relacionados y, según los resultados de la solicitud, podría ser un problema del backend.

Aunque no creo que los complementos que he instalado hayan modificado esta área en particular, intentaré eliminar todos los complementos no oficiales más tarde para ver si eso resuelve el problema.

1 me gusta

Puedes deshabilitar temporalmente las personalizaciones usando el modo seguro y ver si eso funciona.

1 me gusta

Tengo algunas actualizaciones sobre este asunto. Ahora puedo confirmar definitivamente que el problema reside en el backend. Mientras examinaba el código, noté una línea en particular:

Para mi sorpresa, ejecutar I18n.exists?("js.user.username.short_instructions", :en) en mi instancia devuelve false.

Eliminé manualmente esta línea de código y ahora puedo buscar user.username.short_instructions

No estoy seguro de por qué I18n.exists?("js.user.username.short_instructions", :en) devuelve false. Puede que investigue más a fondo para determinar si el problema es específico de mi instancia o un problema más general con Discourse.

Parece un problema general en tu instancia de Discourse.

sam@arch discourse % bin/rails c
Loading development environment (Rails 8.0.4)
[1] pry(main)> I18n.exists?("js.user.username.short_instructions", :en)
=> true

Particularmente algo relacionado con la compilación. Durante la compilación, analizamos todas estas cosas y las colocamos en tablas; de alguna manera, esto aún no ha sucedido en tu instancia.

Recomendaría una reconstrucción de la consola.

@sam, gracias por tu respuesta. He implementado tres instancias de Discourse utilizando diferentes métodos y todas presentan el mismo problema, lo que me lleva a creer que no es un problema de instalación.

Al reexaminar mis plugins, descubrí que uno de ellos creó un archivo de localización (plugins/XXXX/config/locales/client.en.yml) con el siguiente contenido:

en:
   js:

Eliminar este archivo resolvió el problema. Después de una breve investigación sobre la implementación de I18n, encontré que deep_merge se utiliza para fusionar traducciones durante la carga:

    # File activesupport/lib/active_support/vendor/i18n-0.4.1/i18n/backend/simple.rb, line 31
31:         def store_translations(locale, data, options = {})
32:           locale = locale.to_sym
33:           translations[locale] ||= {}
34:           data = data.deep_symbolize_keys
35:           translations[locale].deep_merge!(data)
36:         end

El YAML anterior se analiza como:

{"en": {"js": null}}

Esto da como resultado la eliminación de todo el contenido bajo la clave en.js después de la fusión. Como desarrollador de plugins, entiendo que este problema se debe a un error de codificación propio y soy totalmente responsable de él. Sin embargo, creo que Discourse podría beneficiarse de verificaciones adicionales para advertir contra tales ocurrencias, especialmente considerando que Discourse ya tiene un diseño para inspeccionar archivos de localización, como se ve aquí.

4 Me gusta

¡Me alegra que lo hayas encontrado!

Contactaré al equipo de desarrollo de xp para que estén al tanto.

4 Me gusta

Buena observación, gracias por actualizarnos sobre la solución @pangbo.

Definitivamente podríamos agregar una verificación aquí, aunque si mal no recuerdo, este verificador solo se usa durante las pruebas de RSpec. ¿Eso te habría ayudado en tu caso?

Definitivamente estoy abierto a tener una verificación en tiempo de ejecución para este caso de null, si podemos encontrar un buen lugar para ponerlo.

2 Me gusta

Tienes razón. Hice una suposición injustificada de que estas comprobaciones se ejecutarían en tiempo de ejecución. Al buscar en el repositorio de GitHub, parece que estas comprobaciones se invocan únicamente dentro de una tarea de rake: discourse/lib/tasks/i18n.rake at main · discourse/discourse · GitHub

Agregar comprobaciones aquí no habría identificado de manera preventiva el problema que encontré. Quizás la solución más sencilla sea advertir a los desarrolladores contra esta práctica en la documentación :innocent:

2 Me gusta

¿Qué hacemos con este tema? ¿Deberíamos moverlo a Dev ya que parece ser una guía para desarrolladores?