Closed (fixed)
Project:
Project Issue File Review
Version:
6.x-1.x-dev
Component:
Code
Priority:
Major
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
25 Nov 2011 at 06:10 UTC
Updated:
17 Feb 2012 at 08:20 UTC
Jump to comment: Most recent file
Comments
Comment #1
gábor hojtsyThe change is going to land in #1260716: Improve language onboarding user experience hopefully soon.
Comment #2
rfayI see it just landed.
Hmm. I guess I have a couple of questions:
* Isn't it a simpletest change we're talking about?
* Why aren't there tests for this added with the patch?
* How does the patch pass testbot testing right now?
* How did it get committed without this being solved first?
Comment #3
gábor hojtsyDamien Tournoud and @webchick suggested we put in a little 3-line compatibility layer in the patch to keep it work with the locale argument until we fix the testing system and the testbot rollouts of it. They suggested we get the patch land like this and make the testbots align later. This is documented on the original issue via an IRC log.
I'm not intricately familiar with the testing system, so I don't know if the installation of the system is entirely in the realm of simpletest, in which case, we could have fixed it in the same commit I guess, or if it is a d.o issue. Damien and Angie seemed to believe d.o changes are required.
I think the only remaining question is why we have no new tests with the patch, one you also asked on the issue and I've replied there. So where should we move this issue?
Comment #4
rfayOK, I think I have it now.
The issue is that is an install-time issue. Simpletest is *not* used for the install, it's used for the test. A bit of a copy of simpletest is used for the install, if I remember right.
I am still confused about how this would be controlled. We don't currently have the capability to install in other languages, I don't think.
And there are a bazillion tests that probably won't work if a system is installed in another language, due to the silly use of t() in comparisons.
The change will be required in PIFR, so moving it there. Maybe @boombatower or @jthorson will do better at understanding this.
Comment #5
gábor hojtsyNo, all is changed in D8 is that the language is taken from 'langcode' in GET not 'locale'. The committed patch has these 5 lines so it still passes tests:
Until we fix the testing system on d.o, Drupal 8 needs to carry these five lines. Obviously we don't want Drupal 8 to be released with these 5 lines. The discussion of this 5 line compatibility layer is in the IRC thread pasted at http://drupal.org/node/1260716#comment-5226480.
If we just remove the compatibility layer, PIFT respondes with this: http://qa.drupal.org/pifr/test/191604 Quoting:
Obviously the test system wants to avoid looking at the profile selector or language selector form. Since the GET argument name changed in D8, we need to change the testing system to pass langcode=en instead of locale=en, that is it. Depending on how you handle compatibility with testing for D6, D7 and D8, you might want to do 'locale=en&langcode=en' instead, the extra langcode should not bother D6/D7, the extra locale should not bother D8.
I hope this helps clean it up :)
Comment #6
gábor hojtsyHow can I help move this forward?
Comment #7
jthorson commentedGabor,
If I am understanding your explanation, the only change from D7 to D8 is that the install path argument changes:
From:
/install.php?profile=standard&locale=enTo:
/install.php?profile=standard&langcode=enHave I got this correct?
If so, the attached patch should do the trick.
Comment #8
jthorson commentedAnd if I'm correct, this should be the core patch needed to test it.
Comment #9
jthorson commentedPatch in #7 missed a 'locale' reference.
Comment #10
jthorson commentedDuh. Wrong patch.
Comment #11
jthorson commentedRan a test with the above patches (pifr patch and remove compatibility patch) which resulted in two failures: BareUpgradePathTestCase and FilledUpgradePathTestCase.
Any chance that these test cases are still using locale?
Otherwise, the above looks good.
Comment #12
gábor hojtsyThe upgrade tests run with an imported DB copy, so no, they do not run install.php. I've checked quickly and could not find a reference to locale in those tests.
Comment #13
jthorson commentedOkay ... this ran clean on scratchtestbot ... not sure what's wrong with my local environment, but since there's no obvious tie between the failed tests and the patch, and it works on our qa environment, I'll commit this and re-confirm it's all working before rolling our 6.x-2.8 release.
Comment #14
jthorson commentedCommitted to 6.x-2.x (f3a0e6c).
Will be deployed when we roll a PIFR 6.x-2.8 release.
Comment #15
jthorson commentedPIFR 6.x-2.8-rc1 deployed to testbots ... we can test removal of the compatibility layer now.
Comment #16
gábor hojtsyAll right #1426954: Remove locale backward compatibility layer in installer submitted for the testbot! Thanks for rolling this out!