I'm curious about the translation engine. What would you suggest instead of the current PHP strings system?

My needs can seems exotic and uncommon, but as any other user, if current system is bad for me, I want to use good solution and preferrable way is to do it without dirty hacks on hacks on hacks, which produce fork as final result.

For me, as for any user  which language have plural forms, *gettext is (AFAIK) a single right solution for today. I know about some speed overhead coming with it, but it counted (me) as minimal impact and, with better manageability of pot/po sources and translation process in common, it's fair price (from my POV).

From other side, maybe somebody prefer to use Linquist, f.e, or some other engines, which just don't know. To have choice is better than have nothing. If user don't care - it uses default values, if care - he can do that he want, not that dictated for some unclean reasons.

My position about template engine is the same - current template are (ideologically) worse than terrible. Instead of tips and tricks giveto the end-user freedom of choice and clean rules, which he must follow. Drupal (fast example) supports 4 or 5 (if my memory servers me right) TEs and it doesn't broke anything

The following is what I'd like to focus on for the next few versions of Elgg.  Specificity decrease as ETA increases.

Elgg 1.8 - Q3 2010

1. UI/UX - (A new default theme, drag-n-drop plugin reordering, UI consistency)
2. Improved views model with semantic view names.
3. Improved markup and CSS to allow CSS-only themes.
4. CSS primitives.
5. Improved plugin subsystem with plugin dependencies, generic testing of a plugin's functionality before allowing it to be enabled, uploading a zipped plugin.
6. Rewritten bundled plugins.  (Not all of the...Blog is in the works, groups would be awesome but we'll see).
7. Sticky forms
8. Performance improvements by making better use of query caches, eliminating redundant caching, and possibly extending memcache support.
9. Better debugging.
10. Full RSS, JSON, and XML support.  (ODD will be gone, and JS will likely be removed, too.  Anyone use it?).
11. elgg_echo() passing through sprintf() with argument swapping for easier string translations.
12. "Friendly time" customization support.
13. Better search on users (profile information) and options to sort by most recent time.  Advanced search features.
14. Elgg JS object to solve a few common problems with using JS in Elgg (token renewal, Ajax handling, popup messages, string translation).

The optional templating system Alexander mentions would be interesting, but probably couldn't happen until 2.0.  Elgg does have the ability to change the template handler (see http://reference.elgg.org/elgglib_8php.html#003f835e40d55c410dfe0c4b51a0a858), but I doubt its usefulness for what Alexander wants.  Has anyone used this at all?

This list is, of course, neither comprehensive nor fixed.  It's my hope the community will drive the improvements with discussion, testing, and development.

Will this new default theme be a plugin or part of core?  I would vote plugin...

The default theme will be part of core.

Who is helping with/doing the design? Are you taking outside opinions/help with the new skin and CSS? The reason I ask it the skin is one of the first things I change, I am a designer, and I would love to help.

@Ben - there have been two discussion threads so far. One focused on cleaning up Elgg's default markup: http://community.elgg.org/mod/groups/topicposts.php?topic=397103&group_guid=212846

The other on Elgg's default css: http://community.elgg.org/mod/groups/topicposts.php?topic=424690&group_guid=212846

There has already been some work done on this and I'm sure that Brett and Pete would love feedback. You can grab the latest at http://elgg.org/download/nightly/trunk/ (Note: this is the beginning of Elgg 1.8 and is very unstable. It is not for production environments.)

Brett, I am curious about your longer term goal to "Denormalize the metadata and annotations tables."

Would this be something that happens behind the scenes as a kind of automatic database tuning or would the idea be to essentially abandon the current completely flexible entity-attribute-value design and go back to the more traditional approach of having plugins declare a fixed table structure with one or more separate tables for each plugin?

If it is the second, do you have any performance information suggesting the speed-ups that might be gained with the more traditional multiple table approach?

@Kevin - It is absolutely not the second approach.  The annotations and metadata tables are normalized with a foreign key (two, actually) to the metastrings table.  This means requesting the value of a metadata name for an entity requires either 2 joins or 3 queries or some combination thereof.  There is already at least 1 join between the entities and objects_entity (or users, groups, or sites) tables, and probably another join / query between entities and entity_subtypes.  Joins 

Denormalizing these tables is wholly transparent to anyone using the API, and makes life simpler for anyone writing their own SQL because it means 2 fewer joins on every metadata and annotation call.

@Brett - Couldn't agree more with the denormalizing those tables due to my experience whilst creating my threaded forums plugin.  The queries can become quite long and tedious so makes sense to me.

And judging by your list above - the future of Elgg looks great with lots of exiciting improvements to come.