אתה יכול לערוך את הקובץ הזה ולאחר מכן להמציא את העניין שיקראו לגרסתך על פני זו שבמכולה.
דבר נוסף שאתה יכול לעשות הוא לערוך את הקובץ ולאחר מכן לנסות לעדכן את הדברים במסד הנתונים דרך ה-API. או שאתה יכול לעשות את זה ב-Rails. למעשה, זה אולי לא כזה קשה לגרום ל-Ai לכתוב סקריפט לביצוע העדכונים.
באמת אני לא ממליץ על כך, אבל זה יכול להיות מעניין.
This doesn’t hit the database (I think it would be too slow).
I believe most of the locale stuff is processed in memory for speed, using Redis as a cache (happy to be corrected on that).
the only thing that gets stored in the database are your modifications (in the table translation_overrides), which will be read when you initialise the app or piecemeal when you make a single modification whilst online.
I would just point out a couple of things:
increasing the number of modifications significantly might extend your app initialisation time (I’m not sure anyone has benchmarked this).
these may become an administrative pain to maintain as Discourse evolves but maintains its own nomenclature. You are inventing work for yourself here.
given it’s now arguably the most popular forum platform, lots of people already use at least one Discourse site and are very used to the nomenclature, so maybe consider not confusing your users by changing what they’ve already got used to back to prior norms?
Also see:
This implies that each Category has its own administrators, URL, settings, purpose … e.g. Meta is a forum. It is not made up of several forums … I’m really not sure how you’d argue that? But I digress.
בכבוד, אתם לא מכירים את מקרה השימוש שלי. לומר שזה “רעיון נורא” או שאני עלול להזיק לחוויית המשתמש מבלי לדעת מדוע אני עושה את מה שאני עושה предполагает שאני עושה את זה מתוך בורות. אני לא מעוניין לנהל ויכוח על טקסונומיה או חווית משתמש. עבור מקרה השימוש והקהל שלי, הטרמינולגיה שבה משתמשים ב-Discourse לתיאור סוגי התוכן שלה אינה הגיונית.
אז כדי לסכם:
Discourse קורא את הקובץ הזה כדי לאכלס את התוויות שלו כברירת מחדל; כל שינוי שאני עושה בתרגום מחליף את זה ומאוחסן במסד הנתונים. לכן הדרך היעילה ביותר לשנות מונחים אלה בכל האתר היא פשוט לשנות את הקובץ הזה ולהעבירו לתיקייה /locales/.
נראה שהדאגות היחידות כאן הן אם הקובץ הזה מקודד על ידי הליבה. אני מניח אז שהטקסטים החדשים ייקראו מקובץ ה /standalone/ במקום שלי, ולכן אצטרך לעדכן את הקובץ שלי כדי להתאים לכך. אינני בטוח כיצד ביצועי מערכת מושפעים במצב כזה, מאחר והמסד נתונים לא מעורב וזה רק קראיה מקובץ?
That’s one way to do it. You’d need to edit your app.yml to make it to it every time you build a new container.
If you do what I described above your version will overwrite the version that is supplied with the current version. The version in the locales directory is what I think you mean by the “standalone version”. So, if you do it this way, the file will eventually be missing stuff unless you watch when it changes. Worst case, though, is you’ll just see the name of the thing that’s missing, so maybe you won’t care. It won’t crash, just look confusing.
I’m saying it’s a bad idea because these are things that can cause problems if you don’t understand, so when it ends up being a disaster, I’m on record saying that I did not recommend the very changes that I told you how to do.
Good one! That’s definitely better than overwriting the whole thing as I suggested. . . . as long as those sed operations don’t change the names of the texts!