Jump to:
| Project: | Internationalization |
| Version: | master |
| Component: | Experimental modules |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
The Strings module provides valuable helper methods for module authors wishing to make their custom data translatable. Yet usage is complex. It would be useful to save module authors the heavy lifting.
What's the most basic place we can designate a piece of data as subject to translation? Probably, it's in the schema.
If we designate fields as 'translatable' in the schema, that should provide the information needed to programmatically determine how to translate them.
Based on i18nstrings, the attached module provides schema-based translation. Using logic based on the approach we use in drupal_write_record(), the schema is consulted to determine whether and how to pass fields for translation.
To illustrate how it works, I've included a patch for the scaffolding_example module (an example module in drupal docs).
This patch demonstrates just how quick translation becomes for authors of basic modules. A few parameters in the schema, three or four lines added when saving or presenting data, and you're done.
Would this be a desired addition to i18n? Comments on the implementation? Further ideas?
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| translate.tar_.gz | 3.39 KB | Ignored | None | None |
Comments
#1
Please, never do such things with translatable strings
t(ucfirstas it would become difficult to translate correctly. Aside - there is a drupal_ucfirst that should be used.#2
I'm working on a site where the interface language (menus, etc.) can be different than the content language. You may be Spanish, want to have your menus in Spanish, but read a given article in English because the Spanish translation isn't very good (and you are at ease with English!).
The 'tt' function uses the interface language, not the language of the current node. So using tt to translate the value of fields means I wouldn't be able to view a page in English, while keeping my menus/etc. in Spanish.
The translate_record should be able to take some context - at least a language, or the current node from which the current language can be derived, so that it can translate in the content language, not interface language.
#3
Interesting approach!
How would this work for modules that primarily present their fields joined with other tables - is there a way they could use this also?
#4
Hey nedjo, this looks really interesting!
Right now, I want to get out a 6.0 stable version ASAP but right after that I think I we can mix this one into i18n package and build on that.
Then we should be thinking about some general guidelines for contrib modules to have their stuff translated, something like this, http://groups.drupal.org/node/15177
#5
Before getting i18n out it should first follow the well known translatability rules we can found in the API docs about t() http://api.drupal.org/api/function/t/6 and patch in #310852: Context sensitive translation issues needs to be committed. If i18n themselves doesn't follow the development rules for t() - I don't know how others should follow them. i18n should be one of the good examples that users can follow - except core that is known to be good.