This problem isn't isolated to non-native English speakers. The potential cost of poorly named methods/variables/classes, etc. is high enough on a complex product that it's almost always worth raising the issue in reviews. If your reviews are run positively it really shouldn't be an issue.
As an aside, I recently saw a job listing that included the requirement to be able to "defend your code in reviews" - I would say that's an environment where reviews probably aren't positive experiences.
On the other hand, I could see that as meaning "know what you're talking about so that you can defend the decisions you make."
As an intern, I've had many times where I'd say "I did it this way using A B and C, is that the best way? Are there any improvements you'd suggest?" after completing work. But in a more senior position, you probably don't want people second guessing / not really understanding these decisions.
I have no problem with anyone, from interns on up, constructively criticizing my code/architecture/design decisions. I work for a company with an exceptionally strong engineering culture and no one shies away from expressing an opinion when invited (and sometimes when not invited). That said, "defend" is a poor choice of words for code review. If someone asks me why I did something, I tell them. It's not a defense, it's an explanation. If they have a better way to do what needs to be done that's GOOD. If we disagree, we discuss why we disagree. Defending is what you do when someone's attacking you, not when you're collaborating.
As an aside, I recently saw a job listing that included the requirement to be able to "defend your code in reviews" - I would say that's an environment where reviews probably aren't positive experiences.