In short; I probably wouldn't do it.
Background
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 "shell"
site.
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 "shell"
sites.
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 www.site1.com/sitecore
, the "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.
Enable site-level language fallback
sectionshell
sites.shell
can be only one. For me thisYou must enable the attributes on the shell and on each of the relevant websites.
says everything. I might be wrong but I think that quoted part of the docs is incorrect.