Uploaded image for project: 'In-Portal CMS'
  1. In-Portal CMS
  2. INP-745

Ability to have Preferred Language for Front-end Users

    XMLWordPrintable

    Details

    • Type: Feature Request
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 5.1.1-RC1
    • Fix Version/s: 5.2.0-B1
    • Component/s: Localization
    • Labels:
      None
    • Additional information:
      Hide

      Plan:
      1. add FrontLanguage column (before AdminLanguage column) into PortalUser table
      2. in UserHelper::_processInterfaceLanguage / lang:OnChangeLanguage use:

      • FrontLanguage column instead of AdminLanguage column
      • PrimaryLang column instead of AdminInterfaceLang column
      • remove isAdmin check on top of the method of course
        when login is performed on Front-End
        3. add FrontLanguage dropdown to user adding/editing page (admin), to my profile page in "advanced" theme (front-end)
        4. add AdminLanguage dropdown to admin adding/editing page (admin)
        5. make sure, that available interface languages in dropdown (when displayed on front-end only) only includes languages, that are allowed in current site domain
        6. use FrontLanguage as language for Front-End Type e-mail events (if user_id is specified in kApplication::EmailEventUser)
        7. use AdminLanguage as language for Admin Type e-mail events (if user_id is specified in kApplication::EmailEventAdmin)
        8. make sure that e-mail event language override via "language_id" send parameter (see "_getSendLanguage" method) still works
        9. placing all new e-mail event language detection logic inside that "_getSendLanguage" method would be the best choice
      Show
      Plan: 1. add FrontLanguage column (before AdminLanguage column) into PortalUser table 2. in UserHelper::_processInterfaceLanguage / lang:OnChangeLanguage use: FrontLanguage column instead of AdminLanguage column PrimaryLang column instead of AdminInterfaceLang column remove isAdmin check on top of the method of course when login is performed on Front-End 3. add FrontLanguage dropdown to user adding/editing page (admin), to my profile page in "advanced" theme (front-end) 4. add AdminLanguage dropdown to admin adding/editing page (admin) 5. make sure, that available interface languages in dropdown (when displayed on front-end only) only includes languages, that are allowed in current site domain 6. use FrontLanguage as language for Front-End Type e-mail events (if user_id is specified in kApplication::EmailEventUser) 7. use AdminLanguage as language for Admin Type e-mail events (if user_id is specified in kApplication::EmailEventAdmin) 8. make sure that e-mail event language override via "language_id" send parameter (see "_getSendLanguage" method) still works 9. placing all new e-mail event language detection logic inside that "_getSendLanguage" method would be the best choice
    • Change Log Message:
      New functionality to specify preferred Language for User
    • Story Points:
      1
    • External issue ID:
      929
    • Copy Issue Key:
    • Patch Instructions:

      Patches must be submitted through Phabricator.

      Description

      We need to create a functionality to remember User Preferred Language and then being able to apply it to Email Event sending and auto-loading User Language on Login.

      For that we should ad a NEW User field called PreferredLanguageId (default NULL) and store there user Language selection (option formatter).

      The value in this field can changed in 3 places:

      1. Front-end: Drop-down with currently available Languages (need to count in SiteDomain options) on User Profile form - user can select and save.

      2. Front-end: OnChangeLanguage event when user changes the language we can change his PreferredLanguageId too.

      3. Admin: when Admin can edit users profile.

      [B]APPLICATIONS:[/B]

      1. All Email Events should rely on new PreferredLanguageId field for language selection.

      2. Automatically Load users language (do redirect if needed) on Login if
      currently loaded and preferred languages are different.

      [B]NOTES:[/B]

      a. NULL value will indicate that we need to use Site Primary language for this User.

      b. in case if user (or Admin) has selected the Preferred Language which was disabled or removed (ID is not matching) or it's not in the list of available for current SiteDomain - system should automatically default to Front-end Primary language.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                alex Alex
                Reporter:
                dmitry Dmitry Andrejev [Intechnic]
                Developer:
                Erik Snarski [Intechnic]
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: