Building a Laravel Translation Package – Introduction
Published on by Joe Dixon
Introduction
In this multi-part series, we’ll be documenting the process of building and maintaining an open-source package for Laravel. We will cover everything from bootstrapping the package to dealing with your first issues and pull requests and as much as we possibly can in between.
What Will We Build
During this series, we will build a translation package to complement Laravel’s native localization features.
Laravel’s baked-in localization allows your app to handle multiple locales and serve translated content accordingly. Handling various locales is a three-step process:
- Taking content out of your templates and moving into language files stored in either JSON or PHP array-style syntax.
- Tagging up the content in your templates using one of Laravel’s translation retrieval methods.
- Setting the current locale for the app in the
app.php
Imagine you want to serve content in both English and Spanish, and you want to use JSON language files. Create one file called en.json
and another called es.json
in the resources/lang
directory.
In each file, create an object and add a key.
// en.json{ “hello”: “hello”}
// es.json{ “hello”: “hola”}
To render this in a template, you can use the following helper:
// some_file.blade.php{{ __('hello') }}
Now if your app.locale is set to en
, ‘hello’ will be rendered and if set to es
, you guessed it, the view renders ‘hola’.
As your project grows, managing these files can be challenging, and our package can help with this challenge. We’ll build the ability to scan your project for missing translation keys and adding those missing translations to your language files. We’ll handle syncing language between multiple locales as well as adding a database driver to help in multi-server environments.
We will use a combination of Tailwind CSS and Vue.js to build out a user-interface for translation management which will ship with the package.
The UI will allow you to add new, update existing and delete existing translations as well as add new locales.
Why Are We Building It?
I am doing this for two reasons. First, language management is something I need in lots of my projects. Though there are good packages out there, none entirely suit my unique requirements.
Second, I don’t currently maintain any open-source projects, and it is something I have always wanted to do. This series will be a learning experience for me, and I feel documenting this process will hopefully be beneficial to others looking to embark on the same challenge.
I’m excited to start this journey and look forward to sharing my experiences with you. If you have any questions or feedback along the way, feel free to reach out on Twitter.
Next up, we are ready to start scaffolding the project in Part 2!