Object translation: Extend the locale system to support translatable objects (i18n sprint)

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

In our first i18n sprint scoping session we identified two basic goals to make Drupal fully multilingual:

  • Object translation. Make object names and labels translatable. I.e. content type names and descriptions, field titles and descriptions, etc..
  • Content translation. Make user created content translatable.

About the first one, as these are usually admin defined strings, we need a translation system that is at the same level than the hardcoded string translation. Site translators don't even need to know whether they are translating a hardcoded string or an admin defined one (like content type name) so there's an agreement a uniform translation interface is needed for this.

The current locale system with already built-in support for text groups seems like the best place to translate too this user (admin) defined strings. Thus the starting point will be to add support into the locale system for user defined strings. Thus our development proccess and priorities will be as follows:

  1. Add locale support for user defined strings
    1.a. Extend locale data api to work for different text groups, and search strings indexed by other fields than the string source (textgroup, location).
    1.b. Define a workflow for adding / updating / tracking and translating these user defined strings, with its corresponding API

  2. Make objects translatable through the localization system
    2.a. Build a uniform object agnostic mapping from object strings to locale strings. This may be a schema based one, on which fields marked as 'translatable' will have an automatic mapping into a key for string searching.
    2.b. Implement this object translation for a specific set of objects. Candidates here are: content types, fields (title and description), menu items.
    2.c. Once we have this system built, we need to consider whether this is suitable for textual variable translation or we need something else.

Other considerations:

  • There's some agreement that the best place to implement object translation is not when the object is loaded but right before rendering, if possible. This should save us lots of translation cycles for objecs that won't be finally displayed.
  • We need to keep track of these source strings and mark them as updated when they need retranslation
  • As these are limited object sets (content types) we can implement full caching for some of the groups
  • For user defined strings, we need a primary language to translate from. This will be in principle the site's default language which raises a question, to be handled later: what happens when you change the default language?

Focus issues in queue:

Other related issues:

Internationalization

Group organizers

Group categories

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: