Problem/Motivation

In English, in the Views UI, at the top there is a list of links that lets you add Block, Page, etc. displays to your view. It looks like this:
Add display on a view in English

If you look at the HTML though, actually each entry in the list has a link that says "Add Block", "Add page", etc. But something is being done in JavaScript to remove the word Add.

This doesn't work in Hungarian, because the order is reversed -- instead of "Add ____" it says "____ hozzaadaza" (forgive me for butchering the Hungarian). And the Add at the top says Hozzaadas -- capitalized and not the same word. I haven't looked at the JavaScript, but I think it must be somehow looking for the word "Add" at the beginning to be repeated in each link and removing it? Anyway, it doesn't work in at least this one other language. Here is what it looks like:
Add display on a view in Hungarian

(I noticed this because I was making automated screenshots for the User Guide in Hungarian, and it didn't look the same as my English screenshot.)

Proposed resolution

Either:
(a) make the links actually say just "Block", "Page", etc. without the funky JavaScript thing going on
(b) fix the funky JavaScript thing so it will work in other languages
(c) decide this is unimportant and do not worry about it in other languages
(d) don't do it at all even in English

Remaining tasks

Decide what to do, and do it. Or close this as "Won't fix".

User interface changes

Possibly.

API changes

No.

Data model changes

No.

Comments

jhodgdon created an issue. See original summary.

jhodgdon’s picture

FileSize
18.27 KB

And by the way, it doesn't work in Catalan either. In this case, the word "Add" apparently comes first in the strings, unlike Hungarian where it comes last, but it is still not removed from "Afegeix Bloc" etc. See screenshot:
Add display on a view in Catalan

jhodgdon’s picture

Title: Funky code in Views UI to make Add display list doesn't work in Hungarian » Funky code in Views UI to make Add display list doesn't work in non-English languages
Status: Active » Needs review
FileSize
1.25 KB

Here's the code that is doing this. It's in core/modules/views_ui/js/vies-admin.js in class/objectDrupal.behaviors.viewsUiRenderAddViewButton:

      var $addDisplayDropdown = $('<li class="add"><a href="#"><span class="icon add"></span>' + Drupal.t('Add') + '</a><ul class="action-list" style="display:none;"></ul></li>');
      var $displayButtons = $menu.nextAll('input.add-display').detach();
      $displayButtons.appendTo($addDisplayDropdown.find('.action-list')).wrap('<li>')
        .parent().eq(0).addClass('first').end().eq(-1).addClass('last');

      // Remove the 'Add ' prefix from the button labels since they're being
      // placed in an 'Add' dropdown. @todo This assumes English, but so does
      // $addDisplayDropdown above. Add support for translation.
      $displayButtons.each(function () {
        var label = $(this).val();
        if (label.substr(0, 4) === 'Add ') {
          $(this).val(label.substr(4));
        }

So. The comment here is incorrect, because the variable $addDisplayDropdown a few lines up is actually translating the word "Add".

And what really needs to happen here is ... Hm. The label here is actually coming from a call in PHP to t('Add @type') with the @type substituted in from a call to something like t('Block') or t('Page') or t('Attachment') [the defined types of displays you can add]. So the JavaScript needs to call Drupal.t('Add @type') and then figure out where the "@type" appears in the string for the current language. Then it can extract that out.

For instance, if the translation of "Add @type" is something like "Foo @type barz", then it would need to take a substring that chops off the first 4 characters and the last 5, to find the "@type" portion of the label. If @type is at the start, then don't chop off anything at the start; if it's at the end, then don't chop off anything at the end. Pretty easy to calculate and achieve, using the JavaScript substr() method on strings. str.length(4) would take everything starting at character 4 to the end of the string, and str.length(-5) would take everything but the last 5 characters.

Let's see... how about this patch? I'm testing it in English, Hungarian, and Catalan by making User Guide screenshots, and will posts them when the tests finish. Or post a better patch if it doesn't work right. ;)

jhodgdon’s picture

That patch wasn't quite right. Here's a new one that works for English, Hungarian (where "Add" is a suffix), and Catalan (where "Add" is a prefix, but not 3 characters long). And some screenshots.
English:
English add display with patch
Hungarian:
Hungarian add display with patch
Catalan:
Catalan add display with patch

jhodgdon’s picture

Issue tags: +D8MI, +language-ui, +JavaScript

Adding some tags.

Also note that the CSS for this drop-down needs some adjustment probably, but that was present in the "Before" screenshots in the issue summary, and fixing it is probably out of scope for this issue. (The left side of the buttons in the drop-down list is cut off for some reason by the CSS.)

dawehner’s picture

Interesting, nice catch!

droplet’s picture

will it work?

dawehner’s picture

This is just beatiful! Thank you @droplet. Can we add some javascript test to ensure the UI works in the other language as well?

jhodgdon’s picture

Yes, it definitely makes the JS code much less funky! A good thing.

droplet’s picture

Issue tags: +Needs JS testing, +Needs tests

Any D8MI member could suggest me an efficient way (programmatically, I guess?) or help to write a patch for "Enable & Import second UI Lang" part.

jhodgdon’s picture

You'll need to have the modules language and locale enabled.
Then in your test you can go to admin/config/regional/language/add and submit the form there with drupalPostForm, using something like

$edit = [
  'predefined_langcode' => 'es',
]

and hitting the button 'Add language'.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.