Add domain/category to Translations

[fabiomlferreira]

I'm working with Yii2 for some years and now I'm moving to Laravel but I'm facing a problem with translations. There are no easy way to categorize a translations for example if we have a backoffice and a frontend, usually it's more important to translate the frontend but when I'm developing I want to make every thing translatable. In Laravel to do that I need for example to use the following code __('backend.homepage_title') and ('frontend.homepage_title') but if I use this on my views and don't create the translation files the user will see this weird text "backend.homepage_title", the alternative is to create something like this ('Welcome to admin area') and __('Welcome to homepage') but with this approach I don't have any way to categorize what is translations from backend and from frontend.

In Yii2 we have this function Yii::t('backend', 'Welcome to admin area') and Yii::t('frontend', 'Welcome to homepage'), with this even if I don't create any translation file the user will see the correct message in english and if I create the translation file I will get one for the backend and other for the frontend.

For example Wordpress have a similar feature where we can put the text in the main language and assign a category to that translation.

For me this is a really useful feature and I don't understand why Laravel don't support it.

For example if you outsource the translation service, how did the translator know what should put on something like "backend.homepage_description", it's way more simple to translate the real phrase in the main language.

[mfn]

I think you might want to look into the option for using the json instead the php based format => https://laravel.com/docs/7.x/localization#using-translation-strings-as-keys

It says:

For applications with heavy translation requirements, defining every string with a "short key" can become quickly confusing when referencing them in your views. For this reason, Laravel also provides support for defining translation strings using the "default" translation of the string as the key.

But AFAIK it doesn't have the ability to "categorize" like you're used to it.

[fabiomlferreira]

@mfn Yes I know that I can add the translations as a regular string but this don't help me anything, it's very important to assign a category/group/domain (what you want to call it) to each translation to easily translate only what we want.

I think almost all framework have ways to assign a domain to a translations, Yii2 have it, Wordpress have it, Symfony have it (https://symfony.com/doc/current/translation.html#the-translation-process). For me at this point is hard to understand how a framework like Laravel grow so much and don't have this basic feature that will help alot the developers.

I think Laravel should have something like __("Text to Translate", [], 'domain') this is inspired on Symfony, it's important to add it in a way that don't break code. @JeffreyWay @taylorotwell I would like to know your opinion about this.

[staudenmeir]

I agree that this would be a great feature, especially for JSON translations.

I've had cases where I needed to differentiate between two terms in other languages that translated to the same word in English and I couldn't use JSON translations.

It would also be a good way for packages to namespace their JSON translations.

[fabiomlferreira]

I agree that this would be a great feature, especially for JSON translations.

I've had cases where I needed to differentiate between two terms in other languages that translated to the same word in English and I couldn't use JSON translations.

It would also be a good way for packages to namespace their JSON translations.

Exactly there are too many situations where this is useful, have individual translations for packages if one good example. In wordpress we have many plugins and each plugin can have different translations.

I hope this can be a reality in Laravel very soon.

[mfn]

have individual translations for packages if one good example.

FTR, this is supported, please see https://laravel.com/docs/7.x/packages#translations

Package translations are referenced using the package::file.line syntax convention. So, you may load the courier package's welcome line from the messages file like so:

The part of the docs isn't specific and given @staudenmeir comment I infer it's not working for the JOSN format?

[staudenmeir]

@mfn It's supported for "normal" translations but not for JSON translations. I use loadJsonTranslationsFrom() to load them in packages, but they could interfere with translations of the application or other packages (especially when translating single words).

AFAIK, I could only namespace them by adding a prefix to each key:

{
    "package::I love programming.": "Me encanta programar."
}

[fabiomlferreira]

@mfn Ok this can help when we use packages but and without packages?

What is show to the user if we use __('package::I love programming') and we don't have a translation file associated, it will print only "I love programming" or will print the all string 'packages::I love programming'.

We must have a way to quickly insert the desire text without need to create translation files, like we can do in almost all frameworks, we must have a method that accepts the default text and print it if there are no translation associated and accept an argument that is the "domain" of that translation.

[michaeldyrynda]

I think for the JSON files you need to use loadJsonTranslationsFrom, and loadTranslationsFrom for the regular PHP/array file type.

[mfn]

Also slightly related: https://github.com/laravel/ideas/issues/2200 ("Make translation process translators friendly")

[fabiomlferreira]

Also slightly related: #2200 ("Make translation process translators friendly")

Yes is slightly related but my request is to add a domain to translations like other frameworks do, the translation method should accept the domain as as extra argument, and the text that should be translated can be clean and if the is no translation file this text is shown by default.

[dalibor-sojic]

My request is related with translation process. The localized (translated) files should be compatible with software used by translators. Firstly, we have to check what software are used by translators, which file formats are readable by that software, do they have "domain" property...

Mainly, do not think as developer for this issue.

[mfn]

@liveNetworks thanks for also chiming in here!

That was exactly the reason I made participants in this issue aware of your request because if one would touch the the system it makes sense to have better idea of the vision people are having.

[burzum]

There is also context besides domain and you can also combine context and domain. For example CakePHP provides __d($domain, $string, $args) for domain and __dx($domain, $context, $string, $args).

I don't think this is easy to implement in the existing translator imlementation of Laravel without backward compatibility breaking changes. All of this information would have to go somehow into what is right now just a flat array. I wouldn't mind to work on improving this but I would like to discuss a way to make it possible before doing so.