Topics for the i18n sprint 11.-15.05.2011 in Berlin

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Lets collect and discuss what todo at the sprint on this wiki page:

i18n Modules

Drive key modules to stable release or work on improving them if they are already released.

Define extended real workflows that lead to common ml/i18n issues and write tests.

  • changing (UI / entity) language during edit cycles

Issues for the sprint are tagged as #di18nscb. Open issues:

i18n Patterns

Limit the i18n cases and define clean patterns (documentation?) for full internationalization of contrib modules such as

  • User entity translation (fullnode integration)
  • User content key translation (e.g. webform keys)
  • User fieldbased translation
  • Admin mail translation
  • Admin tool translation (e.g. view)
  • Admin variables/settings translation
  • Translation sets for things that are not nodes/entities, expand the concept from core & i18n module

Each of them in in-UI case in addition to the separate admin translation and l10n_client interface.

D7 Contrib modules

  • Write down some guidelines, handbook pages about how to make contrib modules 'translatable'
  • Add i18n support to more contrib modules.
  • Implement actual management interface for translation sets (as in core) to remove items, add existing items, etc.

D7 Install profiles

There are some install profiles on the works. We can build on them or build a new one around some specific user story.
Create a generic 'Multilingual Drupal' install profile, adding all related modules plus some basic set up,
Proof of concept for a 'Simple Multilingual Blog' install profile (still empty),

D8 planning

Instead of jumping straight into producing D8 patches, I think we should focus better on identifying the key features we want to implement, and when possible giving a try to implement them as D7 contrib modules first.

  • Discuss concepts localization VS i18n (fundamental things in common and differences!) and try to simplify them to one clean case
  • Define stable APIs that don't have gaps for application (on a wide variety of localization tasks).
  • Define patterns as documentation, how those APIs can be used to solve typical use cases.



Gábor Hojtsy's picture

There is a graphical overview of the components at

A tabular view of different translation approaches and tools is at

Tracking this for pointers to UX related issues

yoroy's picture

If you can, add a section with UX/UI related questions/issues in the wiki when you have them. Have a nice sprint!


Group organizers

Group categories

Group notifications

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

Hot content this week