Mi chiedo se sia possibile rinominare i nomi interni dei livelli di fiducia perché interrompono la nostra interfaccia utente e non vogliamo davvero aggiungere altri 4 gruppi per visualizzare correttamente (meno è meglio).\n\n
\n\nPotrebbe essere correlato alla traduzione in spagnolo?
Ciao,
certo! vedi: your.domain/admin/customize/site_texts?q=groups.default_names.trust
3 Mi Piace
Non rimangono salvate (e ho ancora bisogno di usare Chrome per caricare immagini o usare l’editor perché Firefox ESR è ancora buggato 
)
Hai ragione, è più complicato di così, per un gruppo automatico solo il display_name è accessibile tramite l’interfaccia utente, ma le menzioni usano name
ps. riguardo a firefox, stavo solo usando la 102.0 senza problemi (win64) ¯\\_(ツ)_/¯
1 Mi Piace
Posso approfondire se mi dai la tua opinione o qualche link da leggere.
Penso che questo tipo di cose faccia la differenza nell’engagement. Non tutte le community sono fatte per gli sviluppatori 
Spero che i livelli di fiducia saranno più flessibili. Non possiamo usarli negli abbonamenti, non possiamo cambiarne i nomi, non possiamo liberarcene (e lo stesso vale per i badge).
Ho pensato che ci sarebbe stato qualcosa in: Administrative Bulk Operations , ma come temevo: Can I change the "Staff" Group Name? , no.
Attualmente sto testando se la ricostruzione con una locale diversa per impostazione predefinita cambia i nomi dei gruppi automatici, beh… nessuna fortuna 
.
sono definiti durante la configurazione iniziale da - ad esempio in francese - qui:
ps. puoi “liberarti” dei badge, questo è il parametro enable badges 
1 Mi Piace
Pensavo che alcuni fossero permanenti, ma va bene, penso che il team principale abbia delle ragioni (:\n\nHo chiesto la stessa cosa riguardo al gruppo Staff (dobbiamo nasconderlo e usarne altri, un workaround va bene ma abbiamo bisogno di qualcosa per cambiare @trust_level_1)\n\nQuesto sembra davvero brutto. I paranoici potrebbero cancellare i dati del sito (?)
Sono sicuro che quasi tutto sia possibile all’interno della console Rails, ma richiederebbe una conoscenza approfondita del codice che sono ben lungi dall’avere!
1 Mi Piace
In realtà lo fa, ancora un po’ confuso su esattamente quando e come (potrebbe essere necessario rivisitare /wizard/steps/locale? o eseguire discourse-setup o forse viene fatto in background da un’attività ricorrente…)
Quindi ora la domanda è se un plugin possa essere utilizzato per aggiungere una locale 
Sì! Add a new locale from plugin
Perché interrompe l’interfaccia utente?
Puoi nascondere tutti i gruppi di trust_level in modo che solo gli amministratori/moderatori li vedano nella pagina dei gruppi.
Stiamo utilizzando i livelli di fiducia predefiniti ma non con _default_trust_level_ux ma con nomi accattivanti.\n\nSe sei in sincronia con Discord e Abbonamenti, ciò potrebbe avere senso se desideri mantenere tutto il tuo pubblico coinvolto con la filosofia di Discourse ma offrire la possibilità di pagare per le informazioni.\n\nIl problema appare in quelle piccole cose che rendono quell’obiettivo quasi impossibile per i no-coder.\n\nStiamo facendo del nostro meglio nella curva di apprendimento
1 Mi Piace
Quindi, grazie all’incredibile lavoro del team, è sorprendentemente fattibile,
- Ho creato un piccolo plugin come indicato qui: Add a new locale from plugin
- Ho provato alcune modifiche:
- Ricostruito, per vedere la locale personalizzata nel parametro
default locale, l’ho selezionata
- Entrato nell’app e nella console rails
sudo /var/discourse/./launcher enter app
rails c
e infine
Group.refresh_automatic_groups!()
exit;exit
2 Mi Piace
Molte grazie.
Ho provato ma vedo che non aggiorna trust_levels in spagnolo (ma ha funzionato con il gruppo Admins, cambiato):
https://github.com/satoshinotdead/discourse-custom-locale/blob/main/config/locales/server.es_XX.yml
Potrebbe essere correlato alla mia istanza? Ho controllato e non ho visto errori nei log correlati.
Ho appena fatto una rapida revisione e questo ha funzionato per me:
- Cambia
groups.default_names.trust_level_0in ‘Randoms’ (Lingua: Español)
- Vai su
/sidekiq/schedulere attiva manualmenteJobs::EnsureDbConsistency
C’è stato un problema in un altro argomento in cui i nuovi nomi dei gruppi erano già stati presi da alcuni utenti, causando un conflitto. Se questo non funziona, forse potrebbe essere quello?
3 Mi Piace
Dovremmo ricostruire dopo aver eseguito manualmente Jobs::EnsureDbConsistency?
Ci ho provato senza successo 
ma grazie ragazzi!
Non è necessaria alcuna ricostruzione. Si tratta di un processo in background pianificato, quindi verrebbe eseguito automaticamente a un certo punto. Attivarlo manualmente serve solo a eliminare l’attesa.
Non sono sicuro del motivo per cui non funziona per te. E non ci sono altri gruppi/utenti/altro che potrebbero condividere un nome che potrebbe causare un conflitto?
1 Mi Piace
Prima usavo nuovi gruppi e ho dimenticato di rinominarli/eliminarli prima di seguire i vostri passaggi.\n\nFatto, grazie ancora!
1 Mi Piace
Qual è l’approccio migliore se non riesco ad aggiornare i gruppi sulle stringhe modificate dei trust_levels predefiniti?
Già provato:
- Modifica e aggiornamento del plugin.
- Modifica della stringa dall’interfaccia utente (
groups.default_names.trust_level_X) - Ripristino da Sidekiq
EnsureDbConsistency Group.refresh_automatic_groups!()
Pensavo che tu fossi riuscito a farlo funzionare?
Funzionava, ma quando ho provato ad aggiornare alcuni nomi di trust_level non si sono più aggiornati.
I gruppi rimangono senza aggiornamenti e il plugin è stato modificato all’interno dell’app (e i nomi dall’interfaccia utente come ho detto prima):