A bit provocatively I would say: never!
For example, you could say you know Ruby maybe because you've developed Ruby on Rails applications for years. But have you used Ruby in all its possible applications? Odds are saying that no, you haven't. In that context, you know the syntax, but probably not much more than that, since the context is so different to what you're used to.
What do I mean by that? That it's a bit pointless to say "I know language X" because it's a temporary and secondary skill: I was very proficient in Python, but I haven't used it for a while so now I have to look up the documentation constantly; if I started working daily with it I would get back to "expert" level very quickly.
What is more important is: are you experienced in that domain? For example if you are familiar with the formalities of Functional programming, learning Haskell, Erlang, Scala or Clojure wouldn't take you a long time/effort. If you know the concurrent/parallel computing domain does it matter that much if you have to write Go, Rust, Java or C(*)?
Programming languages don't tell you much. The kinds of problems you solved with them tell much more about you and the potential you can have in a certain field. Do hiring companies agree? Sadly quite often they don't...
(*) In the case of C you have the added problem of memory management, which of course is not really secondary. This is the trade off of lower-level languages, and the only language-related aspect that really matters. It is a domain in itself, and it's special because C/C++ are the only common programming languages with manual memory management that are still around.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.