-
-
Notifications
You must be signed in to change notification settings - Fork 817
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow override of inherited CMS language when in CiviCRM #17006
Conversation
(Standard links)
|
I think it's generally OK, but we should double-check any help texts to make sure it's not too confusing. For example, the help text on "inherit language" says:
and this is not really true anymore if we merge this PR. One could change the language using the language switcher, then use the CMS language switcher, and be really confused about why this is not changing the language? We should tweak to "CiviCRM will set the initial session language, which can later be changed if using the language switcher", but few admins will see it or remember that when using CiviCRM. ping @demeritcowboy (relates to issues you raised recently about the lcMessages param, which we want to deprecate since not Angular-friendly) |
I think that tweak makes sense. The inherit from CMS option currently seems backwards to me, i.e. is there a reason, other than history, that it couldn't be "just inherit, and then allow an override in civi"? By using a language switcher for example - which is related to the other ticket about possibly making it a native menu option instead of by url or drupal-only block (which uses url). By the way I did start taking a look at the kamlanguage extension but got sidetracked. |
47cc608
to
c6cc337
Compare
@demeritcowboy @mlutfy It now looks like this: Hopefully that is ok? I switched the field to use metadata instead of hardcoding descriptions in the template. |
Something weird with karma tests aborting. Jenkins test this please. |
Will this need a docs update? Maybe; https://docs.civicrm.org/user/en/latest/initial-set-up/installation-and-basic-set-up/#localization |
Noting that a request for comments had been put out in chat on the 17th by @mlutfy: https://chat.civicrm.org/civicrm/pl/mdzrygkzmbfx8f8h9g3rodyz8w and no objections seem to be noted. |
When language switcher was separated from multi-language, we let 'Inherit CMS language' cause language switcher to be hidden to limit confusion for those already managing multiple languages via the CMS. Providing the precedence of the CMS and Civi settings are clear and documented, this change looks good. |
Docs issue here civicrm/civicrm-user-guide#443 |
Merging based on approval from @aydun @demeritcowboy @mlutfy |
According to #17919 (comment) this caused a regression |
@eileenmcnaughton Yes, it's been a bit of a game of whackamole - me and @christianwach had a chat about the language issues and concluded that the only way to fix things properly is to make sense of and completely refactor the |
Overview
If inheriting the CMS language you cannot change the language in CiviCRM backend anymore using
lcMessages=en_GB
URL parameter (which sets the language for the session).With "inherit CMS language" contribution pages etc. track the CMS language which is usually a good thing. But if you, for example, have an extra language on the backend that is not available on the frontend you cannot select it.
Also, you cannot select which languages should be "available" because the available languages selector is hidden. This means that you a) have to pre-download any languages you might use. b) Can only limit the available CiviCRM languages by deleting the language files. c) Can't use an extension like l10nupdate to automatically download language files.
Before
lcMessages
parameter.After
lcMessages
parameter.Technical Details
Comments
@mlutfy @MikeyMJCO thoughts please?