Wedge

Oh, now I know... I think EmailTemplates was ISO earlier, because it didn't have any accents in it. I added accents when I translated your 'desc' strings...

- Although I'm not enchanted with the idea (when it comes to updating website files via FTP, it's two or three extra folders to check out), I guess it'd make sense to put all languages into their own folders, for simplicity. If you don't want that, then good; if you do, then I won't oppose it.

Well, there are many settings we never hesitated to remove to make room for others or just breathing space... ^^

Speaking of which. Isn't it feasible (ah, finally got the spelling right!) to just keep the editor out of topic pages, and when clicking 'Full editor', load it through Ajax instead...? I'm not afraid of these Ajax calls anymore. :P And it would save quite many bytes to topic page.

- there's an occurrence in Active Topics (from John) and one in one of your plugins (I think it's WedgeDesk, I'm not sure though), where it sends reqWin('url string'). I've fixed Active Topics to do it the 'proper' way, i.e. put the URL into the href (so that it actually gets prettified and optimized by Wedge... I think??!!), and do reqWin(this) instead.

I still prefer for // comments at the end of a line of code to be either very short (a few words at most), or moved to their own line (or move, if needed). That's pretty much a 'SMF/Wedge coding guideline' to me... Do you think you could do that in the future..?

The only real issue with doing it vs not doing it is that we already have about 40 files per language, multiplied by the number of languages installed by Shitastico and friends when translations are available (remember, SMF has around 70 language packs) and that can start to cause other issues.

Yes, if you want to load the JS files and code dynamically, followed by all the requisite event handling. It's doable but it's really not pretty.

WedgeDesk has a bunch of reqWin(this), reqWin(this.href) and a couple of weird reqWin instances.

I have a vague memory of those being related to showing attachments in a popup window, but Zoomedia would be infinitely better in this case.

I'll try :)

The 'correct' behaviour is for loadLanguage to complain bitterly if a given language file doesn't exist - even if there will be a suitable fallback, it is still going to complain about the missing file. The only problem is that a small percentage of the language files for English UK will be identical to English US (e.g. so far the Home language file is in that category), so I need to include a placeholder for those so that I don't write exceptions directly into loadLanguage for a fringe language case. I don't like it either but it's the least worst alternative.

did you check whether $context was being used elsewhere in the functions..?

Considering I'm the only one who'd be annoyed by the change (i.e. having to move my FTP updates to one extra folder), it's probably best to just ignore me and move them to their own folders.

How pretty it is depends on what you're ready to give up on, eh eh.
Personally, I'd say that the less Display is crowded, the prettier it is overall.
As always, my main concern is with reactivity. But as long as the main editor is there, and Ajax is called only when going for 'full editor', I don't really see any issues with it.

i.e., loading smileys and buttons through Ajax seems like a given to me, but the wysiwyg and non-wysiwyg editors, along with their shortcuts etc, should always be loaded.

I was wondering whether we shouldn't be inverting the process on desktop..?

reqWin(this.href) is wrong code. Perhaps inherited from an old version of Wedge..? Can't remember how I used to do it. (I fixed it manually. I have tons of compatibility-related updates I'll commit at some point for plugins... 29 files, half of which are from WedgeDesk.)

Probably, yeah...
I'd still like for you to look into your code for WD and tell me if you can think of a better way of doing it. The onclick stuff, I mean.

I can understand you don't like the idea... And, I'll just say, I agree I'd rather not do it that way.

I'm thinking, *maybe* we could have a 'special setting', such as $txt['language_parent'] = 'english' or something, that says Wedge shouldn't worry about missing files, and instead look for the file inside the 'english' folder. What do you think..?

* Because the registration agreement is a special language string that's explicitly parse_bbc'd

This also makes them easier to use them as base for your own registration agreement.

Missing file. Note that Home files are not supposed to be in the final distro, and that I'm sure I'll forget all about it soon enough, but whatever...

No, I didn't. But any place with a linktree is also going to be setting the title, which is a context variable.

I'm not overly looking forward to the changes in the language editor, or for that matter, themes[1] with their own language files.

1.	Assuming we still have *themes* as things that can replace entire template files

Ah... that's where you and I differ. WYSIWYG pretty much demands the buttons from a usability perspective and realistically the buttons are more important to me than the shortcuts are.

Quote

I was wondering whether we shouldn't be inverting the process on desktop..?

I don't know. I just know I hate crazy and inconsistent interfaces - you know my thoughts about Enter vs Ctrl Enter on Facebook for example ;)

Actually, it's probably from SMF originally.

I don't remember much of WD, mostly it was brute-force conversion of SD original to whatever was current in Wedge at the time.

The problem with a language indicating its parent like that means you implicitly have to load the file twice - load index once, learn that you need to have a parent, load the parent, reload the index to reinstate changes from that. Though once you've done that, you can avoid it further.

Quote

