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.
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.
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.
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.
@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í.
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.
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