대부분의 로케일 관련 작업은 속도 향상을 위해 Redis를 캐시로 사용하여 메모리에서 처리된다고 생각합니다(이 부분에 대해 틀렸다면 지적해 주십시오).
데이터베이스에 저장되는 유일한 것은 여러분의 수정 사항들(테이블 translation_overrides 내)이며, 이는 앱 초기화 시 또는 온라인 상태에서 단일 수정을 수행할 때 부분적으로 읽힙니다.
몇 가지 사항을 지적하고 싶습니다:
수정 사항의 수를 크게 늘리면 앱 초기화 시간이 길어질 수 있습니다(이를 벤치마크한 사람이 있는지 확실하지 않습니다).
Discourse가 발전하면서 자체 명명 규칙을 유지하는 동안, 이러한 수정 사항들은 관리하는 것이 번거로워질 수 있습니다. 여기서는 스스로에게 불필요한 일을 만들고 있는 셈입니다.
Discourse가 현재 가장 인기 있는 포럼 플랫폼 중 하나인 점을 고려할 때, 많은 사람들이 이미 최소 한 개의 Discourse 사이트를 사용하며 해당 명명 규칙에 익숙합니다. 따라서 사용자들에게 혼란을 주지 않도록, 이미 익숙해진 것을 이전의 규범으로 되돌리지 않는 것이 좋겠습니다.
또한 다음을 참조하십시오:
이것은 각 카테고리(Category)가 자체 관리자, URL, 설정, 목적 등을 가진다는 것을 함의합니다. 예: Meta는 포럼입니다. 여러 포럼으로 구성되어 있는 것이 아닙니다 … 어떻게 그렇게 주장할 수 있는지 정말로 모르겠습니다. 하지만 이만 넘어가겠습니다.
정중히 말씀드리지만, 여러분은 제 사용 사례를 모릅니다. 제가 왜 그렇게 하는지 알지 못한 채 그것이 "최악의 아이디어"라고 하거나 사용자 경험을 해칠 수 있다고 말하는 것은 제가 무지해서 그렇게 한다고 전제하는 것입니다. 저는 분류 체계나 사용자 경험에 대한 논쟁에 관심이 없습니다. 제 사용 사례와 대상 독자군에 대해, Discourse가 콘텐츠 유형을 설명하는 데 사용하는 용어는 의미가 없습니다.
다시 정리하면 다음과 같습니다.
Discourse는 기본적으로 이 파일을 읽어 라벨을 채웁니다. 번역에서 제가 하는 모든 변경 사항은 이 기본값을 덮어쓰고 데이터베이스에 저장됩니다. 따라서 이 용어를 사이트 전체에서 변경하는 가장 효율적인 방법은 이 파일을 변경한 후 /locales/ 폴더로 이동시키는 것입니다.
여기에서 유일한 우려는 해당 파일이 코어에 의해 업데이트되는 경우일 것 같습니다. 그렇다면 새 텍스트는 제 파일이 아니라 /standalone/ 버전의 파일에서 읽힐 것이라고 추측하므로, 그에 맞춰 제 파일을 업데이트해야 할 것입니다. 데이터베이스가 관여되지 않고 단순히 파일에서 읽는 것이므로, 이 경우 성능이 문제가 되는지 확신할 수 없습니다.
그렇게 하는 방법 중 하나입니다. 새로운 컨테이너를 빌드할 때마다 이를 적용하려면 app.yml 파일을 편집해야 합니다.
위에서 설명드린 대로 진행하면, 현재 버전과 함께 제공되는 파일을 사용자의 버전이 덮어쓰게 됩니다. 로컬라이즈(locales) 디렉토리에 있는 버전이 바로 사용자가 말하는 "standalone 버전"을 의미하는 것 같습니다. 따라서 이 방식으로 진행하면 파일이 변경될 때 주의를 기울이지 않으면 결국 일부 내용이 누락될 수 있습니다. 하지만 최악의 경우에도 누락된 항목의 이름만 표시될 뿐이므로, 크게 신경 쓰이지 않을 수도 있습니다. 프로그램이 크래시되지는 않지만, 화면이 혼란스럽게 보일 수 있습니다.
이것이 나쁜 아이디어라고 말하는 이유는, 이러한 부분들을 이해하지 못하면 문제를 일으킬 수 있기 때문입니다. 그래서 결국 문제가 발생했을 때, 제가 어떻게 하라고 조언한 그 변경 사항들을 제가 권장하지 않았다는 점을 기록으로 남기고 싶습니다.