Problem/Motivation
Found while working on #2226533: Changes to the Language class due to the LanguageInterface (followup)
Making the id property protected, so... need to not change it in a language like this.
Proposed resolution
Make a new language and use constructor to set the id, or
Maybe we just dont use this change it was thinking it needed to make.
Remaining tasks
see what happens with initial patch
get feedback
User interface changes
No
API changes
No
Comment | File | Size | Author |
---|---|---|---|
#7 | 2333907.7.patch | 4.11 KB | alexpott |
#4 | 2333907.2.patch | 1.53 KB | YesCT |
#2 | 2332739.2.patch | 4.84 KB | YesCT |
Comments
Comment #1
YesCT CreditAttribution: YesCT commentedpatch to explain my idea.
Comment #2
YesCT CreditAttribution: YesCT commenteduh. and the patch.
Comment #4
YesCT CreditAttribution: YesCT commentedcrap. right patch.
Comment #5
YesCT CreditAttribution: YesCT commentedComment #7
alexpottWe can completely remove the user part of the test - it's not really doing much apart from making things complicated - language negotiation, the ability of user's to set timezones and preferred languages are all tested elsewhere.
Comment #8
YesCT CreditAttribution: YesCT commentedbut I wonder if this is testing to see if things are showing in the user preferred language.
Where is "elsewhere"?
I'll look again.
Comment #9
Gábor HojtsyThis test definitely does not test setting a user preferred language, because even though it sets the user to prefer a language, it does not set the negotiation to include that condition, so it needs to manually fiddle with the interface language to be equal to the user preference, which is the point of this issue... So I agree it just makes the test too complex. UserTimeZoneTest looks like a good test for user timezones that does what this part of this test did. So looks good to me.
Comment #10
YesCT CreditAttribution: YesCT commentedok. :)
Comment #11
catchCommitted/pushed to 8.0,x, thanks!
Comment #13
Gábor HojtsyYay, thanks.