I was thinking through dynamic variable translation with Konstantin Kaefer yesterday, and some good ideas come to me after I gone off IRC. This could solve variables, content types, menus, taxonomies, blocks, user profiles, as long as we add dynamic string based translation to these (which will be possible to turn off by type :).

1. We cannot reuse the locale functionality, because it is designed for "static English string to static foreign language string translation" from the ground up: http://groups.drupal.org/node/1827

2. We cannot use a simple t() like function either, as we need special widgets with validation and submit functions for some values (like the site logo or default user picture).

3. We cannot reuse the admin interfaces (menu, taxonomy, content type setup, settings pages) as localizer does, because many sites will not give administrator, menu editor, taxonomy editor, content type admin or site setting admin permissions to translators. BUT we need to reuse some forms from there.

4. Dries would like to see a simple reusable API anyway :)

So, we need to somehow get together what is good in t() and what is missing from t(), as well as provide a specialized UI for translation of these strings, a one-stop-shop for dynamic interface translation for the user.

Attached is potential information architecture redesign based along functional/user persona lines. This needs work, however it's one method of organizing content.

Whether or not these are actual different sites or not remains to be seen... there are pros (could install specific tools for each site -- ex diff module on the docs site, project module on the dev site) and cons (link rot o-plenty, lack of cohesive search) to both.

So since the acceptance announcements last week, you folks have hopefully had the chance to start poking around in the community, getting your CVS accounts setup, subscribing to various mailing lists, etc. (if not, make sure you read Robert's post here: http://groups.drupal.org/node/3621).

How about a round of introductions from the SoC students, to talk a little about who you are, where you hail from, what your project's about, what your interests are, how long (if ever) you've been working with Drupal, etc.? :) There are lots of folks in the community who are very interested in what you all have planned, and would like to get to know the faces behind the projects. :)

Reply here with your bio!

The User Group Meta Group is a group focused on supporting the regional groups. Each regional group faces many of the same issues: where to advertise, what format the meetings should have, what shwag we should get, organizing meetings around major events in the Drupal community (e.g. release parties), and other issues.

If you help organize a regional user group. consider joining this group to help share successes and get tips from other group organizers.

One of the first things we to do is define the data structure that modules will use for declaring their tables. Schema module, Frando's patch, dopry's patch, and CCK fields all use different structures though their underlying approaches are basically the same. We need to decide what kind of information the data structures must contain and can contain. This will obviously include at least columns (name, type, length, nullable, default), indices (name, columns, primary vs unique vs multi), and join/relationship information.

I added two more languages for this site: Spanish and Norwegian. Remember that if you translate og you can have this site in your language.

By looking at what people described as their use case, there is a considerable amount of interest in a CAT (Computer Aided Translation) support tool in Drupal. While Drupal 6 could (and will by default or with a contrib module) provide a translation interface for nodes, content created in professional systems is often not translated inhouse, translation work is outsourced to professional translators. These professionals employ tools to remember previous translations, build on existing terminology and reuse what is already done. The industry standard for data interchange with these tools is the XLIFF format, for which fortunately Bryan Schnabel developed (and released under GNU GPL) some XSL transformations I was able to reuse.

All this resulted in the first implementation of XLIFF Tools, a module to export and import XLIFF data of Drupal nodes. I have tested some basic content nodes with Heartsome's XLIFF Translation Editor, and everything seems to be working smoothly, but there are probably hard edges you will be able to find if you try out this new tool. A development snapshot for Drupal 5.x will be available as soon as the build system generates the tarball.

With tons of help from glendac and some assistance from simplymenotu, we've created a Google map that plots where all of the local user groups are on groups.drupal.org, along with their size, as of last week sometime.

You can check it out here:

http://generator.click2map.com/maps/webchick/drupal_groups

It's very cool to see how global our little community is. :)