Views user language field/filter is for original language code, no translation language field/filter

Well, so the fun thing about users is they may have 3 different languages on them. Woot, right? :D They are the following:

- langcode: Original submission language of the entity
- preferred_langcode: The user's language preference.
- preferred_admin_langcode: If the admin language negotiation is enabled, the user's admin preferred language.

To complicate matters a bit, the language the user can set by default is BOTH the first two at once and the third one (if admin language preference is turned on). It is theoretically possible that a user would have their profile fields in a different language to their preferred language, but not very likely. If so, we have this code in AccountForm.php that addresses that:

    // User entities contain both a langcode property (for identifying the
    // language of the entity data) and a preferred_langcode property (see
    // above). Rather than provide a UI forcing the user to choose both
    // separately, assume that the user profile data is in the user's preferred
    // language. This element provides that synchronization. For use-cases where
    // this synchronization is not desired, a module can alter or remove this
    // element.
    $form['language']['langcode'] = array(
      '#type' => 'value',
      '#value_callback' => '_user_language_selector_langcode_value',
      // For the synchronization to work, this element must have a larger weight
      // than the preferred_langcode element. Set a large weight here in case
      // a module alters the weight of the other element.
      '#weight' => 100,
    );

So the User's preferred language may or may not be the same as the original entity language. I think naming this the "Original language" like we did for nodes is better for consistency. We may also want to expose the other two languages to views in some ways, but they are less useful I guess. Knowing those would be great for heavy duty admin views probably.

+++ b/core/modules/user/src/UserViewsData.php
@@ -350,6 +222,9 @@ public function getViewsData() {
 
+    unset($data['users_field_data']['signature']);
+    unset($data['users_field_data']['signature_format']);
+

I don't get that ... what is the reason to not get integration for it?

Changes look good to me in this patch especially the fix of the admin/non-admin language preferences that was backward before (oops).

Re #10, the extended context of the changes looks like this, showing the code just removes the default values and adds custom values conditionally:

+++ b/core/modules/user/src/UserViewsData.php
@@ -350,6 +222,9 @@ public function getViewsData() {
+    unset($data['users_field_data']['signature']);
+    unset($data['users_field_data']['signature_format']);
+
     if (\Drupal::moduleHandler()->moduleExists('filter')) {
       $data['users_field_data']['signature'] = array(
         'title' => t('Signature'),

Because this already does some refactoring to take the default values from the base class instead of having brand new values generated solely in this class, I think we can keep the scope as-is and not change this part (which is not related to language either). The patch does not change behaviour in my understanding in that part.

So overall looks good to me :) Thanks for the screenshot of the different user language options.

Looks good. Committed 8c2b42d and pushed to 8.0.x. Thanks!

Whilst reviewing the patch I noticed that the filter format used for user signatures is the fallback format and not the one the user has chosen - that's problematic and we should open a followup to fix that.

Thanks so much for sticking to this, consistency is amazing!