In short; I probably wouldn't do it.
The issue here is; that Language Fallback is a mechanism that not only affects your content delivery; it also affects behaviour inside the Sitecore clients themselves (Experience Editor and Content Editor).
These both run in the context of the
For a solution wide approach, see the answer already given here: What is the use of "shell" website in the Sitecore.LanguageFallback.config file
The issue is; once you enable Language Fallback for
"shell", it will take effect on Experience Editor and Content Editor - regardless of what site you are actually editing. There is no way around this; this is just how these Sitecore client interfaces work.
What it means
So essentially; if you want different behaviour by-site, you are going to have to configure separate Content Editing (Sitecore Client) environments per site. The way to do this, would be to configure additional
It's easy enough to do, as such. At least on paper. You can define multiple sites inheriting from your
"shell" site (as shown in the linked answer), and additionally configure them with a
hostName attribute to respond to. The end result being; you go to
"shell" site without Language Fallback gets triggered. And then
www.site2.com/sitecore with Language Fallback enabled.
But your editors would need to log in and out using different host names, and I don't really think they're going to appreciate this.