translate views header / footer / Empty - Global: Text area in D7

I've got the same problem, namely always showing text in default language in views header.

I cannot for the life of me make the view header / footer appear in the strings available for translation via the "Translate Interface" menu.

Is there something I'm missing?

Note that I have the localization mode for views set to "Internationalization Views" (not Core).

Empty text was translatable (though I appear to be missing some setting that allows marked up text to be translated - "The submitted string contains disallowed HTML"), but the header and footer text are not available to translation.

I followed the "translate view" link from the view edit page as well, but this does not allow modifying the header / footer either (I assume this is simply a different interface for translating the same strings).

I'm considering enabling the PHP filter and wrapping it all in t() functions, though I understand this is not the recommended way to do it...

Did wrapping the header area in a t() function work for you? Are there any other workarounds at this point?

Should be fixed in lasted Views version. see #1290916: Header and footer are not translatable

Please save the view again, to make sure that all translations are updated. The "translation keys" above the field should look like "default header:views:area:content, default footer:views:area:content".

Screenshot attached.

With regard to #6:

I ended up using the core translation mode (from Views->Advanced Settings), for the header and footer (my understanding is that this uses the t() function internally).

What's still missing is the ability to used the translated the taxonomy terms I have in my exposed view filters.

Once the latest Views and Views Internationalization were released, I am finding the titles/headers/footers are NOT translating any more. The fields for the text areas are awesome but it just stopped working. Yet, since things are slightly in flux, it may be the way I configured it.

1. Have three languages, English, Chinese, and German.
2. Set up a view with the setting "user's current language setting".
3. Set up aliases to the view for the additional languages.
4. Content is changing successfully as well as CCK content fields.
5. Views fields do not change. Header, footer, titles, more links, etc.

This issue started more recently but it did function with the above setup. It seems related to this issue but perhaps not.

Needs fix in i18n_string. see #1238642: Strings should be able to be runned through filter_xss(_admin)

If you use PHP filter at least tags aren't stripped out, seeing this in latest released versions as of 2/04/2012, no international, only seems to fail on full/filtered html filters for both header and footer.

How can we do to have a translation of header/footer?
Still no hope to create a correct website with i18n in D7?

Strings to be run through filter_xss and filter_xss admin ca be created now, see #1238642: Strings should be able to be runned through filter_xss(_admin)

I've just upgraded to i18n-7.x-1.5 and now it saves translated footer and header with HTML but it's still not translated on the page. It seems that all previously mentioned patches are apllied. Any suggestions?

This is also an issue with the empty Global: Text

A workaround is (with some errors on the screen):

- Set translation method on admin/structure/views/settings/advanced to Internationalization Views (which is default)
- Enter the global text
- Save the view
- As a result the following error is shown:
Error: The string views:services:default:empty:views:area:content for textgroup views is not allowed for translation because of its text format.
- Go to admin/config/regional/translate/i18n_string and select "views" , click on "refresh strings"
- On admin/config/regional/translate/translate the entered text can be searched and translated.

following

@damban: There are now "Follow" buttons at the top of every issue page; you can simply press the button. There is no need to post messages just to subscribe any longer.

Marked #1607798: Header and footer translations deleted on save and #1754172: The string for textgroup views is not allowed for translation because of its text format as duplicates of this issue.

I can confirm this issue. At least in my case is happening with all the places where you can add the 'Global: Text area' or the 'Global: Unfiltered text' (at least the 'Header', the 'Footer' and the 'Empty Text' AFAICT).

In the following URL you can find a good explanation of the current workaround, but is really annoying having to do this everytime you edit a single bit in a view:
http://drupal.stackexchange.com/questions/37673/translating-views-conten...

In my case I'm using i18nviews 7.x-3.x-dev and Views 7.x-3.5

HTH

MyXelf

Seems to work on my system (D7.15 + i18n 1.x-dev + views 3.x-dev + variable 2.x-dev)

