[development] translation for the installer?

[Gabor Hojtsy]

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?

Gabor