많은 수의 게시글을 가져오고 있는데, 콘텐츠에 @global과 같은 텍스트가 자주 포함되어 있습니다. (우리 디스코urs 인스턴스의 주제는 프로그래밍과 관련이 있고, 해당 언어에서 @는 기호입니다.)
사용자 멘션을 억제하는 깔끔한 방법이 있을까요? 가져오기 전에 게시글을 사전 처리하는 것은 괜찮습니다.
어떤 식으로든 더러운 임시 해결책으로, @ 뒤에 빈 bbcode 태그를 삽입하면 작동한다는 것을 발견했습니다(예: @[b][/b]global). 하지만 이 방법은 매우 좋은 해결책이라고 느끼지 못하며, 코드 블록 내에 있는 문자열에는 bbcode가 삽입되지 않도록 해야 하므로 마크다운을 파싱/토큰화해야 합니다. 따라서 좋은 해결책이 아닙니다. 영공백(zero-width space)도 사용자가 코드 스니펫을 자신의 소스 코드로 복사할 때 이상한 오류를 유발하므로 해결책이 될 수 없습니다.
코드 블록 안에 있다면 문제가 되지 않습니다. 항상 코드 블록 안에 있도록 할 수 있다면 걱정할 필요가 없습니다. 다만, 코드 블록 안에 있는지 확인하려면 실제 파서를 실행해야 합니다.
아니면, 데이터를 가져오는 동안 Allow users to mention other users 설정을 끄는 것도 방법입니다.
네, @name이 코드 블록 안에 있다면 문제가 되지 않습니다. 문제는 그것이 코드 블록 안에 있는지 아닌지를 감지하여, 코드 블록 밖에서 핑이 발생하지 않도록 @와 name 사이에 보이지 않는 [b][/b] 태그를 삽입하는 것입니다. 이를 위해서는 실제로 완전한 마크다운 파서/토크나이저가 필요합니다.
음, 나중에 게시물이 다시 생성(rebake)될 경우에도 그 설정이 여전히 적용되나요? 아니면 그런 상황에서 무작위 핑이 발생하게 되나요?
다시 처리될 때 알림과 언급을 피하기 위해 Wyeth로 전환된다고 생각하지만, 코드를 확인해 본 적도 없고 직접 시도해 본 적도 없습니다.
핑을 방해하는 요소는 보이지 않습니다. 제 이해로는 변경 사항이 클라이언트에 직접 게시되는 것 같은데 (하지만 저는 루비나 디스코스에 대해 전문가가 아니므로, 틀린 부분이 있다면 수정해 주세요):
저는 이 부분이 문제라고 생각합니다.
bypass bump가 멘토링 재발을 방지하는 것 같지만, trigger post process에는
`new_post: false,`
옵션이 포함되어 있습니다.
그래서 안전하다고 생각합니다.
오, 정말 좋은 지적이에요! 그 부분은 놓치고 있었네요! 완벽해요, 그럼 그렇게 할게요 
그리고 가져오기 스크립트가 이미 이 값을 설정했을 수도 있습니다. 가져오기 작업이 수백 건의 알림을 발생시킨다고 생각하지는 않습니다.