How can I disable the translation of some of the repeated strings. Such as "Apply", "next", and "Prev".

There are a number of redundant strings that should be translated once.


hass’s picture

Category: support » bug

Oh YES... But I see this as a bug. Duplicate strings need to be translated once only. We translate strings in core only once, too.

hass’s picture

Title: Too many translated strings » Translate strings only once like core
hass’s picture

Reset, sort by, etc are also shown in German when I translate to English.

miro_dietiker’s picture

No. This is how i18n objects work. We can't change that concept.

hass’s picture

Than the module has really a wrong concept. Strings need to be translated only once. I have not spend time on inner workings of the module, but what are the reasons for not using core logics for translation and just show the current interface on top?

bassam’s picture

I was going through the code and came across this function in / Line 14:

protected function build_properties() {
    $strings = parent::build_properties();
    $properties = array();
    foreach ($this->object->display as $display_id => $display) {
      $translatables = array();
      foreach ($translatables as $translatable) { 
        $key = implode(':', $translatable['keys']); // we can check the keys here, if not desired, skip
        $properties[$display_id][$key] = array(
          'title' => $display_id . ' ' . $key,
          'string' => $translatable['value'],
    $strings[$this->get_textgroup()][$this->object->name] = $properties;
    return $strings;

Can we skip the strings if they have certain keys?

Or perhaps this function in /i18nviews/includes/

function stringid($keys) {
    return 'views:' . implode(':', $keys);

If the string is shared, remove the view name from the string ID.

miro_dietiker’s picture

hass, we strictly apply the concepts of i18n object introduction:
Every object has its own context and translation happens on that level.

As with ALL i18n modules, these things can be redundant. We follow that pattern and we won't change that.

If you just want to apply the other core logic, uninstall i18nviews and switch to the core translation handler. Views elements will then be passed through t() and you can translate them in the localize admin area.

bassam’s picture

Category: bug » support

Miro, I understand i18n object logic.

However, what I'm looking for from this module is to use the translatable exposed filters.

Perhaps if you can point me to where I can change the code to remove the view name and display ID from the string ID, that would be great.

This way I can reduce the number of strings while having the exposed filters.

hass’s picture

@miro: Can you elaborate this a bit, please? I have only a very vague idea what context means here and it makes no sense to me right now. Where else are we doing duplicate translations? I'm confused, but may missed an i18n bad change in D7 days.

In my case I have a view that has several displays. All are based on the main or master display. If I translate display 1 I do expect that all other displays are translated, too. I do not create several translations for the same strings as I also have cloned the displays. The fields are all the same on all displays. If I add/modify/delte a field in master it is also deleted on all other displays, too. You break well known usability here.

hass’s picture

Issue summary: View changes

Grammar mistakes

justinmorrison’s picture

Issue summary: View changes

Is there any module that can search for similar or identical strings, and copy translated values? I find it absurd that one must redundantly enter translated text for strings that are used in multiple instances, e.g.: views titles, labels, etc.