Add category to translations

[fabiomlferreira]

In some projects its very important to categorize translations, for example to differentiate translations from backend and frontend.
At the moment the way to do it is something like this __('frontend.Next'), but with this type of translations we cannot write it immediately on english because if we don't translate it on the english translation file we will get "frontend.Next" instead of only "Next".
This is a really issue many other frameworks handle this in a different way for example having a extra parameter to categorize, something like t('frontend', 'Next') unfortunately this is not an option on Laravel because it's a breaking change.

So I think a little and I find a better options we can keep using translations like before but set some "reserved words" on config/app.php something like
translations_reserved_words=['frontend', 'backend'] and in get function from Illuminate\Translation\Translator if the string that will be returned starts by 'frontend.' or 'backend.' we remove it.

So in the example above even if we don't have an english translation for 'frontend.Next' it will allways print only 'Next' if the 'frontend' key is on the translations_reserved_words array.

I think this is a good approach because is something optional if the translations_reserved_words is empty it works exactly as before.

What did you think about it?

[Sophist-UK]

I appreciate the requirement (though I might argue that using Modules might have been a solution if you had considered backend and frontend as separate modules from the start), but I do not think the solution is either elegant or will work.

I am also a little concerned about __('frontend.No. If you click save, then this record will be saved in the database as a new record.').

We could instead do:

__('No. If you click save, then this record will be saved in the database as a new record.', 'frontend');

[Sophist-UK]

P.S. We would also need to decide what is common and what is different about the following statements:

__('next');
__('Next');
__('frontend.next'); or __('next', 'frontend');
__('frontend.Next'); or __('Next', 'frontend');
__('Frontend.next'); or __('next', 'Frontend');
__('Frontend.Next'); or __('Next', 'Frontend');

i.e. are they case sensitive, and if you don't specify frontend or backend, does it search in both or look only in some other place?

[fabiomlferreira]

The frontend and backend are only examples. There are many reasons where is useful to categorize a translations. For example a platform with multiple modules we can create translations specific for each module like __(‘module1.Next’).
The problem is that the only way to categorize is using the dot notation and if we use it we will have allways to translate in the main language otherwise we will get “module1.Next” instead of only “Next”.

If we have some reserved words that are removed from the returned string of the translation, that solves the problems. It’s backward compatible and don’t change anything in the current usage of all translating functions.

[fabiomlferreira]

Your example of adding as extra parameter was a good approach when laravel starts but nowadays is not backward compatible.
This is a design problem when laravel was created now we need a solution than don’t break anything