On Tue, 2 Jan 2007, Jakub Suchy wrote:
These strings are inserted into the database at install time. Unless you have these translations imported before the system.install script runs (which is not possible, even if you use the autolocale module and localized profile which imports at the earliest possible). The system.module is forced to be the first to be installed so it is not possible yet to release an install profile, which does anything before the system module install script is run. So we cannot help these English strings there.
I am open to solutions :)
Which is a critical bug obviously, am i wrong? But i fairly don't understand. These strings are not regular strings available to Drupal?
This is not a critical bug, but a missing feature. Once a string gets to the database (in any language), Drupal does not try to translate it through t(). This is the same with menu items, user email text, etc.
Take for example that you have a German locale on your site. Using that locale, you save german user welcome / password recovery / etc mails on the user interface into the database. Now every registration attempt will result in German language emails sent out, since that is what is stored in the database. Until you store your "custom" strings in the database, Drupal works "right", meaning it send out properly translated mails (depending on what interface language was used, if a translation of the mail text is available).
Your issue is the same. Once the installer stores these strings in the database, they become "user defined" or "custom" strings, and Drupal has no feature to translate these.
That Drupal is not able to translate "custom" strings is a missing feature. This is something worked on in the i18n group: see http://groups.drupal.org/i18n
Gabor