Feed aggregator

The form at user/[uid]/edit should use an email form element.
It seems, according to [#316886] that a form_alter won't cut it here.
Haven't worked it out yet, mabe somebody else wil have a pointer.

Small comment fix

A simple question with far reaching consequences - At a DrupalCamp in a non English speaking country (e.g. Spain), what should be the primary language ?

This is my view, and i post it to get the discussion going.

As i see it, if the majority of sessions are in English, it will :

• Bring in more sponsors from the wider (English speaking) Drupal community
• Potentially improve the quality of the sessions, because more Drupal developers speak english
• Improve English speaking (non-local) attendance. People will not invest $$$$ flying and staying in hotels, if they are then only able to understand 10% (or less) of the sessions

Unfortunately i think language choice is a all or nothing issue. Unless the camp is promoted as being in English (or at least 50/50) you face a negative feedback loop.

Not enough English sessions/focus --> Less interest from non-native speakers --> Not enough English sessions/focus

The camp is promoted as an English language camp with a native langage 'Track', which would probably focus more on the newbie/introductory level to keep it accessible to local businesses and people with a casual interest. Advanced sessions would be targeted at English speaking (perhaps with translation help for slides / dual slides etc) to attract the people who would invest the $$$ to come to a camp in another country

Anything other than this approach, i think, would result in a very poor attendance by non-native speakers and as a result only a few 'star speaker' sessions would be in English with little recognition from the wider Drupal community.

I am cross posting this in a few groups, as i'm interested to hear from the potential non native speakers attitudes to camps in non English speaking countries (like Spain)? Link to help : http://translate.google.com/

The testing profile does not enable required modules like node but uses its permission 'access content'. This leads to a fatal error during testing_install() using drush. Attached patch adds one dependencies[] line to testing.info which is enough to kick in the dependency check and thus all required modules are enabled. Patch also adds a customary files[] = testing.profile like other profiles.