He leído que la única manera de obtener todos los textos para reemplazar es usando la configuración de textos del sitio y reemplazando cada uno. Estoy intentando cambiar la redacción:
Temas → Hilos
Categorías → Foros
Subcategorías → Subforos
Porque eso tiene mucho más sentido para mí en los foros de mensajes. Pude cambiar muchos de ellos con los textos del sitio, pero es una forma muy ineficiente de hacerlo. ¿Hay alguna otra opción?
(También, debido a que solo devolverá los primeros 50 resultados, no puedo cambiarlos todos con los textos del sitio de todas formas.)
¡Jaja, usaré tu idioma para mantener las cosas sanas! Respecto a este archivo, ¿puedo simplemente cambiar su contenido para mi instalación local y las cosas cambiarán en todo el sitio?
Eso es principalmente para que puedas ver cuáles son todos.
Podrías editar ese archivo y luego inventar la forma de que tu versión se copie sobre la que está en el contenedor.
Otra cosa que podrías hacer sería editarlo y luego inventar la forma de actualizar las cosas en la base de datos mediante la API. O podrías hacerlo en Rails. En realidad, no sería muy difícil conseguir que alguna IA escriba un script para hacer las actualizaciones.
Realmente no lo recomiendo, pero podría ser divertido.
Entonces, quieres decir que este archivo es lo que la aplicación interpreta para poblar la base de datos con los valores reales? Es decir, ¿esto es lo que el sistema lee como “predeterminados”?
Esto no accede a la base de datos (creo que sería demasiado lento).
Creo que la mayor parte del contenido local se procesa en memoria para mayor velocidad, utilizando Redis como caché (estaré encantado de que me corrijan si me equivoco).
Lo único que se almacena en la base de datos son tus modificaciones (en la tabla translation_overrides), que se leerán al inicializar la aplicación o de forma individual cuando realices una única modificación mientras estás en línea.
Solo señalaría un par de cosas:
aumentar significativamente el número de modificaciones podría alargar el tiempo de inicialización de tu aplicación (no estoy seguro de que nadie haya medido esto).
estas modificaciones pueden convertirse en una molestia administrativa de mantener a medida que Discourse evoluciona pero mantiene su propia nomenclatura. Te estás inventando trabajo aquí.
dado que ahora es, sin duda, la plataforma de foros más popular, mucha gente ya utiliza al menos un sitio de Discourse y está muy acostumbrada a la nomenclatura, así que considera no confundir a tus usuarios cambiando lo que ya les resulta familiar por normas anteriores.
Ver también:
Esto implica que cada Categoría tiene sus propios administradores, URL, configuraciones, propósito… por ejemplo, Meta es un foro. No está compuesto por varios foros… Realmente no estoy seguro de cómo argumentarías eso. Pero me desvío del tema.
Respetuosamente, ustedes no conocen mi caso de uso. Decir que es una “idea terrible” o que podría estar dañando la experiencia del usuario sin saber por qué hago lo que hago asume que lo hago por ignorancia. No estoy interesado en entrar en un debate sobre taxonomía o experiencia del usuario. Para mi caso de uso y audiencia, la terminología que Discourse usa para describir sus tipos de contenido no tiene sentido.
Así que para recapitular:
Discourse lee este archivo para completar sus etiquetas por defecto; cualquier cambio que haga en la traducción sobrescribe esto y termina guardado en la base de datos. Entonces, la forma más eficiente de cambiar estos términos en todo el sitio es simplemente modificar este archivo y moverlo a la carpeta /locales/.
Parecería que las únicas preocupaciones aquí son si ese archivo es actualizado por el núcleo. Supongo entonces que los nuevos textos se leerían desde la versión /standalone/ del archivo en lugar del mío, por lo que necesitaría actualizar el mío para acomodar eso. No estoy seguro de cómo el rendimiento es un problema en este caso, ya que la base de datos no está involucrada y solo se lee desde un archivo?
Esa es una forma de hacerlo. Necesitarías editar tu app.yml para que se haga cada vez que construyas un nuevo contenedor.
Si haces lo que describí anteriormente, tu versión sobrescribirá la versión que se suministra con la versión actual. La versión en el directorio locales es lo que creo que quieres decir con la “versión standalone”. Por lo tanto, si lo haces de esta manera, el archivo eventualmente carecerá de cosas a menos que observes cuándo cambia. En el peor de los casos, solo verás el nombre de la cosa que falta, así que tal vez no te importe. No fallará, solo se verá confuso.
Digo que es una mala idea porque estas son cosas que pueden causar problemas si no las entiendes, así que cuando termine siendo un desastre, quedará constancia de que no recomendé los cambios que te indiqué cómo hacer.
Parece que obtuve la mayoría (si no todas) las referencias públicas a través de los textos del sitio. Pero lo tendré en cuenta si desarrollo un método más completo.
¡Buena idea! Eso es definitivamente mejor que sobrescribir todo como sugerí. . . . siempre y cuando esas operaciones sed no cambien los nombres de los textos.
