[translations] [jakub at rtfm.cz: one question - Page & Story]

[Gabor Hojtsy]

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