Lets collect and discuss what todo at the sprint on this wiki page:
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: https://drupal.org/project/issues/search/?text=&assigned=&submitted=&par...
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.
- Continue integration of Drupal Commerce: http://drupal.org/node/1032302
- 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, https://drupal.org/project/drupali18n
Proof of concept for a 'Simple Multilingual Blog' install profile (still empty), http://drupal.org/sandbox/reyero/1155834
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.