Я читал, что единственный способ получить все тексты для замены — это использовать настройки «Тексты сайта» и заменять каждый из них вручную. Я пытаюсь изменить формулировки:
Темы → Темы
Категории → Форумы
Подкатегории → Подфорумы
Потому что для досок объявлений это имеет гораздо больше смысла. Мне удалось изменить многие из них через «Тексты сайта», но это очень неэффективный способ. Есть ли какой-то другой вариант?
(Кроме того, поскольку возвращается только первые 50 результатов, я не могу изменить их все через «Тексты сайта».)
Лол, я буду использовать твой язык, чтобы сохранить рассудок! Касательно этого файла: могу ли я просто изменить его содержимое для локальной установки, и изменения отобразятся на всём сайте?
Это в основном для того, чтобы вы могли увидеть, что это за файлы.
Вы можете отредактировать этот файл, а затем каким-то образом скопировать вашу версию поверх той, что находится в контейнере.
Другой вариант — отредактировать файл, а затем обновить данные в базе данных через API. Или вы можете сделать это в Rails. На самом деле, возможно, не так уж сложно попросить ИИ написать скрипт для выполнения этих обновлений.
Я действительно не рекомендую это делать, но это может быть забавно.
Правильно ли я понимаю, что этот файл содержит данные, которые приложение использует для заполнения базы фактическими значениями? То есть это «значения по умолчанию», которые система считывает?
Это не обращается к базе данных (я думаю, это было бы слишком медленно).
Полагаю, большая часть локализации обрабатывается в памяти для скорости, с использованием Redis в качестве кэша (готов принять исправление, если я ошибаюсь).
В базу данных сохраняются только ваши изменения (в таблице translation_overrides), которые считываются при инициализации приложения или по мере внесения отдельных изменений в режиме онлайн.
Хочу лишь отметить несколько моментов:
значительное увеличение количества изменений может увеличить время инициализации вашего приложения (не уверен, что кто-то проводил бенчмарки этого).
по мере развития Discourse и сохранения им собственной терминологии это может стать административной головной болью. Вы сами себе создаете лишнюю работу.
учитывая, что Discourse сейчас, пожалуй, самая популярная платформа для форумов, многие люди уже используют как минимум один сайт на Discourse и привыкли к его терминологии, так что, возможно, стоит не путать пользователей, возвращаясь к прежним нормам вместо того, что они уже усвоили?
Также см.:
Это подразумевает, что у каждой категории есть свои администраторы, URL, настройки, цели… Например, Meta — это форум. Он не состоит из нескольких форумов… Я действительно не уверен, как вы можете это оспорить? Но я отвлекся.
Так что, если вы захотите изменить их все (что является ужасной идеей), вы можете отредактировать этот файл, поместить его в /var/discourse/shared/standalone/whatever.
А затем добавить в app.yml команду exec, которая скопирует его из /shared/whatever в /var/www/discourse/config/locales/.
Но в этом случае вам также придётся отслеживать изменения в коммитах, чтобы видеть, менялся ли этот файл, и вносить соответствующие правки.
Поэтому, вероятно, лучше использовать API или подход Rails, который сохраняет значения в базе данных.
С уважением, вы не знаете моего сценария использования. Утверждать, что это «ужасная идея», или говорить, что я могу навредить пользовательскому опыту, не зная, почему я делаю именно это, предполагает, что я действовал по незнанию. Я не заинтересован в спорах о таксономии или пользовательском опыте. Для моего сценария использования и моей аудитории терминология, которую Discourse использует для описания типов контента, не имеет смысла.
Итак, подытожим:
Discourse по умолчанию читает этот файл для заполнения своих меток; любые изменения, которые я вношу в перевод, переопределяют это и в конечном итоге сохраняются в базе данных. Таким образом, самый эффективный способ изменить эти термины на всем сайте — просто изменить этот файл и переместить его в папку /locales/.
Похоже, что единственное беспокойство здесь связано с тем, что этот файл может быть обновлен ядром. Я предполагаю, что любой новый текст будет считываться из версии файла в /standalone/, а не из моей, поэтому мне нужно будет обновить свой файл, чтобы учесть это. Не совсем понятно, как в этом случае может быть проблемой производительность, поскольку база данных не задействована, и происходит просто чтение из файла?
Это один из способов. Вам нужно будет редактировать ваш app.yml каждый раз при сборке нового контейнера.
Если вы сделаете то, что я описал выше, ваша версия перезапишет версию, поставляемую с текущей версией. Версия в директории locales — это то, что вы, вероятно, имеете в виду под «автономной версией». Таким образом, если вы поступите таким образом, файл со временем начнёт терять содержимое, если вы не будете следить за изменениями. В худшем случае вы просто увидите название отсутствующего элемента, так что, возможно, вас это не смутит. Это не приведёт к сбою, но может выглядеть запутанно.
Я говорю, что это плохая идея, потому что такие вещи могут вызвать проблемы, если вы не понимаете, что делаете. Поэтому, если в итоге всё обернётся катастрофой, я официально заявляю, что не рекомендовал именно те изменения, которые я вам показал, как выполнить.
Кажется, я получил большинство (если не все) общедоступных ссылок через тексты сайта. Но я буду иметь это в виду, если разработаю более комплексный метод.
@alkah3st, тебе удалось настроить это так, как ты хотел? Я тоже думаю о смене терминологии (хотя бы на французский) и был бы очень признателен за твои отзывы, если ты уже проходил через это.
