The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.While testing / implementing i18nviews with i18nstrings we found out that we cannot implement a clean translation layer on current localization code of views.
Calling
$views = views_get_all_views();
foreach ($views as $view) {
$view->save_locale_strings();
}
Results in totally different $source received by views_plugin_localization implementing function save($source)
array(2) {
["value"]=> string(9) "Header Text"
["keys"]=> array(6) {
[0]=> string(9) "i18n_elem"
[1]=> string(7) "default"
[2]=> string(4) "area"
[3]=> string(5) "views"
[4]=> string(4) "area"
[5]=> string(7) "content"
}
}
Compared to the keys received by the function translate_string($keys):
array(2) {
[0]=>
string(9) "Header Text"
[1]=>
array(2) {
[0]=>
string(9) "i18n_elem"
[1]=>
string(7) "content"
}
}
The keys should be fully qualified and at least contain a key that is unique per translateable element.
Also we need a clear 1:1 mapping from source locale refresh to translation request.
Note that i18nstrings has the concept of:
textgroup (here always "views")
type: a static grouping of module entities (e.g. view, display, exposed-form,) NON-hierarchical
objectid: the primary ID/machine-name of the item to translate
property: the property of the item to translate (e.g. title, desc, help, label, ...)
They get reduced to a string in the form of:
textgroup:type:objectid:property
Where property (first) and objectid (second) might be left out.
While these mechanics here might be subject to change for future releases, one thing is very important and clear:
i18nstrings NEVER EVER adds strings just by calling something like t(). It only creates translateable strings when explicitly calling i18nstrings_update.
So we need reliable locale update calls here that perfectly map to the translate_string call.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 1008358-locale-strings.patch | 11.17 KB | merlinofchaos |
| #8 | 1008358-locale-strings.patch | 10.56 KB | merlinofchaos |
| #5 | 1008358-locale-strings.patch | 9.25 KB | merlinofchaos |
| #2 | i18n.patch | 3.12 KB | dawehner |
Comments
Comment #1
miro_dietikerReferring to the origin of this issue
#1002098: Views header not translated
Comment #2
dawehnerThe real problem is that unpack_options is not 100% recursive like unpack_translations.
=> It doesn't keep track of all parents.
This patch currently adds the parents to the handler init method
But this will propably have to be added to plugins, too.
Comment #3
miro_dietikerConfirming this adds the stack of key identifiers cleanly to the stringid.
A step in the right direction.
However, during the $view->save_locale_strings() now NULL show up in the keys stack.
devel dsm:
Also still no clear mapping between the keys stack and the final string key on translate - and no api known for that.
Comment #4
dawehnerAssign to earl.
Comment #5
merlinofchaos commentedLet's try this one.
I assume for the keys stack you can just implode it with some kind of separator to turn it into a string.
Comment #6
miro_dietikerApplied patch - seems to make the interface much more consistent.
Added a test view i18n_elem as table with fields
- nid
- type
- title
- body
- edit node
This triggers the save many default elements but only some page_1 elements
The view itself only loads page_1 elements, but asks for some (field related) that where not saved.
EDIT: As soon as i override the page_1 display fields they get saved (adding a bunch more page_1 field save lines), so the translate query matches.
Comment #7
miro_dietikerAdding note:
Headers, Footers and Empty text are currently NOT translateable.
Views needs to introduce filter information to the $source context - at least on the translation save.
In addition we've noticed that the translation trigger is not called on view save.
Comment #8
merlinofchaos commentedThis patch hopefully addresses the default display issues. It does not address formatting yet. That's going to be more difficult and may be pushed out to a followup patch.
Comment #9
merlinofchaos commentedLast patch was hideously malformed. Try this instead:
Comment #10
miro_dietikerThis seems to make views 3 work cleanly.
Together with i18nviews, translation works out of the box.
Extended topics / features such as translation field format has not been checked.
Comment #11
merlinofchaos commentedCommitted to D6. Marking for port to D7.
Comment #12
dawehnerCommited to 7.x issue.