Posted by FanisTsiros on June 4, 2010 at 12:09pm
8 followers
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | update.module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | dww |
| Status: | closed (fixed) |
| Issue tags: | Quick fix |
Issue Summary
Some phrases in update module are not translateable. (this was not true for alpha 4)
In update.module in function update_menu() i see this code:
....................
// Customize the titles of the action links depending on where they appear.
$items['admin/reports/updates/install']['title'] = 'Install new module or theme';
$items['admin/modules/install']['title'] = 'Install new module';
$items['admin/appearance/install']['title'] = 'Install new theme';..................
should have been passed through t() maybe ?
Comments
#1
In what way are they not translatable? The D7 menu system is supposed to make all the title values translatable by default thanks to #128082: Allow localization of built-in menu items. It's possible that the translation extractor is just confused and your translation doesn't know these are valid strings to provide replacements for...
What exactly have you done that leads you to believe these are not translatable? Please provide detailed steps you've taken, how your site is configured, etc.
#2
The extractor will recognize arrays in the basic array('key' => 'value') form. It will look for the => operator and the right keys will make their values saved as translatable. Any other format used for arrays will be out of translation extraction.
#3
This isn't really a bug in update.module, it's an unfortunate interaction between the dynamic code in update_men() and the translation extractor. But, it's an easy fix, and calling it a 'bug' will probably get it more attention than a 'task'. And, we should do this before the string freeze since these are very visible (e.g. at admin/modules etc), hence 'beta blocker'.
#4
#5
p.s. I confirmed this works. I don't think a test that the menu items have the expected titles is necessary, is it? Certainly we can't have a test for the extractability of these strings, which is the actual "bug" here...
#6
Looks good from an extractability POV. Did not actually test, but looks great.
#7
I don't see this as a beta blocker.
#8
Because it impacts the string freeze. There would be 3 highly visible strings in the UI that wouldn't be translated if we say "okay, 7.0-beta1 is out -- time to update your translations since we only have a few weeks before 7.0!". But either way, it's a trivial patch. More important to commit it than to argue about the beta blocker tag. ;) Here's another tag that's irrefutable... ;)
#9
As this won't get any prettier in D7, this patch is RTBC. For D8, we badly have to consider to remove all special string support from potx and instead, cache everything by interface/content language instead.
#10
Committed to CVS HEAD. Thanks.
#11
@sun: ideas as to how we can improve string identification without the need to run the code (or how we can run all possible code paths :) is welcome in the potx module issue queue.
#12
Automatically closed -- issue fixed for 2 weeks with no activity.
#13
ping about #969172: Hook_menu_alter() not supported in potx - that issue over there is about menu 'title' entries in hook_menu_alter().
It doesn't seem the extractor currently searches hook_menu_alter() ?