Which is better:
Gettext is a sort of builtin feature, so I assume it's tweaked for performance. Using poedit is a pain and impossible to show to any client.
A custom functionality allows for simple translation interface. But might be heavy on php/db usage.
I suppose, which one would you use when?
Localization is difficult. It is really difficult. It's not just "pairs of words" => "Wortpaare", it's a lot more complex than that. What most people forget when they look at gettext and go "Ugh, ugly" is that the localization process is a lot more important than the technical details of the implementation. That's because the actual translators are typically not programmers and are probably not even in-house. This causes a lot more headaches than you may think. gettext is really old, is battle tested and has a huge toolchain behind it that is tuned to support this process. If you want to do i18n and l10n properly, you need a powerful system. gettext is that and has support from a wide range of tools. Your Homebrewed Translation System™ does not.
First of all, you need a robust system to extract translatable strings. Without being able to automatically and reproducibly extract translatable strings from source code, you have a mountain of work for each new string you want to translate. In gettext, xgettext does that.
Next, you need a tool to synchronize the extracted strings with already existing translations in a way that no translations are lost and that only slightly changed translations are kept if possible. In gettext, msgmerge does that.
Next, you want a way to add extra information to strings. You want to be able to group them by category, "domain" and context, you may want to add comments for the translator to the source code and you may want translators to be able to add comments to the translations. gettext supports all that.
Next, you want a file format that has good support from a variety of tools, since you may be sending your files to China to get them translated there. The reason you may be sending them away to external translators is also the reason you need a good synching tool to merge changes, since this can be a very asynchronous process. PO files are very well supported, because gettext is so old. There are many open source and commercial tools that support the localization process at many levels, depending on your specific needs.
Do not underestimate the task of localization, choose a tool that is well suited for the process and learn it. gettext is a great tool, if admittedly not the most beginner friendly.
For what it's worth, here's my gettext extension for Twig, which makes gettext for PHP even better.
Maybe you should look into Memcached which you can use it in combination with MySQL. It's very useful for fetching data which doesn't change too often, like translations.
Gettext is a very old format. Its using files to store translations. Its clumsy, especially when you have translations by the thousands lets say 20,000. Managing a PO file with 20,000 translation strings is a nightmare, across 50 languages is imposible. Then you have to actually compile it in a MO file. No thanks. It might have made sense back in the 1990, not now.
Databases instead are powerful. Like really powerful. Name what you need and you can get it. In a second they can tell you exactly:
