@Eugene Bocharov

I've added test just for returning value type, because, as for me, checking exact value returning from TranslatableMarkup looks more like test for translating system, which should be done (and obviously done) in another place.

Added test of return value type.
Removing "Needs change record updates", see #19, #20

The change record states that this currently always returns the English but that will not be true for sites that install with a language other than English. Adding tag for CR update.

Hm, I can not see how it's possible.
Currently it returns

return $days[$dow]->getUntranslatedString();

But this returns TranslatableMarkup::$string, which is just string passed to the constructor. And both DateHelper::weekDays() and DateHelper::weekDaysAbbr() pass English strings to the t(). Please, correct me if I'm wrong.

Thank you, @joao.ramos.costa ! Turning to RTBC as #7 is fixed. Now there is no deprecation anymore as there is no unneeded dynamic property.

I've updated doc comment, please review.

Yes, but previous change might have broken sites that used original behavior of the method. Here we just return to original state. It is over the year since last change though. So I'm not sure what's the best solution at this point. There might be broken expectation either way.

Opened MR to 11.x

Eugene Bocharov → changed the visibility of the branch 3456417-datehelperdayofweekname-returns-untranslated to hidden.

Thank you @Pablo_Pukha, this is exactly what we need. I just added fix for test.

Eugene Bocharov → created an issue.

Thank you @griz ! You save my day)

Can someone explain why we return untranslated string, though the comment says that it should be translated?

  /**
   * Returns translated name of the day of week for a given date.
   *

return $days[$dow]->getUntranslatedString();

Seems it was brought by these changes.

May be this option has never worked as described in the setting description

"If selected, users can enter multiple values in the form of 1+2+3 (for OR) or 1,2,3 (for AND)"

Earliest version of the module where I was able to find this option is Views 6.x-2.x-dev and there is almost the same logic as in current module state. Both '+' and ',' are implemented with OR logic.
Even tests in \Drupal\Tests\views\Kernel\ModuleTest expect that values, divided by ',' will select items using OR.

If so, and it's never worked other way, we should consider this functionality as a new feature and provide some extra setting to choose whether to use ',' for AND operator and '+' for OR, or both for OR as it works now. Otherwise we can break sites that relies on current behavior of ',' divider.

The patch from #113 is not applicable to 10.2, here's the patch #120 with small but important fix

+    if (once('exposed-form', this.$exposed_form).length) {
+      this.attachExposedFormAjax.bind(this)
+    };

replaced with

+    if (once('exposed-form', this.$exposed_form).length) {
+      this.attachExposedFormAjax();
+    };

otherwise this.attachExposedFormAjax.bind(this) just binds this, but not call the function, so exposed forms don't work by AJAX

Added logic for the 'Exclude' option. Tests are still needed.

This is a starting point to solve the issue. Though it should work for common use cases. But, for now, it will not work as expected if 'Exclude' option enabled. It should be possible to implement this as well using subquery. Also tests needed.

I've started issue fork and attaching the patch for 11.x. And, as I can see, it can be used with 10.2 too.

Eugene Bocharov → made their first commit to this issue’s fork.

Indeed changing data type for the field labels from "string" to "label" makes sense, as they should be translatable. It might be something like this:

core.entity_view_display.*.*.*.third_party.entity_print:
  type: sequence
  label: 'Schema for Entity Print third party settings'
  sequence:
    type: label
    label: 'Extra field labels for each export type'

But seems it still will not be possible to edit translation using UI until Entity view/form mode formatter/widget settings have no translation UI 🐛 Entity view/form mode formatter/widget settings have no translation UI Needs review resolved.

For now it possible to use one of 2 solutions:

1. use patch from #21 and translate with user interface translation
2. create translation YAML config files for needed content type display modes manually and import them, for example core.entity_view_display.node.article.default.yml . As I can see, it works even without changes in config schema.

Example of the translation file

third_party_settings:
  entity_print:
    pdf_label: 'Ver PDF'
    epub_label: 'Ver EPub'
    word_docx_label: 'Ver Word Document'

Merge request #24 based on patch from #10 with some changes:

• using data-* attributes instead of CSS classes for header and footer area to keep consistency with views content selectors
• JS code improvements without changing the logic
• added comment about using @start token in README

Using @start token with infinite scroll module looks like non-trivial task. Actually @start on infinite scroll views can be 0, 1 or another number if query has page parameter and thus view initially has offset. As on AJAX request for load more views still gets from database not all records but only next range of items it make sense that @start is replaced with offset on the back-end. And as soon as the views_infinite_scroll does not replace items but append them on the front end using JS, probably it would be better to control those tokens on the front end as well. It might be possible if tokens had some wrappers but they don't have. So for now I would suggest just not use @start token in infinite scroll views and use something like Displaying @end of @total

Attaching patch file in addition to MR for 2.0.x.

Eugene Bocharov → made their first commit to this issue’s fork.

Looks like the SelectTranslation::$valueTitle is not used anywhere. The only place where I can found reading from valueTitle is \Drupal\views\Plugin\views\filter\InOperator, but SelectTranslation inherits from FilterPluginBase. Checked the form, I don't see the 'Select translation filter' text there. So probably we can just remove it.

Eugene Bocharov → made their first commit to this issue’s fork.

I would suggest just to allow NULL for \Drupal\views\Plugin\views\argument\ArgumentPluginBase::$operator

@@ -108,7 +108,7 @@ abstract class ArgumentPluginBase extends HandlerBase implements CacheableDepend
   /**
    * The operator used for the query: or|and.
    */
-  public string $operator;
+  public ?string $operator;

The issue is relevant to webform pages as well. I think it make sense to not extract language from any config entity, not only Views.

Thank you @grota for the module and for fixing this

Here is the patch to fast fix. Not sure if this is the best solution, it just prevent throwing the exception on any NullBackend in \Drupal\prometheusio_exporter\Prometheus\Storage\DrupalCache::__construct()

I have the similar issue on drush updb

  Please configure the drupal prometheusio_bin cache bin to use either  
  - cache.backend.permanent_database                                    
  - cache.backend.permanent_redis                                       
  - cache.backend.permanent_memcache 

Could you please dump the value of get_class($cacheBackend) here in the constructor and report back? (there might be other modules that are incompatible with this one)

It seems that during drush updb $cacheBackend is instance of \Drupal\Core\Update\UpdateBackend which wraps \Drupal\pcb\Cache\PermanentDatabaseBackend