Exercise 3: What a Context Processor Does — Possible Solution
====================================================================

WHAT THE current_year EXAMPLE ACTUALLY DOES
------------------------------
Per this chapter, a context processor is a function (here, site_settings) that returns a dictionary of values to be automatically merged into the context of EVERY template rendered, once it's registered in settings.py's own TEMPLATES configuration. site_settings returning {'current_year': 2026} means {{ current_year }} becomes usable in any template, anywhere in the project, without that specific view ever needing to include it explicitly in the dictionary passed to render().

WHY THIS IS A BETTER FIT THAN PASSING IT FROM EVERY VIEW
------------------------------
Per this chapter, without a context processor, every single view function that renders a template needing current_year would have to remember to add 'current_year': 2026 to its own context dictionary individually - a repetitive detail easy to forget in any one view, and something that would need updating in many separate places if the value or its source ever changed. A context processor centralizes that concern in one place, guaranteeing the value is available everywhere consistently, the same "shared, always-available data" goal Next.js's own layout component achieves by simply always rendering - just reached here through Django's own request-scoped context mechanism instead.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that a context processor automatically merges its return value into every template's context project-wide, and correctly explains why this centralization is preferable to manually repeating the same value in every individual view's own context dictionary.