With over a dozen active participants and major progress on four significant patches, plus several smaller fixes, the first day of the Internationalization in Core virtual code sprint was nothing short of amazing! And if you want to join in, please do! We'll be in #drupal-i18n on IRC tomorrow (Wednesday) starting around 9:00 GMT and going until after midnight GMT. Never applied a patch before or checked out code from CVS? Don't worry, we can get you started. Here's a rundown of the day.

Goals

Our first task was to set some goals. We quickly reached consensus on a core aim: "There is a solid solution for translating arbitrary objects in other contexts, e.g. variables, menu items, custom objects in contrib modules". From there, the first and foremost distinction we made was between user-facing "content translation" (e.g. field contents) and admin-facing "object translation" (e.g. field definitions, like labels, descriptions). These two probably need distinct solutions.

Making Fields translatable

We decided early on that Fields API is our best bet for making user-facing, content-like properties translatable. We defined a target use case for content properties. For users, an admin defines an optional 'biography' field where users can put their bios. These should be translatable so that users viewing a profile in another language will see some fields untranslated (e.g., postal address), but the biography field (and maybe others) are translated. This is exactly the sort of use case that the new Fields API is built for. With the fields API, a biography can be added as a field. So, if the field is somehow multilingual, we're set. This also enables us, when rendering, to load the translations as part of the original load instead of the costly process of: load original, then for each translatable property do a new query at display time to fetch the translated string. For the fields api work, we broke the approach into two issues. First, http://drupal.org/node/367595, Translatable fields. This is in the fields api per se, to make fields multilingual. Second, http://drupal.org/node/368823, Add #translatable support to content rendering. This is a patch on drupal_render(). On rendering, we need a way to render for a specific language for translatable items. We touched base with Barry and Yves, two of the main Fields API authors, and hope to get some more feedback tomorrow or later in the week. This is all rough as yet, but it feels like a pretty promising direction. If fields can be translatable, we're leaps ahead of where we've been.

Extending the locale system to handle user-defined strings

The other major translation need would be handled by the 2nd of our two main coding focuses, which starts with new APIs for the locale system. The initial draft is here: http://drupal.org/node/361597#comment-1237266, Write locales data API. The idea is: For D6 the locale system was expanded to work for more than just code-based strings, but we don't yet have any methods in core to handle this. So with locale, we're starting with some APIs that we can use to replace the existing hard-coded queries *and* for new methods for non-code-based strings. In drafting a set of API functions for locale, we included some new general use functions for loading and deleting records, parallel to drupal_write_record(). These should be useful both in the new locale APIs and in many other places in core and contrib.

Improving the UI for editing string translations

The remaining significant issue worked on today is http://drupal.org/node/52990#comment-1236808, Improve translation string search and editing interface. This picks up on a long-established need to improve the UI for finding and editing translations. Roger Lopez, stella, and meba worked on this one today. As it is now, you have to resubmit the search form from scratch after every string edit--a major usability pain. The patch basically follows what's done for other forms (db_log, node administration) to retain context when editing a bunch of strings. So this is a big usability gain, even if it doesn't yet address the other problems with this interface. I'm hopeful that http://drupal.org/node/52990 might be good to go by tomorrow.

Bugfix along the way

In the midst of the sprint we hit a bug in installing in languages other than English. Bug? No problem, we're sprinting, we can take care of that! A quick patch, http://drupal.org/node/368729, Installation fails with language profile, some peer testing, and we have our first RTBC patch of the sprint. Plus work was begun on several other issues that should get new patches soon--maybe as early as tomorrow.

Angie updates

To wrap off an amazingly productive day, we updated Drupal 7 maintainer Angie Byron in IRC. She was keen and appreciative of the progress and excited to see more. And our RTBC patch? She applied it on the spot. And she set me some homework, starting with writing up this sprint update ;) Thanks to all participants for a rewarding day of working together. I'm looking forward to seeing many of the same IRC names and hopefully some new ones as well as we continue the sprint tomorrow and then pick up again on Tuesday and Wednesday of next week. It was great to work with several developers I haven't had a chance to work with before. We're already seeing the beginnings of some major improvements to multilingual support for Drupal 7. Way to go sprinters!