Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.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 ?
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 818136-3.update_menu_title_translation_extractor.patch | 1.18 KB | dww |
Comments
Comment #1
dwwIn 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.
Comment #2
gábor hojtsyThe 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.
Comment #3
dwwThis 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'.
Comment #4
dwwComment #5
dwwp.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...
Comment #6
gábor hojtsyLooks good from an extractability POV. Did not actually test, but looks great.
Comment #7
webchickI don't see this as a beta blocker.
Comment #8
dwwBecause 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... ;)
Comment #9
sunAs 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.
Comment #10
dries commentedCommitted to CVS HEAD. Thanks.
Comment #11
gábor hojtsy@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.
Comment #13
yched commentedping 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() ?