Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Arantor
5941
Off-topic / Re: Existing framework vs creating my own?
« on October 11th, 2011, 11:04 PM »
It really depends what you need the framework for. For really basic stuff (a couple of forms, minimal MVC, little/no DB scaffolding), don't bother, just roll what you need of your own.

Alternatively, big project... definitely a framework. Depending on what I need, I tend to have two positions. If it's mostly my own code but with certain biggish components, I'll look at Zend Framework. It provides lots of useful components but you're not required to use any of them - it gives you individual components for different uses. Be warned, it's pretty heavy if you use a lot of components, but it does make life easier for individual components.

If you want something more integrated as an MVC framework without the hassle, I tend to go to Yii. It's lightweight and isn't that hard to extend and work with. I've also used CodeIgniter but I found Yii easier to work with myself.

I don't know what you're aiming to get from a framework and how much you're expecting it to do on your behalf.
5942
The Pub / Re: English British support
« on October 11th, 2011, 10:58 PM »
I'd have to go through and fix a number of strings in the core, and if I did that I'd want to use colour bbc instead of color and so on :/

There is another thing I'd do with this overhaul, actually. There's something that's annoyed me for a long time: the way languages are displayed to users for choosing.

If you have a list of languages, and you list them as English, French, Spanish... you're Anglicising it. It should be the proper language, e.g. English, Francais, Espanol. (Accents included, I just couldn't be bothered typing them)

Now, the reason it's done how it is right now is simply ease of programming and performance: it's easy enough to look up index.*.php files and split the * on _ and upper-case the first letters. That's how you end up with Spanish (or worse, Spanish Es, a construction that's somewhere between meaningless, irritating and unintuitive)

Instead, if you build and store a list, you can actually load the files themselves to get the right string, so you can actually have the files themselves contain a proper language-dependent string holding the proper form of that language's name in that language... can't say more logical than that IMO.

