Level 27
@JillzTom there is no need to write a view for each language you have. It does not work this way. You have to write a translation for each language and then use the trans helper inside your view to load the translated messages.
3 likes
Feb 11, 2016
10
Level 10
Localization in Laravel
I'm trying to use the package: https://github.com/mcamara/laravel-localization for adding multiple languages to my app.
I've installed everything and I can change the language to
example.com/en/about
//or
example.com/es/acerta
Now how can I route the call to the appropriate language view? I mean when I hit the url example.com/es/acerta how can I show the about page in spanish?
I tried something like this in my PagesController:
protected $language;
public function __construct()
{
$this->language = LaravelLocalization::getCurrentLocale();
}
public function aboutPage()
{
return view("pages.$this->language.about");
}
This would choose the view according to the current language selected.
But this would create multiple sets of views for each language with translated content.
Is this the way to go about it?
Level 10
@usman So I should save all translated content along with the html markup in the lang folder?
Level 27
Here is a simple example that translates a welcome message in Russian.
First of all, the following directory structure is required:
.
├── en
│ ├── auth.php
│ ├── pagination.php
│ ├── passwords.php
│ └── validation.php
└── ru
└── site.php
Here are the contents of the lang/ru/site.php file:
<?php
return [
'welcome' => 'Добро пожаловат',
];
Now to translate this message inside our default welcome view, we will first need to set the locale to Russian and then use the trans helper to retrieve the message:
//route
Route::get('/', function () {
app()->setLocale('ru');
return view('welcome');
});
View:
<body>
<div class="container">
<div class="content">
<div class="title">Laravel 5</div>
{{trans('site.welcome')}}
</div>
</div>
</body>
and here is the screeshot of the outcome:
Hope things are clear now.
Level 2
But what if someone wants to use the different routes, will the ru locale still available over there??
Level 27
@sadhakbj I was not teaching practices. It was just a simple example to reduce the confusion of the OP. Believe me I can write a whole article on this one regarding "bad practices" and "good practices".
Regards.
Level 2
We too have a website in multiple languages, and some of the languages need slightly different webpage layouts (HTML) in addition to text translation. So, we needed to be able to serve up different actual blade files depending on the language. Our solution has worked really well for us:
- we "defined" a directory structure for views to be something like "<locale>\<view file path>" with a "<default>\<view file path>"
- we overloaded the default global view() function in the boostrap/CustomGlobals.php file. The overloaded function first looks to see if a <locale>\<view file path> view file exists. if so, then it loads up that file, if not then it loads up <default>\<view file path> file.
- we made sure to fully utilize Blade's templating capabilities so that only minimal HTML is duplicated and the vast majority of HTML is @included or @extends as appropriate.
- we created one other global function called i18n() in the boostrap/CustomGlobals.php file. This function does basically the same thing as the overlaoded view() function, except that it is meant to assist @include() Blade function. When we include a view file via: "@include(i18n('viewFile.path.here'))" if a <locale>\viewFile\path\here.blade.php file exists, then the i18n() function returns "<locale>.viewFile.path.here", otherwise i18n() returns "default.viewFile.path.here". Either way, the @include() Blade function thus loads up the correct localized or default view file.
One downside to this approach is that you end up with blade files that have duplicate names, so you have to be careful which you have open when editing something. Good Blade file commenting can make this a trivial aspect though.
The major upside to this approach is that we don't have to us a bunch of "@if($locale == 'en_US') ..... @elseif($locale == 'es') ..... @else ..... @endif" statements in the Blade files which would have gotten very messy very quickly.
Hope that helps!
1 like
Level 10
Is it good? It seems to require a lot of setup to work, I have been using this which are much simpler https://github.com/overtrue/laravel-lang
But maybe the one I use isn't as powerful?
Level 2
Oh, I didn't mean that my above proposal should be used as a replacement for text translation libraries such as the one you mentioned. Rather, I meant that if you have need for HTML to differ between locales, then you could use a setup like I described above to localize HTML in addition to using your translation library to localize text.
1 like
Level 10
I see, I completely misunderstood the purpose of the package then.
Level 1
@si-andrew Having different HTML content for a multilanguage content is not the good approach. What if you want to edit a file ? You will have to edit all the others contents to fit the website coherent. As @usman you should use the trans or __() on which Laravel version you are using. This link can help you sort out http://www.blog.ksoft-solutions.com/understand-internationalization-localization-with-laravel-php/
Please or to participate in this conversation.