사용자 설정 페이지의 특정 문자열을 수정하려고 하고 있습니다. 관리자 → 사이트 텍스트로 이동하여 관련 키를 검색했지만, 해당 텍스트를 찾지 못했다는 메시지가 표시되어 원하는 특정 텍스트를 사용자 정의할 수 없었습니다.
해당 키가 유효하다고 확신합니다. 여기에서 정의되어 있기 때문입니다:
이후 대상 언어를 영어로 변경했지만 user.username.short_instructions에 대한 검색 결과가 여전히 없었습니다. 또한 user.username.title, user.preferences.title, filters.latest.title 등 다른 문자열도 검색해 보았지만 결과물이 없었습니다.
안전 모드를 사용하여 커스터마이징을 일시적으로 비활성화해 보시고, 그렇게 하면 되는지 확인해 보세요.
해당 건에 대해 몇 가지 업데이트가 있습니다. 이제 문제가 백엔드에 있음을 확실히 확인할 수 있습니다. 코드를 검토하던 중 특정 줄을 발견했습니다:
놀랍게도 제 인스턴스에서 I18n.exists?("js.user.username.short_instructions", :en)를 실행하면 false가 반환됩니다.
이 코드 줄을 수동으로 제거했고, 이제 user.username.short_instructions를 검색할 수 있게 되었습니다.
I18n.exists?("js.user.username.short_instructions", :en)가 왜 false를 반환하는지 명확하지 않습니다. 이 문제가 제 인스턴스에 국한된 것인지, 아니면 Discourse의 더 일반적인 문제인지 확인하기 위해 추가 조사를 진행할 수 있습니다.
Discourse 인스턴스에서 발생하는 일반적인 문제인 것 같습니다.
sam@arch discourse % bin/rails c
Loading development environment (Rails 8.0.4)
[1] pry(main)> I18n.exists?("js.user.username.short_instructions", :en)
=> true
특히 빌드 과정과 관련된 문제일 수 있습니다. 빌드 시 이러한 모든 내용을 파싱하여 테이블에 삽입하는데, 당신의 인스턴스에서는 이 과정이 아직 완료되지 않은 것으로 보입니다.
콘솔 재빌드를 권장합니다.
@sam, 답변해 주셔서 감사합니다. 저는 서로 다른 방법으로 Discourse 인스턴스 3개를 배포해 보았는데, 모두 동일한 문제를 보여 설치 문제라고 생각하지 않습니다.
플러그인을 다시 살펴본 결과, 다음 내용으로 로케일 파일(plugins/XXXX/config/locales/client.en.yml)을 생성한 플러그인 하나가 있었습니다:
en:
js:
이 파일을 삭제하니 문제가 해결되었습니다. I18n 구현 방식을 간단히 조사해 보니, 로딩 시 번역을 병합하는 데 deep_merge가 사용되고 있음을 발견했습니다:
# File activesupport/lib/active_support/vendor/i18n-0.4.1/i18n/backend/simple.rb, line 31
31: def store_translations(locale, data, options = {})
32: locale = locale.to_sym
33: translations[locale] ||= {}
34: data = data.deep_symbolize_keys
35: translations[locale].deep_merge!(data)
36: end
위 YAML은 다음과 같이 파싱됩니다:
{"en": {"js": null}}
이로 인해 병합 후 en.js 키 아래에 있는 전체 내용이 삭제됩니다. 플러그인 개발자로서 이 문제가 제 코딩 오류에서 비롯되었음을 이해하며, 이에 대해 전적으로 책임을 집니다. 다만, Discourse가 로케일 파일을 검사하기 위한 설계가 이미 존재한다는 점을 고려할 때(여기: here), 이러한 발생을 경고하기 위한 추가적인 점검이 Discourse에 도움이 될 것이라고 생각합니다.
찾으셨다니 다행입니다!
개발 XP 팀에게 알리도록 하겠습니다.
좋은 지적 감사합니다. @pangbo 님, 해결 방안에 대해 알려주셔서 감사합니다.
여기에 검사를 추가하는 것도 분명히 가능합니다. 다만 기억이 맞다면 이 체크어는 RSpec 테스트 중에만 사용됩니다. 이런 경우에도 도움이 되었을까요?
이 null 케이스에 대한 런타임 검사를 도입하는 데에도 분명히 열려 있습니다. 적절한 위치를 찾을 수 있다면 말이죠.
맞습니다. 해당 체크가 런타임에 실행된다는 근거 없는 가정을 했습니다. GitHub 저장소를 검색해 보니, 이 체크들은 rake 태스크 내에서만 호출되는 것으로 보입니다:
여기에 체크를 추가했더라도 제가 겪은 문제를 사전에 발견할 수 없었을 것입니다. 아마 가장 단순한 해결책은 문서에서 개발자들에게 이 관행을 피하도록 경고하는 것일 것입니다. 