The Laravel News site has posted the latest part of their "Building a Laravel Translation Package" series focusing on a pre-launch checklist of items to get in place before it's finally released.

In the last part of the series, we finished up building the Laravel Translation package. With this completed, we are ready to start thinking about releasing the it to the world. However, before we do, there are few important steps we need to take.

The post covers some of the final non-code items to take care of:

• Good documentation
• Defining contribution guidelines
• Providing issue templates for easier reporting of bugs/issues by others
• Selecting a license
• Setting up continuous integration for running tests, checking code style, etc.

Each item in the list includes a brief summary of what's involved and, for some, links to other resources and tools that can help get it accomplished.

On the Laravel News site they've posted the latest tutorial in their series covering the creation of a translation package. In this latest article they cover the creation of the database driver to replace the previous file-driven content handling.

In the previous article of the series, we talked about how to handle missing translations, which brings us very close to making the package feature complete. To finish up the build phase of this series, we will discuss how we go about adding a database driver.

Thanks to defining the interface for the data handling previously, redefining the handler for the database is simpler. He includes the code for:

• the migrations to create the languages and translations tables
• the models for both tables and their relations to each other
• creation of the database driver using the interface

His code includes methods for getting either single or multiple translations including fetching them by language. He then updates the "resolve" method to allow defining the driver to use in the configuration rather than being hard-coded.

The Laravel News site has published the latest part in a series covering the creation of a translation package for use in a Laravel-based application. In this new post they focus on how the package will handle missing translation keys.

In the last installment of this series, we talked about building the frontend translation management tool. In this article, we are going to move away from the frontend and follow the process of building another backend feature.

One of the most frustrating things about translation management in a Laravel application is forgetting to add translations to the corresponding language file. This has the undesirable result of either the translation key or the default language being rendered on the page rather than the translation for the current language.

To remediate this issue, they design the package so that it will search the whole project and return the keys that don't have translations currently defined. They walk you through the creation of this functionality complete with the configuration and code required to locate the missing translations and update the configuration to add them.

The Laravel News site has posted the latest in their "Building a Laravel Translation Package" series of tutorials with a new post focusing on the frontend and getting it connected to the backend functionality.

In the last installment of this series, we talked through the process of manipulating the translations in our application’s language files into a format where we are now in a position to start interacting with them. In this article, we’ll be wiring up the frontend ready to start building out the user interface which will aid users with the process of translation management.

The UI will be developed using the community favorites, Tailwind CSS and Vue.js.

The tutorial starts with the approach for the functionality, taking a more hybrid approach and using a balance of backend and frontend for the majority of the functionality. It then starts in on the technical parts to connect the two halves:

• adding the required routes
• creating the controllers
• building out the views to render the interface

The majority of the post is then dedicated to the creation of the assets - the Javascript and CSS - to create the "framework" the functionality will use to work with the translations.

The Laravel News site has continued their series of posts covering the creation of a Laravel translation package with part two of the series. In this latest article they build on part one's introduction and start to build out some of the scaffolding for the package.

In Part 1, we introduced that this series would cover the process of building and maintaining an open-source package for Laravel. Check it out for an overview of what we’ll create in this series. Next, we are going to get to work on scaffolding a new Laravel package.

The post then walks you though the basics of scaffolding a package including:

• repository setup
• Composer configuration creation
• defining the package structure
• the creation of a service provider
• testing

Examples of the Composer configuration are included but the remainder of the points will be developed over the next several parts of the series.

The Laravel News site has kicked off a series of posts sharing some of the experiences from Joe Dixon about the creation and maintenance of a Laravel translation package.

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.

In this first part of the series he goes over some of the basics:

• why they're building the tool
• what they're planning on creating
• how they're expecting it to be used

There's a bit of background about the tools they're planning on using and pseudo-code of how it will work.

On the Pineco.de blog there's a new post for the Laravel users out there showing you a simple way to integrate translations handling into your models. This functionality allows you to more easily build multilingual applications without having some of the overhead of a separate translation framework.

Making you models translatable could be an issue, especially if you are running an application that is multilingual. For static texts, we can use the built-in translation engine, but for models, we need to solve a more complex issue. Let’s take a look at a simple yet flexible solution.

While the post starts with a recommendation to use a full package if you need a more robust system, it quickly moves into the simpler structure they'll be defining. The tutorial describes the "translation mechanism" from a high level and includes the code to create the database table for holding the translated content. With that in place, next up is the model to connect the application with the table and a trait to house the translation logic. This is then used directly in the template (as a translation property) to fetch the translated version of the content.

Jeff Madsen has a new post to his site showing you how integrate Laravel's translations strings with a Vue.js frontend making it simpler to maintain only one source for the translation of content in your application.

One issue you will face if you need to make a multi-lingual site is how to keep your translations organized for both your back-end framework and your javascript components. I’m going to demonstrate the basic technique for this, using Laravel and Vue.js for my example.

While his examples make use of Laravel and Vue.js, the approach is agnostic of most tools and could be modified to integrate with other technologies pretty easily. He builds a system where the translations are kept in PHP files which are converted into something Vue can read and use. He starts with the backend, showing how to use Laravel's localization functionality to set up the files and shift between languages. He then makes use of the lang.js library to pull the contents of these files into Vue and adds in a bit of code to push those values into components.

The JoliCode site has posted a tutorial for the Symfony users out there sharing their method for properly managing translations when using the framework.

We already wrote about our Symfony translation workflow some years ago. But since 2015, lots of things have evolved and it was time to update this workflow.

The aim stays the same, keeping app translation simple and fluent for all stakeholders of the project. To achieve this, we had chosen an external tool: Loco, which centralizes translation data, and a piece of code written to synchronize it with Symfony translation files.

The article talks about the two main methods (bundles) used in the Symfony ecosystem to manage translations but they couldn't connect them with their chosen tool (Loco). The tutorial then shows how they moved to using the php-translation bundle and how to use the Loco UI to manage the keys connected to it. It also covers the use in testing, migrating to production and what's currently missing from Loco they'd like to see.

In an effort to reduce some of the complexity and possible differences in the translated versions of its documentation, the Symfony project is removing those from the main website and splitting them into their own sections.

A few days ago, we updated the documentation section on symfony.com to remove the French and Italian community translations. From now on, on this website you will only find the original English documentation.

The main reason behind this decision is that when developers browse the documentation published on symfony.com, they must be sure that the contents are always the right ones. In the case of a translation, this means that all its contents in all branches must always be perfectly synced with the original English version.

The English version sees quite a bit of activity and the translated versions (with a lower contributor count) aren't always in sync. They've split out two of the translations and will now have them coordinated each by their own community leader: French and Italian