Non, je ne pense pas.
Cela n’accède pas à la base de données (je pense que ce serait trop lent).
Je crois que la plupart des éléments de localisation sont traités en mémoire pour la vitesse, en utilisant Redis comme cache (je serais heureux d’être corrigé sur ce point).
La seule chose qui est stockée dans la base de données sont vos modifications (dans la table translation_overrides), qui seront lues lors de l’initialisation de l’application ou au coup par coup lorsque vous effectuez une seule modification en ligne.
Je voudrais juste souligner quelques points :
- augmenter considérablement le nombre de modifications pourrait prolonger le temps d’initialisation de votre application (je ne suis pas sûr que quelqu’un ait effectué de tests de performance).
- cela pourrait devenir une corvée administrative à maintenir à mesure que Discourse évolue tout en conservant sa propre nomenclature. Vous vous inventez du travail ici.
- étant donné que c’est maintenant sans doute la plateforme de forum la plus populaire, beaucoup de gens utilisent déjà au moins un site Discourse et sont très habitués à la nomenclature, alors peut-être envisagez de ne pas dérouter vos utilisateurs en changeant ce à quoi ils sont déjà habitués pour revenir aux normes antérieures ?
Voir aussi :
Cela implique que chaque catégorie a ses propres administrateurs, URL, paramètres, objectif… par exemple, Meta est un forum. Il n’est pas composé de plusieurs forums… Je ne suis vraiment pas sûr de comment vous pourriez argumenter cela ? Mais je m’éloigne du sujet.