Blade tag to translate output

[bkilshaw]

Curious what everyone’s thoughts are on blade tags that automatically pass the output through the translation functions?

Currently:
{{ __(“foo”) }}

Future possibility:
{__ “foo” __}

Somewhat minor change but it would cleanup apps that are multi-lingual and have to translate all output everywhere. It also would clean up code when it’s not just a straight string

{{ __(Auth::user()->location->name) }}

{__ Auth::user()->location->name __}

[bkilshaw]

An alternative and potentially better option would be to have an app wide configuration option that tells {{ }} to automatically translate everything that it outputs. That way a multilingual app could set the configuration option and forget about it.

[Angel5a]

No way.

Do you want "Johnny English" to become "Johnny Inglese" would you put {__ Auth::user()->name __} into template?

[bkilshaw]

Do you want "Johnny English" to become "Johnny Inglese" would you put {__ Auth::user()->name __} into template?

That's not how translations work in Laravel?

[Angel5a]

It works exactly that way. Try yourself.

1. Setup Laravel-Lang.
2. Publish and use Italian translation.
3. Write code in blade <span class="text-gray-500>You are logged in as:</span> <span class="text-green-600>{{ __(Auth::user()->first_name) }}</span> <span class="text-green-400>{{ __(Auth::user()->last_name) }}</span>
4. Login as 'May April'.
5. You'll be surprised to see 'Maggio Aprile'. But May won't be so happy.

[bkilshaw]

Your first and second example are very different; in your first example you suggested that __("Johnny English") would appear as Johnny Inglese which is not the case unless you had a translation key that translated "Johnny English" => "Johnny Inglese".

Your second example does a better job at highlighting the potential issues with the global config suggestion.

[Angel5a]

Sorry, my fault. I had to be more specific at first comment.

[Pilskalns]

Hi,

I was looking for quite similar "issue". I do use blade translations a lot, basically anything thats visible as text, and my feel is that there should be shorter syntax for translations.

My thinking was to go with something that is less cumbersome to type, is minimal and uses one of the bracket types so text editors intuitevely put a pair of them and cursor in the middle.

I.e. {("foo")} or {($foo)}

With named parameters:
{("foo", ['key'=>'value'])}

And passing locale:
{("foo", "lv")}
{("foo", ['key'=>'value'], "lv")}

When compared to current method {{__("foo")}}, the above is 4 characters shorter.

Underneath it would pass the parameters to trans(...) helper

There is a way how to register tags for some custom components, but not exactly to extend template syntax. Did some more source code reading, I see the way how to build it, but would need some time to come up with proper PR.

P.S, I'm still in some doubts about whether pair of curly + curved brackets is the right choice - they do look quite similar and could be missed at a glance and cause bugs. Could use curly + square brackets, but then nested replacement parameter array looks not the best. I.e. {["foo"]} and {["foo",['name'=>'value']]}

So, some compromise must be chosen, if at all and live with existing, which functions, yet there is that inner wish for it be a touch more elegant.

[Angel5a]

Nice syntax. But it's hard to tell the difference between {{$foo}} and {($foo)} in blade template. I like that no escape {!!$foo!!} is screaming at least that way.

[Angel5a]

Short, ugly, but easy to implement @t($foo).

[Pilskalns]

Yeh, the whole point of this would be to make it quick to type, intuitive to understand and easy to see the syntax over the {{__(...)}}, if not possible, then not worth doing it.

The raw echo {!! ... !!} is not as commonly used and is dangerous when used in wrong place, so very rightfully it should scream.

[rojtjo]

The @lang('foo') directive still exists, but is no longer documented. You can read up on it in the v7 docs: https://laravel.com/docs/7.x/localization#retrieving-translation-strings

[Pilskalns]

I'm aware of it, thanks.
As in your link, there is a notable difference - @trans(...) directive does not escape output.