My two cents would be that it's almost always somewhere in between the two extremes you describe.
Certainly having experience with OO in one language will be an advantage when it comes to picking up another OO language but yeah, you're not 100% there. I would posit that you're more than 50% there, though (with this particular example). Understanding the OO concept is more important than the syntax.
You know what I find onerous when I think about learning a new language? It's not so much picking up the new syntax because a lot of the time I find that I can do that pretty quickly (at least if the paradigm between old and new language is not too disparate). It's picking up the ecosystem around the language:
How do I deploy an application written in language X?
How do I package code written in language X (e.g. Ruby gems, Python eggs or whatever)?
Which unit testing frameworks do I learn?
What IDEs or text editors are usually used with language X?
Documentation conventions and related software (e.g. rdoc)?
What community resources are valuable, trustworthy and stable? etc.
When I first started learning Ruby (along with Rails, some years ago now) my web development experience mostly consisted of LAMP and ASP.Net. Deploying Rails apps seemed like such a massive hassle compared to PHP. Part of this was that Ruby as a web dev language was much newer than PHP and was still settling in, parts of it really were a hassle. But I came to realise that a big reason for the difference was that the two communities were conceptually coming at the issue of deployment from very different perspectives and a lot of the differences I was seeing were no accident, and not so difficult to grok when you understand the motivation behind them.
A lot of non-programmers don't get that there is usually a fair amount of transferable knowledge when it comes to picking up a new language that utilises similar concepts to one you already know. But I can also understand that some (probably most) employers want their staff to "hit the ground running" and may be looking for people with a very specific skill set.
Putting myself in the position of an employer and knowing what I do, I'd rather hire Person A that's obviously enthusiastic about learning new stuff, who's maybe contributed to something open source that can be reviewed, and who surely has some background knowledge that they can build on but who may not necessarily have language X listed on their resume, over Person B who does have language X on his resume but that's all they've really got. It would be good if more recruitment firms and HR departments started to realise that having the right acronym/keyword listed on your resume doesn't actually mean much on its own.