Uploaded image for project: 'Blesta Core'
  1. Blesta Core
  2. CORE-1320

Add a language selector to non-authenticated client pages if multiple languages are installed for the company

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.2.0
    • Fix Version/s: 4.1.0-b1
    • Component/s: Client Interface
    • Labels:
      None

      Description

      Currently only the companies default language is displayed throughout non-authenticated client pages. If multiple languages are available for the company, display a language selector on non-authenticated client pages.

      More details to follow in terms of design/mockups.

      NEW

      After thinking about this and reviewing the comments, the language selector should appear in the upper right of the client area and be visible on all pages. This will either be in the upper-right most of the page, or within the navigation bar to the right on either side of the Login link. My preference is in the upper right above the navigation bar. Need to be sure that it doesn't interfere with the "Return to Staff Portal" link, or move that link.

      This should appear as a link with a menu, similar to bootstrap's drop down menu, and not a dropdown form.

      The selector should only appear if there is more than 1 language installed. By default, it would not appear because Blesta only ships with en_us.

      OLD

      Use the current footer markup if the language selector is not displayed, otherwise use the following markup:

      <div class="row footer">
      <hr>
      <div class="col-md-10 col-sm-9 col-xs-8">
      <p>Powered by <a href="http://www.blesta.com/">Blesta</a>, © Phillips Data, Inc.</p>
      </div>
      <div class="col-md-2 col-sm-3 col-xs-4 pull-right">
      <form>
      <select class="form-control">
      <option>English, USA</option>
      <option>English, UK</option>
      </select>
      </form>
      </div>
      </div>

      NOTE! The <hr> tag is moved up, directly below the row footer. This change can be made in both cases. If the language selector exists, then we have 2 divs, and the "Powered by" paragraph is no longer centered. It looks better aligned left when there is a drop down aligned right.

      This drop down only applies to non-authenticated client pages

        Issue Links

          Activity

          Hide
          cody Cody Phillips (Inactive) added a comment -

          Why not just add this to the footer for the core so it can be available everywhere? Otherwise we'll find ourselves receiving requests for it to be on the Support Manager, and every other public facing plugin.

          Show
          cody Cody Phillips (Inactive) added a comment - Why not just add this to the footer for the core so it can be available everywhere? Otherwise we'll find ourselves receiving requests for it to be on the Support Manager, and every other public facing plugin.
          Hide
          admin Paul Phillips added a comment -

          Perhaps, but it should only be visible to non-authenticated users. Clients may change their language already in the client area.

          Show
          admin Paul Phillips added a comment - Perhaps, but it should only be visible to non-authenticated users. Clients may change their language already in the client area.
          Hide
          admin Paul Phillips added a comment -

          Additionally, the order plugin may need to be updated to set the client (on new registration only) to use the selected language during checkout.

          Show
          admin Paul Phillips added a comment - Additionally, the order plugin may need to be updated to set the client (on new registration only) to use the selected language during checkout.
          Hide
          tyson Tyson Phillips (Inactive) added a comment -

          A language-selector may be useful for every page, including for staff users. For example, when a staff logs in as a client they may want to see the UI in the client's language rather than their own.

          Show
          tyson Tyson Phillips (Inactive) added a comment - A language-selector may be useful for every page, including for staff users. For example, when a staff logs in as a client they may want to see the UI in the client's language rather than their own.
          Hide
          cody Cody Phillips (Inactive) added a comment -

          This would require the language to be stored in the user session, in which case if a user selects language B, then logs in and their user language is language A, we should maintain the language B setting. This would require that we offer the language selector even on authenticated pages.

          Show
          cody Cody Phillips (Inactive) added a comment - This would require the language to be stored in the user session, in which case if a user selects language B, then logs in and their user language is language A, we should maintain the language B setting. This would require that we offer the language selector even on authenticated pages .
          Hide
          admin Paul Phillips added a comment -

          Why would we need to offer the language selector on authenticated pages? If we are a staff member authenticated as a client, couldn't we show the selector to staff only? In such a case, the language selector would only be visible on authenticated client pages when staff uses the "login as a client" feature.

          Show
          admin Paul Phillips added a comment - Why would we need to offer the language selector on authenticated pages? If we are a staff member authenticated as a client, couldn't we show the selector to staff only? In such a case, the language selector would only be visible on authenticated client pages when staff uses the "login as a client" feature.
          Hide
          cody Cody Phillips (Inactive) added a comment -

          Why would we need to offer the language selector on authenticated pages?

          Because we must store the preferred language in the user's session. If the user is authenticated we should maintain this preference. So users must have a way to change their selected language (again, stored in their session) after being authenticated.

          Plus, it just makes more sense to be consistent with language selection. Disappearing UX controls when a user authenticates seems like bad UI.

          Show
          cody Cody Phillips (Inactive) added a comment - Why would we need to offer the language selector on authenticated pages? Because we must store the preferred language in the user's session. If the user is authenticated we should maintain this preference. So users must have a way to change their selected language (again, stored in their session) after being authenticated. Plus, it just makes more sense to be consistent with language selection. Disappearing UX controls when a user authenticates seems like bad UI.
          Hide
          admin Paul Phillips added a comment -

          How often do clients change their language? Once they sign up, assuming they can select their language during checkout (this task), they are unlikely to need to change it again, ever. If they do need to, they can do so by editing their account. Always displaying a language selector clutters the UI unnecessarily.

          The necessity for staff to see a language selector is due to requests to show the client area in the clients language to staff. But, not all staff will want to see it that way, hence the selector.

          Show
          admin Paul Phillips added a comment - How often do clients change their language? Once they sign up, assuming they can select their language during checkout (this task), they are unlikely to need to change it again, ever. If they do need to, they can do so by editing their account. Always displaying a language selector clutters the UI unnecessarily. The necessity for staff to see a language selector is due to requests to show the client area in the clients language to staff. But, not all staff will want to see it that way, hence the selector.
          Hide
          admin Paul Phillips added a comment -

          See attached screenshot, I imagine the language selector should look like this. In this case, the "Return to Staff Portal" link is off to the left.

          Show
          admin Paul Phillips added a comment - See attached screenshot, I imagine the language selector should look like this. In this case, the "Return to Staff Portal" link is off to the left.
          Hide
          tyson Tyson Phillips (Inactive) added a comment -

          Seems like the selector would need to be in the admin interface too, otherwise they will see the language they chose in the client UI when they go back to the staff portal.

          Show
          tyson Tyson Phillips (Inactive) added a comment - Seems like the selector would need to be in the admin interface too, otherwise they will see the language they chose in the client UI when they go back to the staff portal.
          Hide
          admin Paul Phillips added a comment -

          Perhaps the option should not be displayed to staff who are "logged in as" a client if that is the case. I do not want this feature to have any impact on the staff interface.

          Show
          admin Paul Phillips added a comment - Perhaps the option should not be displayed to staff who are "logged in as" a client if that is the case. I do not want this feature to have any impact on the staff interface.
          Hide
          tyson Tyson Phillips (Inactive) added a comment -

          Doesn't that behavior contradict the point of staff logging in to to the client UI to see what they see? I imagine staff may also want to test that clients see the language selector, or could tell them it's there if they were on the phone with them or something. It usually makes sense for UI changes like this to be consistent.

          Show
          tyson Tyson Phillips (Inactive) added a comment - Doesn't that behavior contradict the point of staff logging in to to the client UI to see what they see? I imagine staff may also want to test that clients see the language selector, or could tell them it's there if they were on the phone with them or something. It usually makes sense for UI changes like this to be consistent.
          Hide
          admin Paul Phillips added a comment -

          It's not a big concern that the language selector not appear when staff are "logged in as" a client, but I do agree that consistency across the client interface is ideal. However, I do not want to add any such selector to the staff interface If Staff change the language within the client area, it should be ephemeral, not saved for the client language, and not impacting the admin's language within the staff area.

          Show
          admin Paul Phillips added a comment - It's not a big concern that the language selector not appear when staff are "logged in as" a client, but I do agree that consistency across the client interface is ideal. However, I do not want to add any such selector to the staff interface If Staff change the language within the client area, it should be ephemeral, not saved for the client language, and not impacting the admin's language within the staff area.
          Hide
          admin Paul Phillips added a comment -

          Markup Attached

          There will need to be 2 new Client Theme colors: Top Navigation Text Color, and Top Navigation Text Active Color, whose placement is indicated in the CSS attached. I still need to come up with default colors for the FOUR client theme, and other themes.

          Show
          admin Paul Phillips added a comment - Markup Attached There will need to be 2 new Client Theme colors: Top Navigation Text Color, and Top Navigation Text Active Color, whose placement is indicated in the CSS attached. I still need to come up with default colors for the FOUR client theme, and other themes.

            People

            • Assignee:
              jonathan Jonathan Reissmueller
              Reporter:
              admin Paul Phillips
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Fix Release Date:
                17/Jul/17

                Agile