Re: gettext best practices?
Hy Michael,
> When using gettext, is there any advantage to breaking your
> translation down into modules?
The advantage or disadvantage would be that you have to load every
module-source on request.
An possible advantage would be to have the source splitted but this means
also more time for managing the source.
From speed there is no advantage. The gettext adapter is the fastest one
from the supported sources.
If we think of a normal webapplication with about 500-1000 sentences there
would be no big advantage in splitting the source.
The difference is in some milliseconds. When your web application has more
than about 5000 sentences I would strictly advice for splitting the sources.
> I was working on the basis of having a core.en.mo file for my "base"
> system and then adding translations for each given controller (e.g.
> frontpage.controller.class.php would add frontpage.en.mo to the
> translation object, I'm not using Zend_Controller by the way).
Splitting the source into single files instead of modules adds more overhead
which also speeds down the whole process.
> However, the recommended translation management tool seems to insist
> on scanning entire folders of source code to generate translations, so
> I end up with a single catalogue containing everything in my project.
We do not recommend any translation management tool. When you'r speaking of
poEdit which is an example for a freeware gettext tool, you are able to
scan folders. And modules should be splitted into folders. See the
Zend_Controller part of the manual.
> Is there any advantage to breaking it up? Or is that a disadvantage?
> Does it load and parse the entire mo file? Or just use it as a
> database to look up translations?
The more files, the more overhead. In my opinion no advantage.
It always loads the complete mo file, because the overhead of parsing the mo
until it finds the requested string would be much bigger than just having it
already parsed. Reading each translation from the mo file directly would
decrease the speed because you can not jump to a defined position within a
mo file, wou have to read it from beginning to the requested string.
For now there is no support for backends. And it makes only sense for
applications which are really big. The clue is, that reading the mo file is
as fast as reading it from the cache. Because there is no "parsing" as we
have it for xml files. This is also the reasong why gettext is recommended,
because it is actually the fastest adapter.
Greetings
Thomas (Zend_Translation author)
I18N Team Leader