I added a (plain text, but using "Filtered HTML" text format) string in global text area, and was able to translate it into Dutch, without any warning.
Also works with HTML (for instance, an <a href...> was also translated correctly)

The steps in #16 worked for me once I checked:
"Use replacement tokens from the first row"

This checkbox appears in the view settings directly below the Custom Global text being entered.

While I didn't actually use any replacement tokens, refreshing my strings would only produce the proper string for translation when that box was checked.

Step #16 works for me on a Global text area.
The problem is that when I have to access the View in order to change it again, when I save it the translation is lost and I have to redo the process from the beginning.
The error given is the following:
The string views:course_dates_for_a_course:default:empty:views:area:content for textgroup views is not allowed for translation because of its text format.
But I have configured correctly the Translatable Text Formats.
I have also tried Step #22 but the result is the same one.
Anybody can help?

Same problem as #23.
- Selecting Translate view, select language Dutch, enter translation for the header text in Dutch.
- The header text is shown in the correct language.
- Saving the view again ( without making any changes) seems to reset/clear the translation and the default english header is used on the Dutch view. When you re-edit the translation, the english text is there again so it seems to override this each time you save a view,also for all displays !

This is a huge problem as the site in question relies heavily on multilingual views :(

#23 / #24, might be interesting to know the exact versions of ctools, i18n, i18nviews and views you guys are using (dev versions ?)

sorry for the delay, here are the versions:

- CTools 7.x-1.2
- Views translation 7.x-3.x-dev
- Internationalisation 7.x-1.7
- Views 7.x-3.5

same problem over here.

* ctools 7.x-1.2
* views translation 7.x-3.x-dev (info file from 07 / 24 / 12 @ 7:20:15pm EST)
* i18n (Internationalization) 7.x-1.7
* views 7.x-3.3

But I also have the problem that my view is warning with this message:
The string views:users:default:header:views:area:content for textgroup views is not allowed for translation because of its text format.
I have enabled the translation for the textformat in admin/config/regional/i18n/strings but I don't have the format views. Do I miss something ? Some configuration somewhere else ?

What I did now was switch back to core translation for views (i18nviews is still enabled though).
Then via a form_alter I removed the validation handler for the i18n_string_locale_translate_edit_form.
This bypasses validation so you can input HTML tags (normally inserting HTML tags in your translation returns an error because of disallowed HTML).
This makes views header, footers,... translatable if they contain HTML tags. Do make sure they're set to Full HTML.
Not the most ideal solution but it works for now - the i18nviews translation interface is much nicer and easier for clients though, so if this ever get's fixed we might use Views Translation again

Could you explain how did you do that or even propose a patch ?

Care to share your form_alter code?

Does anyone on the i18nviews team have a suggestion? I prefer to use i18nviews.

I am having the same issue with lost translations every time I save a view.

Versions:
D 7.17
i18n 7x-1.7
i18nviews 7.x-3.x-dev (2012-Jul-24)

Just chiming in. Could we at least have the project maintainer(s) verify whether this is i18nviews or views problem and forward the issue if necessary? Please. This is a well too seasoned one...

I've encountered this though I'm also using older versions of the core and modules than some of the people here. I'm reluctant to upgrade without proof that it would solve the problem. If it's relevant, the text contains html and is set to the full html input format.

I tried writing a hook to override the header but couldn't get it working. The hook I used was hook_views_pre_render(). Out of necessity, I ended up creating a template file and parsing the header.

I think this is caused by a bug in views, see #1525152-21: format_key handling broken which results in lost translations.

Please test the patch that and if you can confirm that this fixes the problem for you as well, close this issue.

I was having the problem described in #16. After several hours of debugging, I tracked it down to a bug in views. Then I checked out the latest version of Views and found that the bug had already been fixed!

In short, I agree with Berdir in #34.

I think that the reason this is hard to reproduce is that the symptom depends on your version of PHP. I get the error message with PHP 5.3.3 (and 5.3.10, IIRC) but not with 5.3.22 nor 5.4.4.

I will mark the issue as fixed, so it will stay open for two weeks after the last comment.