[development] translation for the installer?
gabor at hojtsy.hu
Fri Jul 14 21:35:44 UTC 2006
On Fri, 14 Jul 2006, Jeremy Andrews wrote:
>>> Where you run into a problem is when there's shared
>>> messages, ie as is desired by the requirements api which
>>> could also be used by Drupal itself when enabling
>>> modules, as well as by the installer during initial
>>> setup. Any text displayed by Drupal is already wrapped
>>> in t(), so I think the logical thing to do is to expand t
>>> () to support both reading mappings from text fiels in
>>> addition to from the database. Then t() could be
>>> consistently used in all code, including the installer.
>> t() is called at least several dozen times per page, any
>> complication should be avoided. The installer is a one time
>> thing and should not impact the running of the site.
> Yes, but my point is that there are instances where the same
> message will need to displayed by the installer and by Drupal
> core. All messages displayed by drupal core are wrapped in
> t(). So either t() needs to support non-database
> translations, or...?
> A specific example of where this could happen is in the
> forthcoming requirements api.
I think of the installer as that small piece of code setting up the
database. After the database is set up, Drupal is loaded fully (with the
database in there, module tables created and possibly a translation
imported). So we only need a special case for the "without database" phase
of the installer.
Since parsing a big complete PO file for a translation is a major pain for
every installer HTTP request, the parsed PO file should only contain the
strings relevant for the installer (which are irrelevant later anyway). To
reliably extract these strings for a translation template file, it is a
lot easier to have a differently named function. Although since common.inc
is not loaded in install time, t() is not defined, so we could reuse the
t() name with a different function definition, and this would not affect
t() runtime performance [just in case someone finds a way to reliably
extract install time t() calls].
Am I right in thinking that the requirements API based stuff will load
after the database is ready, so that a full bootstrap can be made and
normal translation support utilized?
More information about the development