I think there are two phases here: the first is just being aware of what the correct idioms and best practices are, and second is attempting to apply what you learned and getting feedback.
For the first phase, you can get a lot of mileage by doing research and casting a wide net. In particular, I personally find the following Google queries to be pretty useful at giving me an overview of the best practices and general "feel" of a language:
- "X best practices"
- "X style guide"
- "X idioms"
- "X common mistakes"
- "X philosophy"
- "X ecosystem overview" (or "X popular 3rd party libraries")
- "X tips and tricks"
- "X history"
- "X advanced features"
- "X linter"
- "X style checking tools"
(Replace "X" with the name of the language. If the language name is common word like "Go" or "Swift", try replacing "X" with something like "Go language".)
This will obviously return a wide range of results, not all of which will be useful, but it's a good way of getting the "lay of the land". Some of the results will be directly useful (for example, you might uncover a popular and comprehensive style guide or a useful linter), and others will be more useful for getting context behind the design and intended use of a language (for example, googling about the language's core philosophy).
Other things I personally find helpful is to browse through the top-voted questions about a particular language on StackOverflow or SoftwareEngineering.SE (previously Programmers.SE). The knowledge won't be immediately useful (or sometimes comprehensible), but it does give you a feel for what sorts of issues programmers using that language tend to worry about, what advanced features people want to learn to use, and what keywords might be helpful when refining your queries.
Something else you can do is to keep an eye on news aggregates for the language of your choice. For example, I like browsing through http://reddit.com/r/python for Python-related news -- every now and then, you run across an article that teaches you something new or reveals a point of contention within the community that's worth keeping an eye on.
Keep in mind that after reading through all of these resources, you'll likely find it hard apply them all at first -- in some cases, you might not even understand the articles you dig up. This is fine: the idea is to be aware of them in the first place so you have a direction to grow towards.
It'll probably be a good idea to start small -- start by finding a style guide and writing your code to be compliant with it, for example. Or maybe try figuring out the recommended best practices for organizing a larger project and using your language's package manager.
The second phase is actually getting feedback on the code you wrote. This can be tricky to do as a self-learner, since you have no direct way of getting feedback, but there are a few things you can try.
One resource to try is CodeReview.SE, though it's probably best to submit relatively small programs for review.
Another idea is to contribute to an open-source project. The more popular projects tend to be relatively picky about following best practices and idioms and will code review your submissions before accepting them. As before, start small: try and find a small and easy bug in their issue tracker, and start with that. It can also be valuable to try googling "open source for beginners" -- that reveals plenty of resources and websites that attempt to connect projects looking for help with beginners.