(It would replace the current getLanguages() process, and would cache the value inside $modSettings. I have no problem with only setting it from the admin panel and have the admin panel be the one to set it, so it's only set if the user asks to recache it, or when you add a new language.)
5943
The Pub / Rearranging the languages/ folder
« on October 11th, 2011, 06:15 PM »
Been thinking about this, don't expect most people will notice the difference, but I think it'll be quite important in the long run. It certainly simplifies a few things, and causes others.

Right now, there's Themes/default/languages/index.*.php where you have one file for each language, e.g. index.english.php. That's cool and all, but I want to move them.

Specifically I want to convert it to Themes/default/languages/*/index.php so that instead of the language being part of the filename, it's part of the folder.

On the one hand, it will provide a performance boost to installations with lots of languages by segmenting the files into folders rather than one big folder.[1] It does also simplify adding new languages from a folder permissions/upload/unpacking scenario.[2]

On the other, it means that whereas before with the list of languages being shown to users based on their filename, it makes it based on language and that's slightly more prone to being wrong.

<discuss />
 1. Mind you, there's 34 PHP files and 1 image per language. Less if it's based on English and makes use of English as a fallback.
 2. That said, I've thought about not having an interface in the ACP for uploading a new language and expecting users to upload it manually. That, or ship Wedge with all known/available languages and just be done with it. Certainly, if it's in a folder it should be easier to upload manually.
5944
Features / Re: New revs
« on October 11th, 2011, 05:08 PM »
(44KB, 49 files)

Revision: 1098
Author: arantor
Date: 16:08:17, 11 October 2011
Message:
! More language clean-ups, mostly to purge variables from language files. It's not finished but I have things to do out here in RL, NB this has not been tested either :( (Sources: Feed, ManageAttachments, ManageMemberOptions, ManageNews, ManagePaid, ManageSettings, media/Aeva-Foxy, Profile-Actions, Reminder, ScheduledTasks, Subs-Post, Subs-Template, Who, Templates: Boards, Display, index, ManageNews, MessageIndex, ModerationCenter, PersonalMessage, Profile, Language files: Admin, Errors, index, ManageMembers, ManagePaid, ManageSettings, Media, ModerationCenter, Modlog, PersonalMessage, Post, Profile, Stats, Who)
----
Modified : /trunk/Sources/Feed.php
Modified : /trunk/Sources/ManageAttachments.php
Modified : /trunk/Sources/ManageMemberOptions.php
Modified : /trunk/Sources/ManageNews.php
Modified : /trunk/Sources/ManagePaid.php
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Sources/Profile-Actions.php
Modified : /trunk/Sources/Reminder.php
Modified : /trunk/Sources/ScheduledTasks.php
Modified : /trunk/Sources/Subs-Post.php
Modified : /trunk/Sources/Subs-Template.php
Modified : /trunk/Sources/Who.php
Modified : /trunk/Sources/media/Aeva-Foxy.php
Modified : /trunk/Themes/default/Boards.template.php
Modified : /trunk/Themes/default/Display.template.php
Modified : /trunk/Themes/default/ManageNews.template.php
Modified : /trunk/Themes/default/MessageIndex.template.php
Modified : /trunk/Themes/default/ModerationCenter.template.php
Modified : /trunk/Themes/default/PersonalMessage.template.php
Modified : /trunk/Themes/default/Profile.template.php
Modified : /trunk/Themes/default/index.template.php
Modified : /trunk/Themes/default/languages/Admin.english.php
Modified : /trunk/Themes/default/languages/Admin.french.php
Modified : /trunk/Themes/default/languages/Errors.english.php
Modified : /trunk/Themes/default/languages/Errors.french.php
Modified : /trunk/Themes/default/languages/ManageMembers.english.php
Modified : /trunk/Themes/default/languages/ManageMembers.french.php
Modified : /trunk/Themes/default/languages/ManagePaid.english.php
Modified : /trunk/Themes/default/languages/ManagePaid.french.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php
Modified : /trunk/Themes/default/languages/ManageSettings.french.php
Modified : /trunk/Themes/default/languages/Media.english.php
Modified : /trunk/Themes/default/languages/Media.french.php
Modified : /trunk/Themes/default/languages/ModerationCenter.english.php
Modified : /trunk/Themes/default/languages/ModerationCenter.french.php
Modified : /trunk/Themes/default/languages/Modlog.english.php
Modified : /trunk/Themes/default/languages/Modlog.french.php
Modified : /trunk/Themes/default/languages/PersonalMessage.english.php
Modified : /trunk/Themes/default/languages/PersonalMessage.french.php
Modified : /trunk/Themes/default/languages/Post.english.php
Modified : /trunk/Themes/default/languages/Post.french.php
Modified : /trunk/Themes/default/languages/Profile.english.php
Modified : /trunk/Themes/default/languages/Profile.french.php
Modified : /trunk/Themes/default/languages/Stats.english.php
Modified : /trunk/Themes/default/languages/Stats.french.php
Modified : /trunk/Themes/default/languages/Who.english.php
Modified : /trunk/Themes/default/languages/Who.french.php
Modified : /trunk/Themes/default/languages/index.english.php
Modified : /trunk/Themes/default/languages/index.french.php
5945
The Pub / Re: English British support
« on October 11th, 2011, 04:30 PM »
Oh, adding a pirate language pack is something I started to do back in the RC3 days. I just didn't finish it because I was frustrated at the things I'm fixing now.

That, and there was a small problem with dealing with locales, but that's not a problem I have to worry about these days (knowing much more than I did about setlocale 18 months ago)
5946
The Pub / Re: English British support
« on October 11th, 2011, 04:24 PM »
Quote from ~DS~ on October 11th, 2011, 04:20 PM
That's amazing.
That's amasing?
Nope, just amazing.
Quote
Color.
Colour?
Colour is the correct spelling, of course :P As is centre, serialise, initialise, humour, flavour etc.
Posted: October 11th, 2011, 04:21 PM

Also, I'm sure I mentioned I'd like to do a pirate language pack, which would similarly be based on English :whistle:
5947
The Pub / Re: English British support
« on October 11th, 2011, 04:01 PM »
Quote
I'd tend to say it's more amusing/exciting to only keep the relevant entries.
That's exactly it. English/British is the most insane language pack to exist because 98% of it is the same as the main English set.
Quote
The load fallback is here to stay, if you ask me.
I can't see it disappearing either, in which case we might as well remove the internal disable option for it.
Quote
add a version number to every single language file
That's not a bad idea. A little bit tricky to get right, but certainly doable.
Quote
store language files in a serialized array in the database.
The variable nature before made it practically impossible to get this one right, and the old language cache was incredibly unreliable, mostly because of Modifications.*.php and the fact that files weren't re-pulled through the cache after modification, so if a mod edited a language file, it never recached it until it naturally fell out the cache.

The real question is whether the benefit outweighs the hassle. I'm not sure what benefit it does actually have to do it for all strings, especially with the way different files reuse strings the way they do.

That said, what we *can* do is put edited strings in the DB, so instead of users having to make files editable through permissions, they just get to put it into the DB.
5948
Development blog / Re: Plugging in the Plugin Manager
« on October 11th, 2011, 03:48 PM »
What's the difference?

If you're defining a list of classifications, it doesn't matter what you call them, you'd still be enforcing the content fits those classifications.
5949
The Pub / English British support
« on October 11th, 2011, 03:30 PM »
I was wondering about this, since I figure it was inevitably going to come up (if nothing else, I'll probably end up wanting to do it)

Now, I figure there's a way that we can do that and make life quite easy to support the English British set without too much extra work.

loadLanguage already loads English standard anyway, as a fallback, so the required strings should always be declared. But if you're doing that, you can be very cheeky and just have English British quite literally be *only the changed strings*. If there's no difference between English and English British for a given string, why define it again?

There is one caveat: right now, the load-fallback is actually a setting, though there's no UI for it, because I figure you almost never would change it (and if you did want to change it, it's not like you couldn't just tweak the code manually... if you're at the stage where it would make a difference, you're going to be up to making code changes)

Curious to know what the thoughts are on this, both technically and generally.
5950
The Pub / Re: Spell checker
« on October 11th, 2011, 02:52 PM »
Quote
Still some that don't have a spell check and really need it
Would these be the same people who wouldn't use it even if they had it? :whistle:
5951
Features / Re: New revs
« on October 11th, 2011, 02:00 PM »
Revision: 1096
Author: arantor
Date: 12:59:57, 11 October 2011
Message:
! Cleaned up some language strings, less of this composite stuff and more unified strings that can be translated meaningfully. (Load.php, SSI.php, InfoCenter.template.php, index.english.php)
----
Modified : /trunk/SSI.php
Modified : /trunk/Sources/Load.php
Modified : /trunk/Themes/default/InfoCenter.template.php
Modified : /trunk/Themes/default/languages/index.english.php
5952
Features / Re: New revs
« on October 11th, 2011, 01:14 PM »
Revision: 1095
Author: arantor
Date: 12:08:05, 11 October 2011
Message:
! Performance optimisation that actually didn't work properly (ManagePlugins.php)

! Improved layout when there's an error in plugins. (ManagePlugins.template.php, admin.css)
----
Modified : /trunk/Sources/ManagePlugins.php
Modified : /trunk/Themes/default/ManagePlugins.template.php
Modified : /trunk/Themes/default/skins/admin.css
5953
Features / Re: New revs
« on October 11th, 2011, 01:08 PM »
Revision: 1094
Author: arantor
Date: 12:00:34, 11 October 2011
Message:
! If a plugin is already enabled, disallow any other plugin using the same id from being enabled. Anyone upgrading a plugin will by definition need to disable the older one before enabling the new one. (The whole nature of hot-upgrade-in-place is fraught with danger. It depends how much initialisation you do on start-up, we don't do much for performance's sake, which means caches etc. MUST be cleared by next runtime on a plugin's run. By forcing that break, it makes everything a lot safer.) (ManagePlugins.php, ManagePlugins language file)
----
Modified : /trunk/Sources/ManagePlugins.php
Modified : /trunk/Themes/default/languages/ManagePlugins.english.php
5954
Features / Re: Birthday, calendar, plugin, core [VOTE NOW!]
« on October 11th, 2011, 01:01 PM »
Quote from billy2 on October 11th, 2011, 01:00 PM
* billy2 thinks to himself - If Birth Dates have to remain in Core, why is Arantor asking why I think Birthdays should be in the core. Are they not one of the same?

I've got a headache
No, they're totally different things.

Storing the birth date is required for COPPA compliance and must remain core for that reason.

Sending out nice emails, or displaying a list of everyone's birthdays is not required for compliance and is the part I want to move out of the core.
5955
The Pub / Re: Spell checker
« on October 11th, 2011, 12:31 PM »
Quote
- It represents a sizeable amount of code. Most entries don't take extra CPU cycles when spellchecking is disabled, but it does for instance add 1.5KB of data to the JS editor, even if disabled/not available.
That would be beneficial to remove, I think.
Quote
- There is nothing that prevents us from using pspell in the search feature to show potential typos *EVEN* with spellchecking disabled or removed entirely.
If it were going to be removed entirely, I'd also have removed the entries in each index.language.php file to cover for the variations in dictionary to be used. But yeah, there's no reason we can't do that.


Also, I mentioned it in the area for signatures. Is that actually necessary? (Mind you, I've thought about integrating the full editor into the signature area anyway so it would be component of that)