The first translation is ok…ish. But the second? Not really, is male-focused: activ vs activă. ![]()
How can we ignore or hide this call-out for certain categories?
Each category is wrapped with its own class, so something like this:
.category-feature-announcements { // Hides it in Feature > Announcements
.post-notice {
display: none;
}
}
[class*="category-feature"] { // Hides it in Feature and all of its subcategories
.post-notice {
display: none;
}
}
[class*="category-feature"] is a wildcard attribute selector if anyone is wondering (so it matches anything containing category-feature; it also covers category-feature-example, which is how subcategories are structured). More on attribute selectors.
This has been a fantastic addition to our community, it really encourages people to welcome new members. I would actually like to see this extended a bit so it’s not just their first post. I’d like to see the first post notification stay the same, but then for the next ‘x’ number of posts it still shows a similar banner that they are new to the community since not everyone is going to see their first post, and anyone that did see that first post and welcomed them will likely remember that and not welcome them again.
Something is not quite right with those notes. On one of my instances a post from a user who I know has never posted in the forum at all received a notice
It’s been a while since we’ve seen *** name redacted *** — their last post was nov '18. It turned out that he had written a PM in November.
I’d like to suggest that PMs are not treated as “previous posts” in this feature.
On another instance, a PM that I received from someone who never posted on the forum and who - I believe - hasn’t posted a PM either, received a notice
It’s been a while since we’ve seen *** name *** — their last post was in Aug '18.
I’m not sure where the August 2018 thing comes from if he has never posted… If it’s a PM, it would be another example of the issue above. If I’ m right and he has never even posted a PM, it would be really puzzling.
If the notice is too prevalent, it becomes a crying
and it won’t be effective.
Note that TL0 users still have a light grey username, so if you know what to look for you can still tell if someone is new and act appropriately.
@maja can you ensure we never display that notice for anon users?
Hmm no the anonymization code path would need to remove it anonymization time. Unless this is super super easy I would ignore it for now. So tiny. Also this is still correct in terms of the historical record, that is indeed the first time that user posted, so I am not even convinced this would be a useful thing to do.
I’m not able to reproduce this, seems to be fixed since this commit:
https://github.com/discourse/discourse/commit/476d0050ab80b2dfcaee6368c529f5094f14d79a
Isn’t there a similar feature where admins can leave banner notes above suspicious posts? Who can view the “admin warning” banners?
From community perspective is veeeeery useful Thanks for that
간단한 의견입니다.. 첫 방문 사용자를 위한 공지사항은 좋은데, 왜 개인 메시지(PM)로 표시되는지 궁금합니다. 더 많은 사용자에게 환영 인사를 전하려는 목적이라면, 공개 주제에만 표시되어야 합니다. 가능하다면 사용자의 첫 게시물을 평가할 때 PM에 있는 게시물은 무시되어야 합니다(코드를 직접 확인해 보지는 않아서 구현이 비현실적일 수도 있습니다).
@awesomerobot의 원문을 참고하세요.
새로운 사용자나 복귀 사용자를 제외하고 모든 사람이 게시물 통지를 봅니다. 통지를 전역으로 숨기거나 특정 주제에서만 숨기려면 첫 번째 게시물부터 아래로 읽어보세요. 추가 게시물에서 이 방법을 설명합니다.
내 의도를 제대로 이해하지 못하신 것 같습니다.
나는 게시물 알림을 표시하는 것을 좋아합니다. 이는 참여도를 높이는 데 도움이 되니까요.
문제는 첫 번째 사용자의 게시물이 개인 메시지(PM)인 경우, 첫 게시물 알림이 그곳에 표시된다는 점입니다(수신자만 볼 수 있음).
훨씬 나은 방법은 개인 메시지를 이 목적에서 제외하고 첫 공개 게시물에 첫 게시물 알림을 표시하는 것입니다. 그러면 더 넓은 독자층에게 전달되고, 첫 게시물을 올린 사용원이 많은 멤버들로부터 환영을 받을 수 있습니다.
핵심은 일부 사람들이 개인 메시지(PM)에서도 누군가가 오랜 시간 동안 게시물을 올리지 않았는지 알아두는 것이 유용하다고 생각한다는 점입니다. 하지만 그런 메시지가 개인 메시지에는 적합하지 않다고 생각되면 CSS를 추가하여 숨길 수 있습니다.
수정:
아! 죄송합니다. 그렇다면 그들이 오랜 시간 만에 처음으로 올리는 개인 메시지를 보내면, 그 다음 공개 게시물이 오랜 시간 만에 첫 게시물로 계산되지 않는다는 뜻이군요. 죄송합니다. 저도 그 부분을 놓쳤습니다.
알겠습니다. 약간 엣지 케이스처럼 보이지만, 코드가 어떻게 작동하는지 추측해보면, 그 기간 확인 시 개인 메시지를 고려하지 않도록 하는 것은 꽤 작은 조정으로 가능할 것 같습니다.
이제 이해합니다. ![]()
감사합니다.. 변경 사항이 크게 부담이 되지 않는다면 정말 좋겠습니다!
제 경우에는 에지 케이스가 아닙니다. 모든 회원에게 개인 환영 PM을 보내려고 하거든요 ![]()
아니요, 이는 발생하지 않을 것입니다. 현재 동작은 의도적으로 설계된 것입니다. 다른 옵션은 CSS 수정이며, @pfaffman이 언급했듯이 직접 쉽게 수행할 수 있습니다.

