Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I'm running my Drupal site in Norwegian. However, when I tried to install a module from within Drupal, authorize.php was in English. AFAICT, the strings are actually translated.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 1021322-7-authorize-locale.patch | 1.46 KB | crifi |
| #3 | authorize-2011-01-19-hansfn.patch | 824 bytes | hansfn |
Comments
Comment #1
plachComment #2
crifi CreditAttribution: crifi commentedI don't understand your bug report. There are some calls of t() in authorize.php http://api.drupal.org/api/drupal/authorize.php/7/source
Can you give some example strings which doesn't works? Currently I see no reason why the translation shouldn't work...
Comment #3
hansfn CreditAttribution: hansfn commentedHow can this be unclear - the strings in authorize.php just aren't translated. I looked closer at the code myself and realized that the locale module wasn't loaded and hence no strings translated. See attached patched (that fixes the issue for me).
Comment #4
crifi CreditAttribution: crifi commentedI have a german translation of drupal 7. All HTTP pages with 403 status are called over authorize_access_denied_page() in authorize.php and they work, because the function t() calls locale() which loads the translation strings...
What do you mean with installation of a module in coherence with authorize.php?
Comment #5
hansfn CreditAttribution: hansfn commentedcrifi, haven't you even tried to install a module the new way - by using the form on admin/modules/install?
Anyway, you can see the problem by just visiting authorize.php directly - with and without my patch.
NB! The function t() checks if the function locale exists, and then calls - big difference.
Comment #6
crifi CreditAttribution: crifi commentedPlease respect that I tried to reproduce your issue and wasn't able to comprehend your issue directly. It should be in your interest that the community proof your issue and help to clarify what's the exact problem. Thank you for your patience anyway.
For me it's clear now and I can reproduce it. With your patch installed, calling authorize.php directly without any rights the "Access denied" title string is still not translated (even if the string itself is in the translation). So I think your patch doesn't solve the whole issue, right?
Comment #7
hansfn CreditAttribution: hansfn commentedI think my comment sounded harsher than it was meant.
My patch solves the issue I reported. The problem you are seeing, is just a missing t call, isn't it?
Line 44 of authorize.php: drupal_set_title('Access denied');
Comment #8
crifi CreditAttribution: crifi commentedSure there is a t() missing, this is simple. But there are still some drupal_set_titles more without t() called (for example line 116):
So I've made a grep over the whole D7 code to proof if there is also a translation problem with these $_SESSION variables...
In modules/update/update.authorize.inc t() is called correctly, but in modules/system/system.module there is no call of t() when setting the page title to the session vars. I think there must be a t() call also?! Or we translate inside of the drupal_set_title() calls in authorize.php and revoke the t() call in update.authorize.inc ...
What's the Drupal way? ;-)
P.S. New patch file attached with the obviously missing t() call.
Comment #9
hansfn CreditAttribution: hansfn commentedOK, we are really moving beyond my knowledge, but I'm guessing that $_SESSION['authorize_operation']['page_title'] contains the translated string already. Calling t on a translated string normally doesn't change it - unless the translation by coincident is identical to some other English string.
If you look at the calls to system_authorized_init in modules/update/update.manager.inc you'll notice that the page_tite parameter is translated. system_authorized_init sets $_SESSION['authorize_operation']['page_title'].
Comment #10
crifi CreditAttribution: crifi commentedOkay, I agree. We have controlled that everything in the translation of authorize.php is okay right now. Under the presumption that the session var is already translated, we now need a review of somebody who knows if this is now the desired behavior.
Comment #11
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedTagging this with Update manager to make it more simple to find for update manager maintainers (dww).
Comment #12
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedComment #13
Tor Arne Thune CreditAttribution: Tor Arne Thune commented#8: 1021322-7-authorize-locale.patch queued for re-testing.
Comment #14
albertosouza2 CreditAttribution: albertosouza2 commented#8: 1021322-7-authorize-locale.patch queued for re-testing.
Comment #24
quietone CreditAttribution: quietone as a volunteer commentedThe patch here contains changes to authorize.php to add t() to the 'access denied' string. That was added to Drupal 8.0.x in #2192653: Remove drupal_set_title from authorize.php and resolves the problem in the Issue Summary. There are other suggested changes in that patch but track the history of those. So, I search for any D8/0 current issue related to this problem and was unable to find any. Therefore, I think it is safe to make this as outdated.
But before doing that I checked the D7 code and find that the changes to authorize.php could still be applied there. So, moving this to the Drupal 7 issue queue.