Contrib.social

Explain and improve the usability of dynamicly selected languages

Open on Drupal.org →
Created on 26 May 2015, about 10 years ago
Updated 16 May 2025, 17 days ago

Problem/Motivation

Opened a followup to #2420737: Differences in dynamic language names are confusing in views, content, etc. → . Following quoted from @xjm:

Here are a few outstanding questions that (as @jhodgdon points out) can probably be handled in followups:

  1. In general, I still find all this confusing and overwhelming. I looked through the hook_help() for content_translation.module, language.module, and locale.module, but still find it quite confusing. Could we add a list somewhere (like in a hook_help()) of what each of these options actually are, and link to it in the select field's description or such for each of (b), (c), and (d) from the summary? I think this is worth a followup issue.
     

  2. Regarding the option for:
    Interface text language selected for page

    @Gábor Hojtsy explained in #73:

    The first one is the language of the content in the row, the later one is the language selected for content display in general in the request. I don't think we want to use technical words like "request" on the UI? So that is why we use page.

    Okay, that makes sense. I'm still concerned about this being confused with page displays and page nodes, though, as @danigrrl also highlighted.

    I also am confused as to how the language was "selected" (by whom? where? how?). If it were the language configured for the entity or a translation thereof, or something the site user clicked on, that would make sense, but how is it "selected" for a particular request? "Selected" seems to imply human interaction, but "for the request" implies some sort of automatic calculation.

    It looks like the word "selected", "selection" is used elsewhere (looking at the "Detection and Selection settings" title and language_help(), so I get now that this is a specific term and changing it would be out of scope here.

    If folks are satisfied with this option as it is in the patch (and since the patch does accomplish the goals of making it consistent), could we do a followup issue to explore potential alternatives for "page" and for "selected"?
     

  3. I also still don't quite get the difference between
    Content language of view row
    and
    Original language of content in view row

    @Gábor Hojtsy said in #73:

    As for why there is an option to render it in the original language, this is varied based on the content, so you cannot achieve the same behavior with any of the other options. If you are to create a translator dashboard (workbench style) for example, then you would include possibilities like "List me content that is not yet translated to French" where you would need to display it in the original language (which may not be the same across all content found, so none of the other options let you make sure you rendered in a language that is available to show).

    and:

    You can either render the content in the language found or in the language the content was originally created (before possibly being translated to the language it was found in). See above for why do we have the two options. If you are to have a view to list content based on uncertain translation availability (especially to list content that is NOT available in some language), then the only language you can be sure of is available for each piece of content found is the original language it was created in. You don't know ahead of time if there was any other translations that you could render in. This makes the results consistent in the view.

    So I don't know what the "language found" means still even after reading over this for an hour. :( Is the idea that the view could be a view of (e.g.) German translations, which would be configured somewhere in another Views handler, and the first option would display the German translation in that case? If there were a word in the first option that contrasted with the second, rather than there just being an added word, maybe that would help?

    This would be worth its own separate followup, since it's Views-specific.
     

Proposed resolution

TBD

Remaining tasks

Discuss. Implement. Review.

User interface changes

Likely textual changes and more help text.

API changes

Likely none.

📌 Task
Status

Postponed: needs info

Version

11.0 🔥

Component

language system

Created by

🇭🇺Hungary Gábor Hojtsy Hungary

Live updates comments and jobs are added and updated live.
  • D8MI

    (Drupal 8 Multilingual Initiative) is the tag used by the multilingual initiative to mark core issues (and some contributed module issues). For versions other than Drupal 8, use the i18n (Internationalization) tag on issues which involve or affect multilingual / multinational support. That is preferred over Translation.

  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

  • stale-issue-cleanup

    To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 17 days ago →
    🇺🇸United States smustgrave

    Thank you for creating this issue to improve Drupal.

    We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

    Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

    Thanks!

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024