Wedge

Well, that too would work, but then you're getting into the realms of having some button strips that act just as button strips, and some button strips that act as non clickable buttons with dropdowns. Whatever you do, you still end up creating something that does not behave like anything else in its style. Either we give it a unique look (and make it very clear that there are drop items), or we make them more like other menus and make them clickable.

I can fully understand that, but on the flip side, it does work exactly how you suggest.

The only downside to checking for any URL-like structure is that you can risk changing things that shouldn't be changed, e.g. the URL that controls the page index injection for ... expansion (which is a known bug in SMF implementations)

There's no best solution at all, only a variety of least worst solutions that all have their up-sides and down-sides to them.

But surely you can't do it only once? If you load French, you load French after you load English... so you need to rebuild it when French is loaded - surely you need to do it just when $template_name === 'index' so that you always rebuild it properly when changing languages?

(That does raise questions for switching languages e.g. for emails but IIRC index isn't used then anyway)

But I do worry about it :P But really worrying about it at this stage is not a huge deal, we can always fix it up later if we have better ideas :) (Beta is when we really need to worry about performance)

But that's still a filesort per time it's viewed - and it is an I/O hit that's not very nice. I don't think it's a performance killer but we should be mindful of it. What it might be worth doing is figuring out whether it's worth doing in PHP rather than MySQL.

Yes there are, actually. India, for one.

But it's still kind of moot. There absolutely MUST be a timezone set. You can't even call time(), without having a timezone being set because PHP will complain bitterly. Same with strftime, date etc. And given that we already have to do that, it's no biggie to get the user's timezone that they've set, which allows us to calculate the offset relative to server time, including DST, and get it right. IIRC I implemented it so it calculated the time_format and overrode what the user had otherwise set to preserve codepaths.The time format should now be obsolete, and only timezone should be set. There's no clean way to determine a user's timezone by anything supplied by the user, far better that instead ask the user what their timezone is on registration. (This is not yet implemented but I'll add that in due course)It does have to be in the language loader, but you have choices in how it's done.

What you can do, if you want, is implement it as an array, such as:

Or, as previously discussed creating a set of prefixes. But this seems cleaner to me - and you can have it expanded automatically into a normal set of day_suffix_1, day_suffix_2 etc in loadLanguage, when the loaded language file is 'index', and have it automatically unset all of them and build them out of just this array.

Is Bebas being shipped in Wedge's files? If so, we can certainly use it for this. Would be more apt, really, given everything else.