Laravel Translations: Store in PHP or JSON Files?

One free lesson from my newest course about Multi-language Laravel.
Full course: laraveldaily.com/course/multi...
- - - - -
Support the channel by checking out my products:
- My Laravel courses: laraveldaily.com/courses
- Laravel QuickAdminPanel: quickadminpanel.com
- Livewire Kit Components: livewirekit.com
- - - - -
Other places to follow:
- My weekly Laravel newsletter: us11.campaign-archive.com/hom...
- My personal Twitter: / povilaskorop

[@MPDubois11]

I just wanted to say a big thank you to you for all your videos. They are amazing.

[@MPDubois11]

I just wanted to say a big thank you for all your videos. They are amazing.

[@danygagnon8446]

In production, I use a JSON file for the simple reason that it is universal. Not only that, but typically, translators are used to translate JSON files, not PHP files. Also, for JavaScript, I can just grab the JSON file and obtain free types for the file in TypeScript. There are drawbacks, but they are easily fixable if you create a dashboard to manage translations that can read, update, etc., this JSON file. One of the useful features is the search option to see if a given translation is present.

[@ElJuniorSenior]

JSON file is better, i like that.

[@J87NL]

For blade files there is the @lang(…) directive as well. For more flexibility and to give clients the possibility to update/edit the translations I’ve seen in projects that the translations were stored in the database (and retrieved and hopefully cached into translation files).

[@nobel1378]

Thanks a lot for this great explanation.

[@ercank1137]

Thank you!

[@development2301]

Thank you

[@tharushafernando6688]

I worked on a project where they had entire module for adding new languages and translations. All the translation were stored in the db and cached with a scheduled job. In the helper the get the cached translations and get the appropriate translation. Seems to be lot of work but it worked fine and didn't had any performance issues either

[@cardboarddignity]

Just a few notes to add. 1. I suggest to stick to one single folder, preferably /lang, since if you already have /lang folder and some plugin will publish their own lang files into /resources/lang (BTW the case with laraveldaily/invoices package as I recently discovered), all your translations from /lang folder won't be visible. So keep it in mind, since Laravel (yes, even new one) prioritizes /resources/lang for some reason. 2. For translations by non-developers, there are packages that adds strings to DB so they can translate it on live via user interface; 3. NEVER EVER mix both methods in a single method. If your team uses php, use php. If your team uses json, use json. Project's code should be consistent and standardized

[@momahdy]

Good video, you can also use multiple json files under en/ directory

[@giacomogaravaglia6742]

I personally use php. In my case i say to the dev team to "don't translate" the dot syntax, then run a custom command that puts dot translation in proper file (if not already contained). Using this method i can focus on development process instead of translation, and all the translation are automatically added in all languages.

[@RexTangle4]

We use PHP, but we've just added a vue frontend and I wish we had json files so we could re-use them

[@DeTechDivus]

How would you handle multi lang translations, whould you use spatie translations or json based ones with way to load translations from file designed by user?

[@medilies]

I made this package elaborate-code/laravel-json-tongue that helps split a large JSON to many and gives freedom in naming the files

[@akinoreh]

What about gettext & po files?

[@MatejSK1]

What if i have placeholders which are given by js file to the laravel blade? How can i make an lang text for those placeholders, so when the user on the website will switch the lang button it will aswell change the placeholders on the table?

[@spicynoodle7419]

You probably need to expose the translation files so you can fetch them, dynamic import them or straight up import them into the bundle

[@emrekapukaya5795]

First thanks for this great video, i want to manage my translations on admin panel so is there a any package for this ? I want update json or php file dynamicly.

[@LaravelDaily]

This is a video about one package: kzbin.info/www/bejne/oorOmIukrNOJmNk

[@yacobee]

and what is the best way for making admin for a title to be stored in database?

[@LaravelDaily]

There are packages for that

[@janfornication]

The json files are a nightmare for third parties who translate them. Because the context is missing and that is in my experience the most effort when working with third parties, the question "in which context is this". With the PHP files, you can counteract this with nesting and comments. But that is not perfect either. The best thing I have seen so far is the language system of Qt together with the Qt Linguist.

[@truewebdesign3263]

No. Pretty easy. Create a language tables to store all languages for edit. On edit from a views file/page. Allow users select the language to edit. And store to database table and as well convert data to update existing .json file.

[@janfornication]

Hey, you're missing the point. Of course you can offer a view. However, the Laravel Translator lacks context. You will notice this when working with translation agencies, because in many cases they cannot simply translate the "key" 1:1, because idioms and terms can differ. For this you need a third value and that is the context or a comment. The latter is only possible in a PHP file.

[@necmettinb]

What stops me from using auth.register.name in a json file?

[@bulent2435]

İt worth to mention there is nothing to stop us using whole sentence as key in PHP files.

[@moauyameghari]

Thats right! I use them and it works fine

[@modestasmv]

You are technically correct. The only issue is what happens in these cases: - No translation key found. You'll get a `filename.YOUR Translation here` put out to the user. While in JSON you'll get `YOUR Translation here` without a key - much cleaner. - If you have a `period` in your translation. PHP based files will treat it as an attempt to go to a specific key, while JSON doesn't really care about it. So while you can, there are always tradeoffs. But you are free to choose :)

[@jonkf7548]

For me when both developing and translating context is more important than making it look pretty when the translation isn't created yet and that's why I don't really like the "modern" way people translate their apps nowadays (not just Laravel but some JS frameworks too). Example: Imagine you have an application for trading Pokemon. In your navigation menu you have a list of free Pokemon: {{__("Free")}} And then next to your favourite Charizard you have a button to release/lliberate it: {{__("Free")}} In one language a word might have multiple meanings but in another language you might need to use different words. Even if the meaning can be translated, you might want to use different text on a menu link vs a button vs a data table depending on what fits in the context. And as an aside if you are searching for a bug, it's a lot easier to find occurrences of something like LOGIN_FORM_LABEL_FIRST_NAME than searching your whole project for occurences of the word "name"...

[@spicynoodle7419]

Translation is a joke everywhere, that's why I advise people to never use non-english for their OS because otherwise it's impossible to find settings while following tutorials

[@Farbfilmstudio]

@@spicynoodle7419 You must be from the US...

[@spicynoodle7419]

@@Farbfilmstudio I'm from Easter Europe

[@Darkness_7193]

I don't think that an article rereading is strange. In voice format we can do some simple coding and other routine. Plus this is the channel promotion

[@krims15]

If you feed AI translator with PHP files it can actually translate them more precisely because of given context. For JSON translations you don't have any context.

[@spicynoodle7419]

PHP should be faster to parse

[@LaravelDaily]

But I don't think regular users would actually feel those millisecond differences.

[@spicynoodle7419]

@@LaravelDaily yes, it's 2-3ms at most and isn't much in a world with serverless everywhere. Still I don't like the idea of parsing JSON to get a key and then encode it into JSON again for an API response. To me it feels unnecessary to take an extra step when it can be avoided at no cost

[@webglobesolutions]

Hello sir.. is there any way to give a discount of your courses? $129/year looks a lot to me.. Just a request.. Thank you.

[@LaravelDaily]

All discounts here: coupons.laraveldaily.com

[@webglobesolutions]

@@LaravelDaily Thank you sir!

[@yungifez]

Who translates? Nobodyyyyyy

[@rdvr]

For large amount of content e.g. static about us page could one use multiple views e.g. return view($locale . '.about-us'); ?

[@LaravelDaily]

Well yes, then you need to have those resources/views/en/about-us.blade.php and other languages.