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! :)
Comments
purpose of string freeze and the role of localize.drupal.org
Hey :) So let me give you some historic details. String freeze is held for a few reasons.
(a) To be able to translate software before it is released,
(b) To keep printed books, video tutorials and such valid,
(c) To keep any altering modules work (eg. historically, modules were checking submit button text equivalence in custom form submit hooks).
In reality I think it is fair to say that every other Drupal 6 release added or modified about a couple strings. The rules I followed were:
(a) If those are strings only ever shown on the admin UI, adding any number of them is not an issue
(b) If those are shown on the front end UI then be vary about changing them / adding new ones
(c) If it is is about error messages or so, then be extremely vary
(d) Major renaming, terminology changes, UI reorganization was not allowed for the books, videos, etc. unless EXTREMELY required
Imagine for error messages, it is the most important thing for someone to understand and asses the severity of the issue. If your site suddenly displays error messages in a language you don't know, it is very easy to freak out...
Now, all that localize.drupal.org does is that it makes the core strings available automatically soon after release. Then if translators jump there to see if there were any changes and make their translations updated, it still takes about a week for localize.drupal.org to come back and regenerate the translation files (it goes around on projects that need regeneration). Yes, I'd love help in re-architecting the .po file generation process, I have great ideas to speed this up and remove idle cycles from the process, but no resources to work on it... Then once the new .po files are available, sites running l10n_update module will get the updated translations either manually or automatically depending on their l10n_update setting.
So the deployment of updated translations is $translator_time_on_new_or_changed_strings + $about_a_week. Imagine that in the meantime the strings will show up in English on an updated site.
I've used the above information when deciding on Drupal 6 string changes. There is no hard rule to never do it or always do it, it is a nuanced one by one decision.
Strings always change
... despite string freeze.
Be it because some t() was missing, or whatever, in drupal 7.2 there were about 20 strings to translate to italian on localize.drupal.org.
With l10n_update refreshing the translation of core & contrib is really affordable for every site maintainer, and I think every non-english site admin knows how to use it.
Of course an 'upgrade' message advertising that some text might have changed would be welcome.
Angelo Turetta
Modena - Italy
Upgrade message is a good
Upgrade message is a good idea for both site admins and l.d.o
Hadi Farnoud
فروشگاه ساز | ایمیل مارکتینگ پاکت
String changes = Usability improvements
@webchick: Since the time between major releases are much longer than back in the 4.x (before my time) I believe that making some string changes are important. The points you bring up are valid reasons.
One other point I would like to add is all the usability tests being done now that often discover new users being confused about the terms/string used in Drupal.
To make changes easier to see for site builders/developers it would be good if there also could be a Help page listing all those changes, which point release the change was introduced, where they are, what the original and what the new term/string is. Then everyone will know where to quickly look et every point release.
Since string freeze does not apply to contribs, every site will have strings changed over time and for a user it doesn't really make any difference if those changes are for a contrib or a core function. Just look at the major change in the Views UI done lately to take one extreme example.
--
/thomas
T: @tsvenson | S: tsvenson.com
good point
Good point with the large contrib changes...
+1 for having a listing of
+1 for having a listing of changes. Current system is not sufficient to figure out what changed, why and in which context.
Part of the problem is t()
The t() function is fundamentally flawed as it uses the English value as the key. You can't change anything without cascading failures on everything that is dependent on the key. I hope there's some will to fix this post-D7.
</rant>
That said, I think a cautious approach, considering what Gábor and Thomas have said, is best. Since there is a lag in translation translation times, it is essential that security releases have no string changes at all. I would imagine that large i18n sites won't upgrade core without testing, so cautious string changes would be OK for regular releases.
http://cleaver.ca
on that rant
On that rant of using real string keys, if the string changes enough, the keys would need to change to accommodate that, so that old translations are not used in that place. For simpler fixes like typos, it would be a great thing to keep the translation the same. I think mostly what is needed there is (a) make up a system of naming for these. Eg. a hook_help or a form or a form_alter might have tens of translatable strings. How do you make up identifiers for them? How do you maintain them? And then (b) we need buy-in from the community at large - but we need a plan to have buy-in for in that case. Anyway, I've posted a summary of what has been discussed so far at http://groups.drupal.org/node/154394 for interested parties to discuss. Your feedback more than welcome.
It could already be an
It could already be an improvement if there was a possibility to override English strings with an English *.po file.
This would only be used for small changes and typos, to avoid that translations become invalid.
That's not the big new architecture we might want, but it would work quite well with the existing system.
(and btw, the captcha for regular users just sucks)
ok, offtopic here :)
I'm not sure I understand what you propose, please follow up with this discussion on http://groups.drupal.org/node/154394 so that this one can be kept ontopic :)
Implementation details of
Implementation details of this would be off-topic, but having this in place would certainly make some string changes easier. So it does have a relevance for this thread. Ok I follow up over there.
In some cases, exceptions to
In some cases, exceptions to string freeze would be a good thing for translators. If a string is hard to translate, or needs a context, it most likely won't be discovered until after people have started translating, and that's mostly after string freeze. So I'm all for it, especially if there's a list of changes so we know that we need to update the translations.
--
Hilde Austlid, Drupalchick
I'm afraid I'm an old dog
I'm afraid I'm an old dog here and not up to date on Drupal but a level of indirection could be terribly useful here. In general the strings are referred to by unique id's usually a number that indexes into a table. This could be a table of English, Italian, Spanish, etc.... A change in the English spelling makes no difference to the translators, ambiguities in English may be resolved in the translations. All new strings will need to have entries in their translation before the release or by default the messages could be put out in English.
Not much help at present but I know this approach took a recurring issue to bed for years.
.
That's a whole 'nother issue... http://groups.drupal.org/node/154394
Michelle
If we could provide a file
If a module / core developer could provide a file with legacy translations..
For each updated English string, this file would give us the previous version.
The t() function could then use this thing as a fallback.
runtime vs. update
Why would you use this as runtime data instead of updating the old strings in the database when you update the module? If you use runtime data, it always needs to be loaded and be part of the lookup, while we know the original data is outdated. We don't do similar hacks in other parts of Drupal definitely.
True. The point is, we want
True.
The point is, we want to use the legacy version as a better-than-nothing, but we still want translators to be notified that the English has changed.
The old po files (produced by some translator) that you download will still contain the old English string, and its translation. Only the module files (produced by the module maintainer) know about the updated strings.
I guess we could make an implementation that runs during install/update, and when you download a translation, and not at runtime.