The
Enter your username >strong<>em<or>/em<>/strong< your e-mail address.
string is not translated. I've looked inside your code, and the t() call is right there. The string also exists in core, and there's a translation in de.po (the German translation, which I have installed). It shows up translated on /user/password but in the securesite form it comes up in English. The other strings and the button caption are translated all right (they're core strings, too).
BTW, during testing I noticed that I can include /user/*/* and it will not affect /user/password and /user/register. That's neat!
Comments
Comment #1
darren ohFixed in CVS commit 48064.
Comment #2
moshe weitzman commentedbe wary. if page cache is enabled, you may not have access to t() yet and will get undefined function error.
Comment #3
NaX commentedI have seen that in some of Drupal Core a
if function_existsis done first before usingt().Why then is the
t()function in common.inc and not in bootstrap.inc? The only problem I can see with moving it is the that maybe thetheme()function might not be available yet.Comment #4
salvisYour fix didn't really seem to help and I finally understand what is happening.
First, you didn't fix the string I mentioned in my original message. It's a bit hard to read because the entities were escaped, but the one I asked about was
Enter your username <strong><em>or</em></strong> your e-mail address.It turns out that this one as well as the one you fixed are only used once in the lifetime of the site to initialize the fields in admin/settings/securesite. I have my site set to German, but my admin account to English, so it's correct that securesite gave me the English default string. I didn't change it (which was my fault, but at that point I didn't care about that functionality), and it went right into the database. Thereafter you always take the string from the database and you don't run it through t() anymore.
I guess that's correct behavior, because at that point the string is a user-defined string, not a source code string, and you could say I should change the string myself in admin/settings/securesite. OTOH, running the string from the database through t() again would have given me a chance to translate it and avoided my confusion.
However, if I had customized the string (with German text, because the site is in German) and you had passed it through t() again, then the German text would have been stored as the untranslated (=English) string, which could cause confusion, too.
In the end I believe the proper approach would be to try to translate the default string to the site's default language, not the user's language, if that's possible at all (after all, the context where the string is shown is the anonymous user's context, which always uses the site's default language). Currently you don't have a de.po file, so it wouldn't have helped, but at least the string would have been added to the untranslated German strings. Supplying my translation still wouldn't have helped, because it isn't used again, and I might still have contacted you, but if you get translations in the future, the situation will improve.
A short comment in the source code, stating that the string is only used to initialize admin/settings/securesite the very first time and that the user has to customize it there, would have brought me onto the right track and saved you from the support issue.
P.S. Your fix is still worthwhile, it just hasn't addressed the original issue.
Comment #5
salvisComment #6
m3avrck commentedYou'll want to look into the get_t() in bootstrap.inc which is part of 5 now.
You can use the st() to translate strings when t() isn't available at installation time or in the _init() phase.
Comment #7
darren ohYou must set the string before it is used. If you want to see the translated default value, use
variable_del('securesite_request_form')to remove the string from the database.