J’ai lu que la seule façon de récupérer tous les textes à remplacer consiste à utiliser les paramètres de textes du site et à remplacer chacun d’eux. Je tente de changer la terminologie :
Parce que cela a beaucoup plus de sens pour moi avec les forums. J’ai pu en changer beaucoup avec les textes du site, mais c’est une méthode tellement inefficace. Existe-t-il une autre solution ?
(De plus, comme cela ne renverra que les 50 premiers résultats, je ne peux pas tous les modifier avec les textes du site de toute façon.)
Lol, j’utiliserai ta langue pour garder les choses saines ! Concernant ce fichier, puis-je simplement changer son contenu pour mon installation locale et les modifications se propageront partout sur le site ?
C’est principalement pour vous permettre de voir ce que chacun d’eux est.
Vous pouvez modifier ce fichier puis essayer de faire en sorte que votre version soit copiée sur celle du conteneur.
Une autre option serait de le modifier et ensuite de tenter de mettre à jour les données dans la base via l’API. Ou vous pourriez le faire dans Rails. En réalité, il ne serait pas trop difficile de faire en sorte que une IA écrive un script pour faire les mises à jour.
Je ne le recommande vraiment pas, mais cela pourrait être amusant.
Alors, tu veux dire que ce fichier est ce que l’application interprète pour remplir la base de données avec les valeurs réelles ? C’est-à-dire que ce sont les “valeurs par défaut” que le système lit ?
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.
Donc, si vous voulez tous les changer, ce qui est une très mauvaise idée, vous pourriez modifier ce fichier, le placer dans /var/discourse/shared/standalone/whatever
Et ensuite ajouter une commande exec à app.yml qui le copierait depuis /shared/whatever vers /var/www/discourse/config/locales/
Mais vous devrez également surveiller les commits pour voir s’il a déjà été modifié afin de pouvoir ajouter tout ce qui a été modifié.
La méthode via l’API ou Rails, qui insère les valeurs dans la base de données, pourrait donc être meilleure.
Respectueusement, vous ne connaissez pas mon cas d’utilisation. Dire que c’est une « idée terrible » ou que je pourrais nuire à l’expérience utilisateur sans connaître pourquoi je fais ce que je fais suppose que je le fais par ignorance. Je ne souhaite pas débattre de taxonomie ou d’expérience utilisateur. Pour mon cas d’utilisation et mon public, la terminologie que Discourse utilise pour décrire ses types de contenu n’a pas de sens.
Donc pour récapituler :
Discourse lit ce fichier pour remplir ses étiquettes par défaut ; toute modification que je fais dans la traduction écrase cela et est sauvegardée dans la base de données. La manière la plus efficace de changer ces termes sur tout le site est donc simplement de modifier ce fichier et de le placer dans le dossier /locales/.
Il semblerait que la seule préoccupation ici soit si ce fichier est mis à jour par le cœur du logiciel. Je suppose alors que tout nouveau texte serait lu à partir de la version /standalone/ du fichier plutôt que le mien, donc je devrais mettre à jour le mien pour en tenir compte. Je ne suis pas sûr de la performance dans ce cas, puisque la base de données n’est pas impliquée et qu’il ne s’agit que de lire à partir d’un fichier?
C’est une façon de faire. Vous devrez modifier votre app.yml pour qu’il le fasse à chaque fois que vous construisez un nouveau conteneur.
Si vous faites ce que j’ai décrit ci-dessus, votre version écrasera la version fournie avec la version actuelle. La version dans le répertoire locales est ce que vous entendez par la « version autonome ». Donc, si vous faites cela, le fichier finira par manquer des choses à moins que vous ne surveilliez quand il change. Le pire des cas, cependant, est que vous verrez simplement le nom de la chose qui manque, donc peut-être que cela ne vous dérangera pas. Cela ne plantera pas, cela semblera juste confus.
Je dis que c’est une mauvaise idée car ce sont des choses qui peuvent causer des problèmes si vous ne comprenez pas, donc quand cela finit par être un désastre, je suis enregistré pour dire que je n’ai pas recommandé les changements que je vous ai expliqués comment faire.
Il semble que j’aie obtenu la plupart (si ce n’est toutes) des références destinées au public via les textes du site. Mais je garderai cela à l’esprit si je développe une méthode plus complète.
Bonne idée ! C’est certainement mieux que de tout écraser comme je l’avais suggéré. . . . tant que ces opérations sed ne modifient pas les noms des textes !
