Wedge
Public area => Bug reports => The Pub => Archived fixes => Topic started by: Nao on June 11th, 2012, 12:52 PM
-
Here's the list of language files that admin search will work its magic on:
'Help', 'ManageMail', 'ManageSettings', 'ManageBoards', 'ManagePaid', 'ManagePermissions', 'Search',
'Login', 'ManageSmileys', 'ManageMaintenance',
As you can see, it doesn't have Profile in it...
However, if I do a search on 'minposts' (signature_minposts), it returns to me the string from the Profile page, instead of the one from the Admin page. The profile page one is multilingual-ready, so it would return an error but I fixed that one in my local install (I'll commit it later, it's actually pretty big compared to the relevance of that bug...)
But I don't see Profile in that list. So I enabled debugging locally, and looked at the language list... Wow, what a load of fun.
Fichiers de langue (42) : index.english (default), index.french (default), Admin.english (default), Admin.french (default), Help.english (default), ManageMail.english (default), ManageSettings.english (default), ManageBoards.english (default), ManagePaid.english (default), ManagePermissions.english (default), Search.english (default), Login.english (default), ManageSmileys.english (default), ManageMaintenance.english (default), Help.french (default), ManageMail.french (default), ManageSettings.french (default), ManageBoards.french (default), ManagePaid.french (default), ManagePermissions.french (default), Search.french (default), Login.french (default), ManageSmileys.french (default), ManageMaintenance.french (default), Help.english (default), Help.french (default), ManageSettings.english (default), ManageSettings.french (default), Help.english (default), Help.french (default), ManageSettings.english (default), ManageSettings.french (default), ManageSettings.english (default), ManageSettings.french (default), ManageSettings.english (default), ManageSettings.french (default), ManageSettings.english (default), ManageSettings.french (default), ManageSettings.english (default), ManageSettings.french (default), Profile.english (default), Profile.french (default).
There are two issues in this:
- The Profile language is loaded at the very end. I don't see where it's coming from...?! This call needs to be removed.
- The other files are loaded multiple times. It's likely that they're stopped at the gates before they're loaded one time too many (?), but it seems to happen on a lot of pages... For instance on a topic page with media items, it'll load Media.english, Media.french, Media.english and Media.french in sequence. Here, it's done in that order: (Whole lot).english, then (Whole lot).french, then (Help.english, Help.french...) * count(Whole lot). (Or Whole lot.length, depending on your language of choice.)
The latter is definitely a 'bug' to me, as the language files are only listed if they're actually included. Because it's an array we're sending, the first two Whole lot loops are as expected. It's the last one that doesn't make sense. And the Profile calls. Any ideas...?
-
The later strings are loaded through an obscure loop in the admin search that actually executes every single function it finds in the admin... Not exactly very smart I'd say?!
There are certainly more ways to do that properly...?!
Anyway, I think I'm "simply" going to force a reload of the original language files after that... Meh!!
-
Well... the admin search has to execute every function, that's how it gets the list of settings to work with, and all the main language files should be loaded first. It's loading both sets of languages because loadLanguage has done that for a while but there's no need for it to go through all that twice.
-
So, how do you manage the case where a matching setting is found, but another language file already overwrote it from the text strings..?
Search for "visible" and it'll match signature_minposts but you'll get some contents that doesn't have "visible" in it... :-/
-
Because what it matches on is what it's supposed to use >_>
I never said it was perfectly written. If it's being overwritten that suggests that the other string should be changed so that it has a different language string - and that we shouldn't be reloading lots more strings.
-
Because what it matches on is what it's supposed to use >_>
I never said it was perfectly written.
If it's being overwritten that suggests that the other string should be changed so that it has a different language string - and that we shouldn't be reloading lots more strings.
Regarding that, yesterday I posted a topic with a list of all intersecting entries in the language files. Feel free to have a look and hack away at the language files... :)
-
My contributions to the admin search are primarily configuration related, I fixed a bug about it being case sensitive and I've added changes to differentiate types of settings available but that's about it.
-
So, aside from the internal mess of the admin search (and, sadly, I don't see a better way to deal with it!), is there anything about it that doesn't work as expected?
From my perspective, there's a few minor areas that could be cleaned up and made sure to be added to it - but I'm thinking that's almost into overkill territory at this point. (E.g. we could make all the possible custom field templates into searchable items.)
-
I guess there aren't too many places where it breaks. Maybe we could just take the one I mentioned, and rename the option... Would be simpler.
-
Yeah, that makes sense.
-
What to, then? :P
-
Take the one you mentioned and rename one or the other of the strings so that there isn't a clash.
-
Should be good now...
-
The mass extra loading should be fixed in r1736.