Answer the question
In order to leave comments, you need to log in
What are the pros and cons of (not) using gettext in Laravel?
Let's say there is a CRM on Laravel.
Requires i18n.
1) You can do it as it is done natively in Lara, with files with field values, dividing them into directories en ru es, etc.
2) Or you can connect gettext , which is already like a standard, it is used everywhere, and even here there is a tag on the toaster.
3) maybe there is another option?
( 1 - multilang in the database - not kosher)
The question arises: what are the pros and cons of the first options?
the first one seems to be native out of the box, so in theory it should be fast. But gettext is a professional tool for localizations, where every sneeze is already provided, and l2r and plural, and genders and cases and all that.
In theory, an extra plugin with its own file can somehow affect performance. But there is a compiled .mo there.
So all the same, even if it is scanty, but the performance will be different?
The second bonus I see with gettext is Poedit and/or online translation tools. For myself or for the community, if someone wants to translate.
On the other hand, if there are only 2 or 3 languages in the project, then you can translate native Lara files and leave them alone.
What other pros and cons are there to consider using or not using gettext in Laravel?
Answer the question
In order to leave comments, you need to log in
In theory, an extra plugin with its own file can somehow affect performance. But there is a compiled .mo
gettext is more native than "native" from Lara then.
For gettext, no plug-in is needed at all, in fact, only as convenient ready-made language switching functions, the rest is already out of the box.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question