I'm going to answer off-topic, at least to give some context here.
Like David and Rick said, the answer is "no." But similar to the "favor composition over inheritance" object-oriented design pattern (from how I understand about it in comparison to Blueprinting), it is probably best to apply localization sparingly. Community member Manuel Garrido even coined the term, "minimizing localizations" as a good practice.
I'd say you're on the right track and here are items you may want to reduce localization and how.
As you create a content model, certain items should or shouldn't be localized based on the BluePrint.
Items that should be localized (or are at least okay to localize):
- Components for translation or region-specific localization (articles, labels, etc.)
- Structure groups for path "localization," if desired (but it can make it harder to separately manage page localization)
- Schemas for Publication-specific or editor-specific descriptions (if you really want to)
Considering letting certain editors keep the localize permission for these.
Things that are harder to manage when you localize them:
- Containers or link list type components
- Templates (I've rarely recommended this)
- Folders, if you can avoid it. Sometimes you might localize for permissions or metadata, but use as needed.
- Pages, if you can avoid it (to be able to manage the content globally)
Most of these tend to be global or system-specific items and you can remove the localize permission for the organization item containing them. It's probably a good idea to put global items in global folders. Users will still need read to select templates.
There are a few options when you need to assemble, or dare I say, "compose" some set of content or functionality for a given page.
- If editors control the specific set of content in the context of a Publication for a given page, only localize a container component on the page but leave the page shared. The placement and rendering/template of the page remains the same, with local flexibility for the items in the container.
- If the set of content depends on the visitor's attributes and the context and rules are known, use the Content Delivery APIs (Taxonomy and Criteria filters) and possibly the Ambient Data Framework to create the selection of content during the visitor's session. The classic scenario is to present a list of articles in reverse sorted order by date.
- If the rules are not known, nor even which page the content should appear on, consider a personalization implementation using Experience Optimization or other solution.
Anyways, the point is to separate parts of a page and a content model (but not too much--consider the editors!) so the modular parts can be managed easily and localized (or not) as needed.
And in practice, it's hard enough to implement a proper authorization model. I suspect going one step further to prevent localization at an item level would be tedious for implementers and editors.
