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