* Because the registration agreement is a special language string that's explicitly parse_bbc'd

Which means now what's in the database is explicitly different to what's used for actual users, but heigh ho and all that. Reason: preparsecode will convert out all the line breaks.

Quote

This also makes them easier to use them as base for your own registration agreement.

Please tell me why a user would do this. Translators are the only people who should be looking at raw language files.

Quote

Missing file. Note that Home files are not supposed to be in the final distro, and that I'm sure I'll forget all about it soon enough, but whatever...

So users who get the final distro are going to be expected to hand code stuff? Might as well write off Wedge now then because most users do NOT want to hand code ANYTHING. If anything, not only does it need to stay but it needs an admin UI as well.

At some point you renamed 'simple' and 'classic' to 'name', at other points to 'group'. I suspect the one above should say 'group' instead of 'name', but I'm not sure

True enough. Although not always done... (e.g. notification action.)

(It is so tempting for me to remove themes as a feature entirely, because skins can do so much more... The only thing they have for themselves, is the ability to replace a template file. But it should be possible to simply put these files into our skin files... Why not?! I'm so familiar with my skin code, and so unsure about theme code... Heck, I've never tried to install an additional theme in Wedge. Everything can be done with skins so...)

So, I take it it's untested, right..?

I don't know, Pete.
All I know is that SMF has this:

And you have a similar one, except you're using $txt instead of file_get_contents.
The rest is the same, i.e. you parse_bbc it. If you didn't want it to be parsable, you should remove the parse_bbc call and revert the $txt strings to use HTML instead

Well, exactly... I was talking about translators, in this case.
In which case, having a long line of text will be annoying to translate for them, unless they enable wrap mode, but not everybody thinks of that. (Heck, I pretty much never enable wrap mode, except when I have to read a TXT file that was built that way...)

What do you mean, Pete? They get the Welcome template by default. Which is geared towards a 'starting' forum. Heck, I can't bother to write the UI for the default homepage target, allowing for users to choose whether they want to target a specific page, or action, or board list, or specific board (or even topic, why not...)

First thing for that is to allow for the homepage (most often modified page) to be overridden and redirected to another page of yours.

:edit: One deals with the permission groups, one deals with the individual permissions and the group it is supposed to go into. They should not both be the same. I will fix it in my next rev.

Fairly sure I gave the notification action a title some days ago.

Can a skin replace part of index.template.php?

And I see no reason off hand why this should even work. preparsecode has always converted line breaks out - always.

I'm not being funny but did you even look at the UI in the admin panel for this?

The reason my file had no line breaks and br tags in it is because I ran it through preparsecode. That's what preparsecode does, amongst other things: strips the line breaks and converts them to br tags. I then specifically call un_preparsecode on it when I prepare it for the rich text editor so that people can use full formatting it without having to get their hands dirty like they had to in the old days - hell, most people didn't even know the agreement supported bbc parsing.

So I checked parse_bbc and lo, there is a linebreak to br conversion, yet I cannot think of a single time outside of this one area where this ever EVER comes into play.

Agreements... they're the odd ball. I deliberately tried to harmonise it - working under the assumption that it had to be that way as it was my understanding that parse_bbc didn't do linebreaks.

And, as ever, I wasn't intending them to have to edit it as such. The grand plan involves having language editing tools for translators on this site.

The idea of having a template like this is a noble one, but it's also sadly naive of our userbase - it's giving them infinitely more credit than most of them would actually be due.

This is why I've been talking about content management and adding a CMS into the mix for the simple reason that most admins can only manage something if given a nice UI to play with, it's why so many of them jump to Simple Portal and co, so that they can have nice front pages and so on.

So instead of giving them the barest bones tools for the job, we need to give them more powerful tools.

So may I leave everything to you on this..? It was quite a large patch, so I know it's not going to be fun...

Nope. It's the mission of Custom.template.php, where you can declare template_whatever_override() to replace a function.
We discussed it at length back in the day. Having template files inside skin folders is very doable, but it's not 'clean'. I'm always torn between the two sides of the problem, eh...

I didn't. I just noticed that adding line breaks manually in the string would add more physical line breaks to the thing. So I checked the code, and noticed the parse_bbc call. Which is why I decided to go for a 100% BBCode version. (Not that there's ANY BBCode in these strings, but... I mean the line breaks...)

Yeah but that's no reason to throw a hadōken at me in your previous post, buddy...

Considering the amount of work we still have to finish, I don't see this happen in a realistic time frame. I'd rather we focus on more urgent matters -- translators can work on existing language files, if they're in such a hurry to have it done ;)

now that your Wedge copy is installed, download this separate file, Home.php and its related files, copy them to their respective folders, and point the homepage to Home, so you can have the Wedge.org homepage code on your site. Now you can modify it all you want (if you want!), because a Wedge upgrade will never overwrite it.

And working on these tools will deprive Wedge of other features that could be added to it, and that could be used by more people...