Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
I want to override the helper function '__()' what is the best way to do it?
I have a problem with the translations I want to organize by files the different translations for example translations for frontend are really important and should be done but for backend are optional.
One way is to use code like this __('frontend.welcome_message') but most of the time I will write the correct text directly on the code something like this __('Welcome to our website') but if I put this __('frontend.Welcome to our website') the laravel will print 'frontend.Welcome to our website' if the translation don't exists. I want to rewrite the __() to prevent this and remove the "frontend." from the string, so even if the translation doesn't exists it allways will print only 'Welcome to our website'.
I would suggest you write your own function with another name that calls __(). Composer loads content from the vendor before it loads your code, so you cannot overwrite it. You would have to inject your own file before this line using require
https://github.com/laravel/laravel/blob/9.x/public/index.php#L34
And this would only be for web requests. If you need it in your tests, you would need to find a way to inject it there as well
So. Make ___() and just search replace your files
I have found a better approach and don't need to override __(), I override the "get" function from Illuminate\Translation\Translator and create a new service provider to it.
I have posted a new suggestion in laravel github https://github.com/laravel/framework/discussions/43338, I think the translations can be improved to have a easy way to categorize without we need to translate everything in the main language.
At the moment the problem is if we want to categorize a translation we allways need to translate it in the main language otherwise we have something like this printed 'frontend.Welcome to our website' instead of only 'Welcome to our website'.
@noop sounds like a good idea for a package if they don't want to maintain it :)
@noop I don‘t really understand what problem you’re trying to solve. If you use a string with the __() helper then it will just return that string back by default like you want.
I don’t really understand why you’d need to “categorise” translations. The translation of a word or phrase would be the same, whether it’s “frontend”, “backend”, or anything else.
“Hello” is “Hola” in Spanish. This doesn’t change between the front-end and the back-end of a website. The rules of language don‘t change depending on what part of a web app you’re in.
@martinbean there are many cases where it's important to categorize the translations, a basic example is a website with a public frontend and a backend for internal usage, imagine you are from Portugal and you write everything on code in english (this is my company case). We need to translate everything to Portuguese on frontend but on backend in many cases it can be in english. So it's important to categorize to easily know what strings are used on backend and what are used on frontend. Using the dot notation we can categorize it easily for example https://github.com/barryvdh/laravel-translation-manager plugin will create a file for frontend and a file for backend, this is perfect but the problem is that if we don't translate the english version we will get on our backend something like this "backend.Hello" when we really want is to have only "Hello". Did you understand?
At the moment in our company we are writing everything without any category we use only __('Hello') in this case we get always the string in English and only need to translate to Portuguese, but it's extra work when we translate because the person that translate it don't know if is a string from backend or frontend and need to translate everything, if we have the categories we only translate what was really necessary.
For example in Yii framework to translate they have the follwing function \Yii::t('app', 'This is a string to translate!'), with this approach the category is the first parameter, but laravel don't have this we need to use the dot notation can cause some problems
I don’t really understand why you’d need to “categorise” translations. The translation of a word or phrase would be the same, whether it’s “frontend”, “backend”, or anything else.
I agree with you that between backend and fronted it might be the same but a word in english can have different words in another language.
"bank" means in dutch a couch, sofa, or an actual bank. You cannot translate single words without knowing the context. You see it quite often in translated apps that the translation is incorrect, because they only translated the word but did not take the context into account.
@click I don’t see what your solution does to fix that? If there’s not a translation, the user’s still going to see “frontend.Bank” or whatever.
@martinbean The problem is simples should be easy to add categories to translations without write strange things on the screen. At the moment it's impossible to add categories without we need to translate in the main language, because when the translation doesnt exist it write the string, with my approach we have some reserved words that are removed before it writes on the screen in, this is backwards compatible, enable us to easily categorize translations and if we don't want to use it don't change nothing.
I hope that the Laravel developers implement this natively, at the moment I already have a working solution that will implement on some projects, I don't need it in all. But in large projects I like to categorize the translations, to help the translation team to do their work.
@martinbean I don't suggest a solution. I only give a reason that there is a valid reason why you would like to categorize translations.
@click Sorry. Was reading and replying on mobile and got mixed with you and noop.
Please or to participate in this conversation.