Feature Request & Technical Inquiry: Implementing Database-Driven Multilingual Auth Pages

Hello DevDojo Team,

First and foremost, thank you for the excellent work on the devdojo/auth package. We are using it in a project with Filament and are highly impressed with its functionality.

We are writing to you today for guidance on a specific implementation challenge and to propose what we believe could be a valuable feature for many users: making the authentication pages fully translatable via the database.

Our Core Objective

Our goal is to give our client the ability to manage all texts for the authentication pages (Login, Register, Password Reset, etc.) directly from the Filament admin panel. We aim for a fully multilingual setup (initially English and German) using a database table and spatie/laravel-translatable, so that content can be updated for any language without requiring developer intervention or code deployments. This is a standard workflow we use successfully for other models in the application.

The Technical Foundation We Have Built

To achieve this, we have already set up a robust backend system:

Database & Model: We created a global_translations table (group, key, text (JSON)) and a corresponding GlobalTranslation Eloquent model using the Spatie\Translatable\HasTranslations trait.

Filament Resource: We built a fully functional Filament resource for this model. It allows us to create, edit, and delete translation keys (like login.headline) and manage their content for each language seamlessly, complete with a LocaleSwitcher.

Our Amazing Sponsors DigitalOcean View Website DigitalOcean offers a simple and reliable cloud hosting solution that enables developers to get their website or application up and running quickly. Laravel News View Website Laravel News keeps you up to date with everything Laravel. Everything from framework news to new community packages, Laravel tutorials, and more. Genesis View Website A Laravel Starter Kit that includes Authentication, User Dashboard, Edit Profile, and a set of UI Components. Translation Service: We created a dedicated AuthTranslationService class. This service fetches all auth group translations from the database, caches them for performance, and provides a simple get('key.name') method to retrieve the correct string for the currently active locale. The cache is automatically cleared whenever a translation is updated.

This entire backend architecture is complete, tested, and works perfectly.

The Challenge: Overriding the Auth Page Views

Our only remaining challenge is to make the frontend auth pages use our AuthTranslationService. We have been unsuccessful in overriding the default Folio/Volt views, specifically pages/auth/login.blade.php.

The system consistently ignores our override files and continues to render the original views from the package, which read from the config/devdojo/auth/language.php file.

A Detailed Summary of Our Attempts

We have meticulously followed standard Laravel procedures to override the view, including:

Standard Vendor Override: Placing our modified login.blade.php at resources/views/vendor/auth/pages/auth/login.blade.php.

Custom Service Provider (View Namespace): Creating a CustomViewServiceProvider, registering it in bootstrap/app.php, and using View::addNamespace('auth', resource_path('views/custom-auth')) to prioritize our custom directory.

Custom Service Provider (Folio Path): Modifying our CustomViewServiceProvider to directly register a prioritized Folio path using Folio::path(resource_path('views/custom-auth/pages')).

Comprehensive Caching: After every single attempt, we have cleared all relevant caches using php artisan optimize:clear, config:cache, view:cache, route:cache, and have even manually deleted the contents of bootstrap/cache/ and storage/framework/views/ to ensure a completely clean state.

The Definitive, Conclusive Test

To be absolutely certain, we performed a final test. We placed a at the very top of our override file at resources/views/vendor/auth/pages/auth/login.blade.php. After clearing all caches again, the login page still rendered the original view normally. The die() statement was never executed.

This provides definitive proof that the application's boot process is, for some reason, completely ignoring the standard Laravel mechanisms for overriding a namespaced package view in this specific Folio/Volt context.

Our Questions & Feature Suggestion

Given this, we have two main questions:

What is the official, intended way to override the devdojo/auth page views? Is there a specific configuration, event listener, or registration method required for Folio/Volt pages that we have missed?

If a direct override is not intended, what would be the recommended approach to hook into the system to replace the language source from the config file with our database-driven service?

We believe that a documented, straightforward way to make these essential user-facing pages fully database-driven would be a fantastic and powerful feature for the devdojo/auth package, especially for agencies and developers building client sites.

Thank you for your time and for considering our detailed inquiry. Any guidance you can provide would be immensely appreciated and would help us build a better product for our client.

Best regards,

Vengels, from Costify3D