[#5963] - Making it possible to switch languages by fixing JLanguage::setLanguage()
- Closed
- 8 Feb 2015
- Medium
- Build: staging
- # 5963
- Diff
- Hackwar:patch-21
- Success The Travis CI build passed Details
User tests: Successful: Unsuccessful:
Problem
If you want to switch languages, for example because you are a languagefilter plugin and you are defining which language to load via the URL, you are out of luck if you are not the first plugin to be called and if this discovery process is not done in the constructor, because at that point, other plugins might have autoloaded the language and thus forced a language on you. JLanguage however currently is not able to switch between languages. JLanguage::setLanguage() does change the language, but it does not reload previously parsed files and it also does not update the callbacks. So this means that you have mixed-language translation strings, the wrong callbacks registered in the class and the metadata and the language name itself claim to be the new language.
Proposal
By moving most of the code from the constructor to setLanguage(), we can make sure that with setLanguage() the whole object is in a consistent state. This should also be backwards compatible and rather fix bugs in existing code where people simply use JLanguage::setLanguage() and thus have our above described issues.
It should be made clear that this is not perfect. The code assumes that all files are loaded simply by handing over the extension name. If an extension manually loads files from a different location, then this will break for this pageload. However it will still be less buggy than right now.
jissues-bot
- | Labels |
Added:
?
|
||
As far as I can see: Yes. You have to make sure that there is at least one system plugin that autoloads its language before the languagefilter plugin.
@Test No issues without #5140, and with #5140 the issues reported there by me are solved.
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5963.
| Status | Pending | ⇒ | Ready to Commit |
moving to RTC based on testing by @infograf768 and @richard67 Thanks @Hackwar for coding!
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5963.
| Category | ⇒ | Multilanguage |
An issue that must be addressed, with or without these patches applied, is that changing the internal language properties of a JLanguage object which is stored in its internal cache (this object should be since JFactory is calling JLanguage::getInstance which stores to the cache) results in two different language codes. By doing this setLanguage call, a JLangauge object which was instantiated and cached as en-GB can return a language object loaded to de-DE, for example. If we are going to encourage this behavior of JLanguage, the cache MUST be dealt with otherwise we are introducing other issues into the API.
| Status | Ready to Commit | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-02-08 08:47:05 |
Oh, this is necessary that #5140 correctly works.