Ho letto che l’unico modo per catturare tutti i testi da sostituire è usare le impostazioni dei testi del sito e sostituire ognuno di essi. Sto cercando di cambiare la terminologia:
Topics → Discussioni
Categories → Forum
Subcategories → Sottogruppi
Perché per me ha molto più senso con i forum. Sono riuscito a cambiare molti di loro con i testi del sito, ma è un metodo molto inefficiente. C’è un altro modo?
(Inoltre, poiché restituisce solo i primi 50 risultati, comunque non posso cambiare tutti i testi con i testi del sito.)
Lol, userò la tua lingua per mantenere la calma! Riguardo a questo file, posso semplicemente cambiare il contenuto per l’installazione locale e le cose cambieranno in tutto il sito?
Questo serve principalmente a farti vedere cosa sono tutti.
Potresti modificare quel file e poi cercare di far copiare la tua versione su quella nel contenitore.
Un’altra cosa che potresti fare sarebbe modificarlo e poi cercare di aggiornare le cose nel database tramite l’API. Oppure potresti farlo in Rails. In realtà, non dovrebbe essere troppo difficile far scrivere uno script a un’Intelligenza Artificiale per fare gli aggiornamenti.
Davvero, non te lo consiglio, ma potrebbe essere divertente.
Quindi intendi che questo file è ciò che l’app interpreta per popolare il database con i valori effettivi? Cioè, questo è il “default” che il sistema legge?
Questo non accede al database (penso che sarebbe troppo lento).
Credo che la maggior parte delle localizzazioni venga elaborata in memoria per velocità, utilizzando Redis come cache (sarò lieto di essere corretto su questo).
L’unica cosa che viene memorizzata nel database sono le tue modifiche (nella tabella translation_overrides), che verranno lette all’inizializzazione dell’app o a pezzi quando apporti una singola modifica mentre sei online.
Vorrei solo sottolineare un paio di cose:
aumentare significativamente il numero di modifiche potrebbe estendere il tempo di inizializzazione dell’app (non sono sicuro che qualcuno abbia effettuato un benchmark di questo).
queste potrebbero diventare un problema amministrativo da mantenere man mano che Discourse si evolve ma mantiene la sua nomenclatura. Ti stai inventando lavoro qui.
dato che ora è probabilmente la piattaforma di forum più popolare, molte persone utilizzano già almeno un sito Discourse e sono molto abituate alla nomenclatura, quindi forse considera di non confondere i tuoi utenti cambiando ciò a cui si sono già abituati a norme precedenti?
Vedi anche:
Ciò implica che ogni Categoria ha i propri amministratori, URL, impostazioni, scopo … ad esempio Meta è un forum. Non è composto da diversi forum … non sono davvero sicuro di come potresti sostenere questo? Ma divago.
Rispetto, ma non conoscete il mio caso d’uso. Dire che è una “idee terribile” o che potrei danneggiare l’esperienza dell’utente senza sapere perché sto facendo quello che faccio presume che lo faccia per ignoranza. Non sono interessato a discutere di tassonomia o esperienza utente. Per il mio caso d’uso e pubblico, la terminologia che Discourse usa per descrivere i tipi di contenuto non ha senso.
Quindi ricapitolando:
Discourse legge questo file per popolare le sue etichette di default; qualsiasi modifica che faccio nella traduzione sovrascrive questo e viene salvata nel database. Quindi il modo più efficiente per cambiare questi termini su tutto il sito è semplicemente cambiare questo file e spostarlo nella cartella /locales/
Sembrerebbe che l’unica preoccupazione sia se quel file viene aggiornato dal core. Presumo allora che qualsiasi nuovo testo sia letto dalla versione /standalone/ del file piuttosto che dalla mia, quindi dovrei aggiornare la mia per adattarmi a quello. Non sono sicuro di come le prestazioni siano un problema in questo caso, dato che il database non è coinvolto e si tratta semplicemente di leggere da un file?
Questo è un modo per farlo. Dovrai modificare il tuo app.yml per fare in modo che venga eseguito ogni volta che crei un nuovo container.
Se fai quello che ho descritto sopra, la tua versione sovrascriverà la versione fornita con la versione corrente. La versione nella directory locales è ciò che intendi per “versione standalone”. Quindi, se fai in questo modo, il file finirà per mancare di cose a meno che tu non lo osservi quando cambia. Nel peggiore dei casi, vedrai solo il nome della cosa che manca, quindi forse non ti importerà. Non si bloccherà, sembrerà solo confuso.
Sto dicendo che è una cattiva idea perché queste sono cose che possono causare problemi se non le capisci, quindi quando finisce per essere un disastro, sono a verbale dicendo che non ho raccomandato le modifiche che ti ho detto come fare.
Sembra che abbia ottenuto la maggior parte (se non tutte) delle riferimenti pubblici attraverso i testi del sito. Ma terrò presente questa informazione nel caso sviluppi un metodo più completo.
