Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.In fields dialog the "File" (and probably some other) strings are passed to t() two times. This mostly does nothing but a little overhead, but in Estonian this may lead to strange results, since "File" → "Fail" and "Fail" → "Ebaõnnestunud", which is far from the original meaning.
I think that having t('File') is good for translation collection scripts, but the second one may be needed (or may not) to translate user fields. So the t() markers should be removed from the field_ui_admin.inc
/modules/file/file.field.inc@12-15
function file_field_info() {
return array(
'file' => array(
'label' => t('File'),
modules/field_ui/field_ui_admin.inc@351-361
'type' => array(
'#type' => 'link',
'#title' => $field_types[$field['type']]['label'],
'#href' => $admin_field_path . '/field-settings',
'#options' => array('attributes' => array('title' => t('Edit field settings.'))),
),
'widget_type' => array(
'#type' => 'link',
'#title' => $widget_types[$instance['widget']['type']]['label'],
'#href' => $admin_field_path . '/widget-type',
'#options' => array('attributes' => array('title' => t('Change widget type.'))),| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 915592-field_ui_double_translation.patch | 1015 bytes | franz |
Comments
Comment #1
mahfiaz commentedFor testing add to /includes/bootstrap.inc@1442,1463 to return call some additional marker, like:
return $string."↑";
This way you will see, that a awful amount of strings suffer the same plague of overtranslating. This usually does not ruin anything but performance, but sometimes it does (as the above example). Also such behaviour can add unnecessarily already translated strings to translation database.
Comment #2
franzIf I get the issue well, this is a problem with field_ui module then. Are you sure this modification won't affect other fields?
Comment #3
mahfiaz commentedSorry for taking so long to come back to this. I tested this again and all the other widgets still had translated names after applying this. Committing this is safe.
(you may skip this:)
If a module (none that I am not aware of) ought to let user define their own customized field types and widgets from UI (not by writing a new module), then it is the problem of that module, also doing so does not make much sense, at least not in the next decade (Drupal is too configurable as it is, there is no need to create a framework for a framework :) ).
Comment #4
webchickHmmm. Not sure about this. This seems like it could cause existing sites to suddenly be seeing English strings, at least in D7. Assigning to Gábor to get his thoughts.
Comment #5
mahfiaz commentedI tested this with Drupal 7.
Modules translate widget names and types in the place where the name and type string originates from. If they didn't, the strings would not end up in the .po file and localize and would be only available for translation after the string is first time passed through t().
As I mentioned earlier, the only way for such untranslated strings is if users could define their own field types directly from UI. This is totally unnecessary, as we use modules which define field and widget types (and setting database column types and defining widget code will hopefully never reach Drupal UI). AFAIK there is no such module.
Comment #6
gábor hojtsyIs this label not already configurable? I don't really know this area of the code well to be honest.
Comment #7
damien tournoud commented_field_info_collate_fields()doesn't collate by language, so thet()infile_field_info()needs to go away.Comment #8
droplet commentedIs there any document about it for developers
Comment #9
mahfiaz commentedThese two strings appear as third (Field) and fourth (Widget) column in /admin/structure/types/manage/article/fields
I have never seen a place to configure these names, although I have wandered around in admin interface quite a lot.
Damien, if you remove t() functions from the _field_info_collate_fields(), these strings do not reach .po file, unless we create a dummy function with all the entries, like:
I would like to be proven wrong here, that would be a nasty workaround.
Comment #10
gábor hojtsyCan someone post a "call-graph", ie. tracking down where things are called, so we have a better idea of how this data is used?
Comment #11
damien tournoud commentedThis is needs work based on #7: either we need to collate and cache by language in
_field_info_collate_fields(), or we need to remove thet()from the various info hooks.Comment #12
mahfiaz commentedDamien, sorry for the status change, it was accidental.
Gábor, unfortunately I can use xhprof only in localhost and cannot provide you with a link. But the chain is as follows:
_field_info_collate_fields → field_info_field → field_ui_fields_list → call_user_func_array → (and I suppose) menu_execute_active_handler
Comment #13
mahfiaz commentedArgh, Firefox tries to outsmart me.
Maybe I should also note that this chain was for /admin/reports/fields
Comment #16
jhedstromThe methods in the IS have been completely overhauled, so I don't think this is still an issue in 8.x?
Comment #23
quietone commentedThere has been no activity here for 4 years 7 months.
As said in #16, the methods have been changed. I did try to reproduce the problem with a standard install of 9.2.x and was not able to do so.
Therefore, closing as cannot reproduce. If you are experiencing this problem reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue (starting from "Install Drupal core").
Thanks!