Back in D5 or D6, we introduced a rule of "string freeze", meaning we would not change/add any strings in a stable release of Drupal that was not clearly a bug fix (and a critical bug fix, at that, iirc) lest poor, hapless end users do a minor update of core and be slapped in the face with English in their French/German/Swahili site.
I wanted to open this up for discussion up again now that we're in the age of localize.drupal.org. Is this formally hard-and-fast rule something we can look at loosening a bit? It would certainly put a lot more options on the table in terms of incrementally improving D7's UX, and also in terms of backporting non-backwards-compatibility breaking features (which is on the table for the first time in D7, thanks to the testing framework).
Here are a few specific examples that have come up recently:
- (bug) More accurate error handling in EntityFieldQuery : non-existing field: In this example, Drupal is just plain giving the wrong error message when something happens. This patch adds in a new string to explain what's going on. Since this is (hopefully) a developer-only facing string, I weighed the pros and cons and decided to commit this patch.
- (minor text improvement) Color labels are not intuitive when searching for the keyword “background”: This is a very minor issue, but a nice usability improvement. By adding the word "background" to Bartik's background colors, it makes it more clear for end users what's going to be changed. However, the fix changes an existing string, and thus breaks string freeze. This would normally not be on the table.
- (major usability fix) update manager error messages: dww points out here that the existing Update Manager error messages are very unclear to anyone but the programmer who wrote them. This makes use of this feature really problematic for non-techies (the very audience for whom it's intended. D'oh!) But cleaning these up is going to break strings...
- (new feature) Add backtrace to all errors: This is a proposed D8-only feature atm. But if we decided that it would be nice to have it in D7 too, we currently can't because it makes adjustments to strings. (Actually, it looks like the current patch doesn't, but humour me and say it does. ;))
Questions I have are numerous, but include:
- Can we revisit this policy at all, and if so, to what extent? For example, does localize.drupal.org render (to some extent) previous concerns about string freeze moot? Is updating translations now easy enough that the person upgrading core can do it?
- How buggy is buggy? Is the first example there on the table for string freeze breakage? How about the third example?
- Are there any processes we could put into place to provide more string breakage flexibility? For example, a mailing list/twitter feed/something that could alert translation teams of things like #1 there?
So... yes. Your thoughts welcome! :)