User tests: Successful: Unsuccessful:
Conditions
Create a multilanguage site with 2 languages for example at Joomla installation time. Then install a 3rd language. Do not create a Content Language for that 3rd language.
Result => when the user logins, he is redirected to the unexisting Content Language and it breaks the site.
The reason is that we use the normal $type field 'language' for the user to choose his default site language among all those installed.
This PR creates a new $type field which will only display the choice between installed languages which are enabled, have a related published Content language and a related Home page.
When a site is multilingual, the $type field will be changed from the "normal" one to this specific one to avoid the error.
To test the patch, for the third language installed, create or not a content language and change it to published or not, its home existing or not , published or not.
In this example, I have installed the Catalan language and created a Content Language for it and no specific menu with a Catalan Home page:
Screenshot of the installed languages:
Screenshot of the Content Languages:
Screenshot of the "Frontend Language" dropdown choice when editing a user profile
BEFORE PATCH: => Catalan is proposed as a choice
AFTER PATCH: => Catalan is NOT proposed as a choice anymore
Labels |
Added:
?
|
Easy | No | ⇒ | Yes |
Category | ⇒ | Multilanguage |
Status | Pending | ⇒ | Ready to Commit |
RTC. Thanks
Labels |
Added:
?
|
Thanks for testing.
before merging, let's @phproberto have a look at the new field.
Before merging isnt this a B/C break
(I am a little confused. I do understand that this is addressing a redirect
bug BUT this also introduces changed behaviour)
Previously Joomla could be used with any installed site language it did not
have to be a content language. This meant that the Joomla language strings
would be in the selected language but content would still be in the default
content language. That might not have been a normal thing to do but it has
been possible since Joomla 1.0.
A use case for this would be where the content is all in french but the
administrator only speaks english. Previously they would set the site
language for themselves to be english and the content wold not change but
the administrator would be able to read all the system messages and labels
when editing for example. This is not possible anymore is it?
On 9 April 2015 at 09:22, zero-24 notifications@github.com wrote:
RTC. Thanks [image: ]
This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/6718
http://issues.joomla.org/tracker/joomla-cms/6718.—
Reply to this email directly or view it on GitHub
#6718 (comment).
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/
We speak here about a multingual site, not a monolingual site where the UI language can be chosen by the user and will be used all over the site, whatever the content when the user logs in.
We also only speak of the site part of that multilingual site.
So , there is no "previously" in multilingual since the origin of the implementation.
So, the PR is not B/C break as chosing a non Content Language as user language has always broken a multilingual site when the user logins, with the error:
( ! ) Notice: Undefined index: ca-ES in ROOT/plugins/system/languagefilter/languagefilter.php on line 361
or a 404 if error set to None
when Automatic Language Change is set to Yes.
Otherwise, the user choice for the default site language has always just been ignored in multilingual Joomla implementation.
Would it be nice to separate a user's language from the content language displayed as a New Feature? Not sure. Someone choosing to display the Italian part of a multilingual site would be expecting the UI to be also in Italian, etc. Also, it could be very complex to implement.
FYI, the redirect error as a Notice happens when there is no Content Language at all for the said language.
If other type of related errors: missing home, unpublished content language, said language set as default, etc. one may get an empty page instead of the Notice, which is as bad.
I am not denying there may be an error. I just dont agree that disabling a
function is the correct solution.
This PR does not disable a function at all: it corrects a bug.
As explained, a multilingual page (as also a monolanguage one) can have only ONE language assigned to in Joomla!.
The language tag is the base for all aspects of multingual and it is right impossible in the present state to have 2 language tags. It always has been the case and I do not see a solution to this.
I do agree with the observation of Thomas and Jean-Marie. I have tested
extensively the behavior and it happens exactly as Thomas describes. I
also tested as posted on Github the positive test results of JM's patch
and that resolves the issue as shown by JM, Thomas and myself as well
during the test. JM's patch resolves the issue so I do not see the issue
not committing this patch (!)
On 4/9/2015 9:45 PM, infograf768 wrote:
I am not denying there may be an error. I just dont agree that disabling a function is the correct solution.
This PR does not disable a function at all: it corrects a bug.
As explained, a multilingual page (as also a monolanguage one) can
have only ONE language assigned to in Joomla!.
The language tag is the base for all aspects of multingual and it is
right impossible in the present state to have 2 language tags. It
always has been the case and I do not see a solution to this.—
Reply to this email directly or view it on GitHub
#6718 (comment).
@infograf768 please check infograf768#16
Merged infograf768#16, thanks Roberto!
Does this means we need to test this again?
On 4/9/2015 11:09 PM, infograf768 wrote:
Merged infograf768#16
infograf768#16, thanks Roberto!—
Reply to this email directly or view it on GitHub
#6718 (comment).
I forgot to check the since tags in doc blocks and all the query joins can be converted to innerjoins because we only want all the items that meet all the requirements:
Status | Ready to Commit | ⇒ | Pending |
Labels |
Removed:
?
|
Status | Pending | ⇒ | Ready to Commit |
RTC again As for milestone i guess we should ask @wilsonge
Labels |
Added:
?
|
Status | Ready to Commit | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-05-25 00:35:58 |
Closed_By | ⇒ | wilsonge |
Labels |
Removed:
?
|
@test: works for me, thanks!