Posted by David_Rothstein on August 1, 2010 at 9:14pm
2 followers
Jump to:
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | update system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Currently in D7, it is documented that implementations of hook_update_N() should return a translated string, using the t() function.
According to the writeup at http://drupal.org/node/322731, however, they should not return translated strings. In addition, we have a lot of drupal_set_message() calls in update functions that do not translate their strings, following the recommendations on that page.
Overall, something must be wrong somewhere :) We need to figure out what the correct behavior is for D7 and then apply it consistently across all update functions in core and then document it.
Comments
#1
Yes, the status of translation is update functions is still as explained in http://drupal.org/node/322731 I believe.
#2
I thought about writing a patch to try to do this conversion, but then found places where it didn't really make sense to. Sometimes t() is used for security, with @ and % placeholders, and it seems wrong to tell people not to use that - it results in more awkward code and a greater likelihood of security mistakes.
Maybe just like we tell people it's OK to use t() in tests (even though the string extractor is supposed to know to not translate them), we should do the same thing in update functions? For example, the locale() function itself could learn to bail out when it sees a string it doesn't recognize and when MAINTENANCE_MODE is 'update', to prevent those getting stored in the database. I think that would make more sense. That way the burden is not placed on module authors.
#3
Yeah, well, the runtime t() can look for MAINTENANCE_MODE, but the static code analyzer that runs on the code for localize.drupal.org (and that was used in the past 7 years to generate translation templates for translators) will not know if a code block only runs in MAINTENANCE_MODE, or not. Those strings will end up not translated in the database of localize.drupal.org, translators will translate them, and therefore those translations will be imported into Drupal databases, even if locale() would otherwise not save them runtime. Depending on the number of the strings, it might not be a big issue though, just noting that technically, it is not possible to tell a t() that runs in MAINTENANCE_MODE and one that is not.