Jeremy Andrews wrote:
On Fri, 14 Jul 2006 18:10:55 +0200 Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
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...?
I don't see why the installer can't use the existing PO parsing functions to parse a PO file and then display the result through another function. Cheers, Gerhard