Wedge

The real standard and expectation is that you try it out and give us feedback. Even if it's just things you like/don't like/wished it had, it lets us know you're trying it out. Especially if you've come from SMF, there are a *lot* of changes to see and get a feel for.

There's also a lot of things that are rough around the edges right now and I've forgotten half of them ;)

Currently it is a 2.0 only importer - note that it is an importer, not a converter as such.

You install Wedge, fire up the importer and point it at your old DB. Hasn't been tested lately, may be broken, may need some refinements, not sure yet.

OK, another update. Probably the last for the evening because I'm at the stage where I'm not entirely sure what to do with it, so throwing it open a bit.

First up, the more finalised list of templates. Aside from the fact everything is now linked to where it should be, the things of note are that I moved Modlog from main to admin panel and gave it a better description, plus I created a block for 'configurable language crap that isn't in this area', namely the email templates and the agreements. I have no qualms about them being outside the language editor, they are where they are for a very good and specific reason, namely that they have a bunch of other specific behaviours that are attached to them that have no place being here.[1]

Then we have the actual editing page itself. You may remember SMF's was a two-pane affair. I didn't like it, still don't like it, and I've started on a half-assed replacement but I'm really not that fond of THAT either. It's just marginally better to me than what we had before. Second screenshot shows the main index, part way down - mostly so it shows the one actual entry I have that does have both a master value and a replaced value (namely 'admin', which is the main $txt['admin'] menu item)

I'm open to any suggestions of what to do with it because I got nothing right now!

1.	Email templates has all the stuff related to variable injections, agreements do not currently but will have the whole 'force reagreement' facility. Either way it's a ton of stuff that is unique to those areas and would get in the way of the rest of the stuff.

I know there were issues a bit back with using compression and it interfering with Xcache and Xdebug, not sure if they're still issues or not, I haven't tried using the profiler lately.

But this is very unusual, hence the topic. I can only assume a parser bug, but I've seen moved on past it, heh.

Actually, that's a very good question. More importantly from my perspective, though, is the desire not to have it do extra queries that it doesn't need to do - it assumes (reasonably rightly) that it's going to be run once per page, not multiple times, so I don't see why it would bother staticifying or globalising anything it gets in terms of query results, but it'd need to do that to avoid it making queries it shouldn't here.Some things that are very minor are not so minor when they grate on you over time.It is an unusual policy, yes. If it's just the odd function, sure, rename it. But I'd be wary of lots of renaming because then I'll forget what we did ;)

The only thing about using underscores, aside from the extra typing (I'd rather camelCase than underscore personally), is that sometimes odd things happen in terms of where the underscore is. ob_sessrewrite never looks right when I type it. I always think of it as obsess_rewrite. Freud has much to answer for. :^^;:

The other thing is that functions are case insensitive in PHP (or should be), meaning that if it's all camelCased, getting case wrong doesn't matter as much as misplacing _ does.

So I'm working on the language editor, and moved its templates into its own handy dandy file, ManageLanguages.template.php. And as such I'm removing the old code I don't want.

But if I remove this one div from it, see before/after shots, so you can see what was removed - just removing that div on line 319 will not generate a 500, it will simply force PHP to abort entirely with just this in the Apache error log:

I have no idea WTF is going on.

Yup. It is something we need to do, because outgoing emails don't get the translation. This gets incredibly hairy when you realise that in some cases multiple calls are going to be needed, depending on the way email is handled. I'm thinking of the cases where you load one template per language that you're sending out. Fortunately it should be doable within loadEmailTemplate rather than every instance of sendmail manually.

It seems perfectly logical to me, it is yet another 'simple machine' ;) I couldn't decide whether I preferred 'Pulley' or 'Lever' for the translation tool on this site. Now THAT's a silly name :lol: