Wedge

I have a working version of this stuff. At least, I have a cut down working version of this stuff.

I have it able to load from cache, rebuild cache and query the DB in the process, so all the mainline language files are built appropriately. I have merely commented the old code out for now.

There's not exactly caveats to this, but what I have got thus far works by recording the theme id (not skins, since skins don't have their own language files), plus language and whatnot. It shouldn't matter whether a theme is pulling from different places or not, all that matters is that for a given theme (whether it has its own language files or not), a given thing is going to get loaded, and whatever the result of that, that's what's going to be extended by the DB check and then saved.

This does mean that, currently, it *is* stored per theme. Whether that will change, I don't know. I can always assign 0 to force it for all themes and juggle the code. I don't know yet, I just implemented the base functionality and I'm not entirely sure where this is going yet.

It's not battle tested, but it seems to work (including respecting the DB content). It also does not yet do plugins, but they're going to be special anyway haha.

I don't know also how this will affect JS caching, or whether editing a file means just flushing all the JS cached files of the same language, that would be the easiest, if not the cleanest.

Also... how come we never had agreement_french.txt anywhere in SVN that I can find? SMF supported multiple languages for the agreement for ages, not that most people really understood that it worked :/

Anyway, making a note that I'm moving it to a proper language file now, and given its name I'm giving it its own language file. But unlike the original, I'm going to be running the preparser on it. It gets shoved through parse_bbc anyway but I want to store in the language files as a directly parseable string for bbc purposes. (And I'll be excluding it from the main language editor for fairly obvious reasons; there's a dedicated UI for it, and as such I want to reuse that rather than anything else, plus there I can set up the bbc editing for it since so many people do not realise that it actually gets bbc parsed.)

Also, the table's PK should be PRIMARY KEY (id_theme, id_lang, lang_file, lang_var, lang_key) not what's currently in SVN. I'll commit when I submit everything else related to changing the registration form code.

I don't mind which we have, but I believe we need at least one of these in the core distribution.

No, I was being flippant. It's a joke from H2G2 about a ship fitted with a device that makes something infinitely improbably and the 'quasi reciprocal nature of the universe' means that something that is supposed to be infinitely improbable is bound to happen almost immediately.I'm not sure where it would be useful, though. I'm fairly sure that anyone using such buttons would just drop the relevant ul in the first place.

It's funny you should say that :whistle:

You're also not the only person to have commented upon it.

And you just know that the 1 in 100 chance will come back to bite. Still there's always the clear-file-cache ;)Where would we want to use buttons, exactly? There aren't many places I can think of where this would actually be an issue.And unless the word Android is used elsewhere on the page, it's not going to compress particularly well anyway ;)

You mean just like I suggested in the first post?

So. Anyway.

Reply to new topic (leaving a post behind the old topic, maybe)... or even quote to new topic. Thoughts?

This has multiple consequences, depending on your perspective.

So, I created a dropdown with both raw HTML and bbcode in it, as I couldn't remember whether it allowed either or neither or what. bbcode is unparsed, understandably.

Now, raw HTML is not supported as such. I'm willing to take it that this is a security measure, because the way it is implemented, the value is stored as-is in the DB and displayed without further processing later on. So it would be a security issue to just accept and handle raw HTML there, and naturally it is htmlspecialchars'ified before use.

This leads us to the interesting situation where inside the dropdown, the htmlspecialchars'ified text will be rendered as HTML inside the selectbox.

Which means there's one bug, in that the content isn't twice-parsed.


There is a separate side bug related to the selectbox. I have a piece of text with an image that's substantially bigger than a single line of text. It was the first image at hand, and was 40x40. When the selectbox is expanded, it is displayed normally. But when closed and it is the selected item, something else happens entirely. See attached. The picture shows both the expanded behaviour and the unexpanded behaviour (i.e. it doesn't change height, and the text is base-line aligned, so the text is actually out of sight)

I'm not sure what *should* be the ideal behaviour here, though.