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

Gabor Hojtsy gabor at hojtsy.hu
Wed Jan 10 10:35:25 UTC 2007


On Mon, 8 Jan 2007, Jakub Suchy wrote:
>> 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.
>
> Hi,
> thanks for explanation, but i don't think we understand each other and i
> don't think you are right. Test this please:
>
> http://test.drupal.cz
> login as XXXXXXXXXXX (hidden)
>
> Then add Czech language (Èesky). Then import cs.po i am sending as
> attachment and enable Czech language. After enabling, click "Vytvoøit
> obsah" (Create content). Do you see English page, story strings? Try to
> look them up in cs.po, they are translated.

1. When you install a Drupal site, the names and descriptions of the 
content types are added into the database. They are already in the 
database before you can even try to import a translation. Check your 
node_types table.

2. Drupal does not try to translate strings stored in the database, only 
strings stored in the source code files, for many good reasons. You can 
read up on this issue in the i18n group I pointed you earlier.

> This is not "custom" string. This is unability of Drupal to translate
> these strings and is a critical bug i think, because it is a major
> drawback from version 4.7 (which did translate these correctly) and from
> my point of view, this will lead to creation of "hacks" to support
> localization correctly.

This *missing feature* already lead to hacks to use t() to translate 
"custom" or "user defined" strings. Once a string gets to the database, it 
is considered "user defined", since Drupal cannot distinguish between an 
unmodified string inserted by Drupal in the database and a modified one.

Gabor


More information about the translations mailing list