Me pregunto si es posible cambiar el nombre de los nombres internos del nivel de confianza porque rompen nuestra interfaz de usuario y realmente no queremos agregar 4 grupos más para mostrar correctamente (menos es mejor).
¿Podría estar relacionado con la traducción al español?
Hola,
¡Claro! Mira: tu.dominio/admin/customize/site_texts?q=groups.default_names.trust
No se guardan (y todavía necesito usar Chrome para subir imágenes o usar el editor porque Firefox ESR todavía tiene errores 
)
Tienes razón, es más complicado que eso, para un grupo automático solo se puede acceder al display_name a través de la interfaz de usuario, pero las menciones sí usan name
ps. sobre Firefox, solo estaba usando 102.0 sin ningún problema (win64) ¯\\_(ツ)_/¯
Puedo profundizar más si me das tu opinión o algún enlace para leer.
Creo que ese tipo de cosas marcan la diferencia en la participación. No todas las comunidades están hechas para desarrolladores 
Espero que los niveles de confianza sean más flexibles. No podemos usarlos en suscripciones, no podemos cambiarles el nombre, no podemos deshacernos de ellos (y lo mismo con las insignias).
Al principio pensé que habría algo en: Administrative Bulk Operations , pero como temía: Can I change the "Staff" Group Name? , no.
Actualmente estoy probando si reconstruir con una configuración regional diferente por defecto cambia los nombres de los grupos automáticos, bueno… sin suerte 
.
se definen durante la configuración inicial desde - por ejemplo en francés - aquí:
pd. puedes “deshacerte” de las insignias, ese es el parámetro enable badges 
Pensé que algunas eran permanentes, pero está bien, creo que el equipo principal tiene algo de razón (:\n\nPregunté lo mismo sobre el grupo de Staff (necesitamos ocultarlo y usar otros, una solución alternativa está bien pero necesitamos algo para cambiar @trust_level_1)\n\nEso se ve realmente mal. ¿Los paranoicos podrían eliminar los datos del sitio (?)
Estoy seguro de que casi cualquier cosa es posible dentro de la consola de Rails, ¡pero requeriría un conocimiento extenso del código que estoy lejos de tener!
En realidad sí lo hace, todavía es un poco confuso saber exactamente cuándo y cómo (¿podría ser necesario volver a visitar /wizard/steps/locale? ¿o ejecutar discourse-setup o tal vez se hace en segundo plano mediante una tarea recurrente…)
Así que ahora la pregunta es, ¿podría usarse un plugin para añadir una configuración regional? 
¡Sí! Add a new locale from plugin
¿Por qué rompe la interfaz de usuario?
Puedes ocultar todos los grupos de nivel de confianza para que solo los administradores/moderadores los vean en la página de grupos.
Estamos usando niveles de confianza predeterminados pero no con _default_trust_level_ux sino con nombres geniales entonces.
Si estás sincronizado con Discord y Suscripciones, eso podría tener sentido si quieres mantener a toda tu audiencia comprometida con la filosofía de Discourse pero ofrecer la oportunidad de pagar por información.
El problema aparece en esas pequeñas cosas que hacen que ese objetivo sea casi imposible para los que no saben programar.
Estamos haciendo nuestro mejor esfuerzo en la curva de aprendizaje
Gracias al increíble trabajo del equipo, es sorprendentemente factible.
default locale, la seleccioné.
sudo /var/discourse/./launcher enter apprails cGroup.refresh_automatic_groups!()exit; exitMuchas gracias por eso.
Intenté pero veo que simplemente no actualizará los niveles de confianza en español (pero funcionó con el grupo de administradores, cambió):
https://github.com/satoshinotdead/discourse-custom-locale/blob/main/config/locales/server.es_XX.yml
¿Podría estar relacionado con mi propia instancia? Revisé y no vi ningún error en los registros relacionados.
He corrido rápidamente y esto me ha funcionado:
groups.default_names.trust_level_0 a ‘Randoms’ (Idioma: Español)
/sidekiq/scheduler y activa manualmente Jobs::EnsureDbConsistencyHubo un problema en otro tema donde los nuevos nombres de grupo ya estaban siendo utilizados por algunos usuarios, lo que causó un conflicto. Si esto no funciona, ¿quizás sea eso?
¿Se supone que debemos reconstruir después de ejecutar manualmente Jobs::EnsureDbConsistency?
Lo intenté sin éxito 
¡pero gracias chicos!
No se necesita reconstrucción. Ese es un trabajo de fondo programado, por lo que se ejecutaría en algún momento automáticamente. Todo lo que hace activarlo manualmente es eliminar la espera.
No estoy seguro de por qué eso no funciona para ti. ¿Y no hay otros grupos/usuarios/nada más que puedan compartir un nombre que pueda estar causando un conflicto?
Estaba usando grupos nuevos antes y olvidé renombrarlos/eliminarlos antes de seguir sus pasos, chicos.
¡Hecho, gracias de nuevo!
¿Cuál es el mejor enfoque si no puedo actualizar los grupos en las cadenas modificadas de trust_levels predeterminadas?
Ya intenté:
groups.default_names.trust_level_X)EnsureDbConsistencyGroup.refresh_automatic_groups!()¿Pensé que habías logrado que esto funcionara?
Funcionaba, pero cuando intenté actualizar algunos nombres de trust_level simplemente ya no se actualizaron.
Los grupos siguen sin actualizarse y el plugin se cambió al ingresar a la aplicación (y los nombres desde la interfaz de usuario, como dije antes):