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.
Topics - Arantor
301
Plugins / Quick little plugin
« on October 23rd, 2011, 01:59 AM »
OK, tonight's little project is one of those that I'm doing mostly under protest. Which begs the question why I'm doing it at all, and the answer is stupid user prevention.
I would generally rather inform users about the true facts of what they're trying to do, than pander to their ill-informed and frankly dangerous misinformation, but you know users: too many of them are a bit naive.
Tonight's project is one such example: disable right click.
It's useless as plugins go, because it's insanely trivial to bypass it, but you know how some users feel it's useful for protecting their content, and it's one more thing that I can publish, they can find and use and feel happier in its 'glory', or they can download it and then read the readme that covers it in detail. But hey, either way, I've done the best I can.
I would generally rather inform users about the true facts of what they're trying to do, than pander to their ill-informed and frankly dangerous misinformation, but you know users: too many of them are a bit naive.
Tonight's project is one such example: disable right click.
It's useless as plugins go, because it's insanely trivial to bypass it, but you know how some users feel it's useful for protecting their content, and it's one more thing that I can publish, they can find and use and feel happier in its 'glory', or they can download it and then read the readme that covers it in detail. But hey, either way, I've done the best I can.
302
Off-topic / New coding music :D
« on October 21st, 2011, 01:29 PM »
I listen to a variety of music when coding, but most frequently it's metal or heavier rock. Queen through Meat Loaf, Iron Maiden and Nightwish are typically on that list.
And today, I present the latest addition to my coding tracklist.
Greatest Battle Music Of All Times: To Glory
There's just something awesome about coding to something like this.
And today, I present the latest addition to my coding tracklist.
Greatest Battle Music Of All Times: To Glory
There's just something awesome about coding to something like this.
303
Plugins / Plugin manager, phoning home and privacy
« on October 21st, 2011, 12:03 PM »
One of the things I've been talking a lot about is the way the plugin manager calls the different plugin servers in order to check for updates.
I'm not quite at the stage of implementing this yet so it's not like I can't change it but something occurred to me that I would like some feedback on.
Imagine a large repository, of a couple of thousand plugins - like sm.org has. It's realistic to expect that Wedge will get to that point sooner or later (preferably sooner!), and at that point it starts to be unviable to be requesting a list of everything the server has - it's not good for the server, it's not great for the client either.
So I conceived of the notion of having the request actually include a list of plugins that it has available, and the server responds with a list of what it has in it that matches by id, so you know whether to update or not. This idea is not unknown, WordPress does it, for example.
The difference is that WordPress only supports its own repository, not third party repos, in the core code - we expressly support third parties.
Here's the problem. While I can guarantee that my own server(s) won't log requests[1], I can't guarantee other servers won't do the same, so that if a list of plugins is sent, it would be possible to log what plugins you have.
And, naturally, there is a privacy concern here as a result.
I should note what I'm planning on logging as a core feature of the plugin server system (the actual server facility itself) - it should be able to log downloads (total and per day downloads), and if a plugin is secured by group access, i.e. it's not open to guests or regular members, I think it should also log the name and time of download as well as the user who downloaded it.
I think the above logging should be provided because it's useful to see how many people are downloading plugins, whether they're still being downloaded currently (or just historically), and if it's secured behind some kind of authorisation, it should be able to log who's downloading for the simple reason that you're offering a product behind some kind of restriction and you should be able to identify an account or accounts that are using that facility.
Thoughts?
I'm not quite at the stage of implementing this yet so it's not like I can't change it but something occurred to me that I would like some feedback on.
Imagine a large repository, of a couple of thousand plugins - like sm.org has. It's realistic to expect that Wedge will get to that point sooner or later (preferably sooner!), and at that point it starts to be unviable to be requesting a list of everything the server has - it's not good for the server, it's not great for the client either.
So I conceived of the notion of having the request actually include a list of plugins that it has available, and the server responds with a list of what it has in it that matches by id, so you know whether to update or not. This idea is not unknown, WordPress does it, for example.
The difference is that WordPress only supports its own repository, not third party repos, in the core code - we expressly support third parties.
Here's the problem. While I can guarantee that my own server(s) won't log requests[1], I can't guarantee other servers won't do the same, so that if a list of plugins is sent, it would be possible to log what plugins you have.
And, naturally, there is a privacy concern here as a result.
I should note what I'm planning on logging as a core feature of the plugin server system (the actual server facility itself) - it should be able to log downloads (total and per day downloads), and if a plugin is secured by group access, i.e. it's not open to guests or regular members, I think it should also log the name and time of download as well as the user who downloaded it.
I think the above logging should be provided because it's useful to see how many people are downloading plugins, whether they're still being downloaded currently (or just historically), and if it's secured behind some kind of authorisation, it should be able to log who's downloading for the simple reason that you're offering a product behind some kind of restriction and you should be able to identify an account or accounts that are using that facility.
Thoughts?
| 1. | This should include wedge.org, though there is a valid logic behind doing it here too, which if done anonymously allows us to see which plugins are popular, not just downloaded but what is downloaded *and still being used*. |
304
Plugins / More pictures of the plugin manager
« on October 21st, 2011, 03:10 AM »
The plugin manager is a very very big thing for me, I want to get it right.
Now, as I've mentioned before, the idea is that daily it's going to call into the different plugin servers listed and see if there are any updates to any of the plugins you have. (Yes, you can turn this off! But it makes sense to make it on by default, as it were.)
The other thing you'll be able to do is provide a username/password for private sites so that you'll be able to be notified automatically of updates - even on private mod sites.
Here's a demo of the screen as it stands right now - you'll notice the old 'download from a URL' option is gone, and that there's a revised upload and download area (with adding a repo / package server being on a new page)
On this particular case, I've set it to fake being 'error' (so that if it couldn't call a given site, it flags it as in error and won't call on it again until you reset it, to avoid repeatedly trying to hammer broken links etc), and I've manually put in a user name into the system so it displays the fact that there's a user account attached to that server.
(I also happen to think it's more consistently styled compared to the rest of the admin panel, but that's just my biased view :P)
Now, as I've mentioned before, the idea is that daily it's going to call into the different plugin servers listed and see if there are any updates to any of the plugins you have. (Yes, you can turn this off! But it makes sense to make it on by default, as it were.)
The other thing you'll be able to do is provide a username/password for private sites so that you'll be able to be notified automatically of updates - even on private mod sites.
Here's a demo of the screen as it stands right now - you'll notice the old 'download from a URL' option is gone, and that there's a revised upload and download area (with adding a repo / package server being on a new page)
On this particular case, I've set it to fake being 'error' (so that if it couldn't call a given site, it flags it as in error and won't call on it again until you reset it, to avoid repeatedly trying to hammer broken links etc), and I've manually put in a user name into the system so it displays the fact that there's a user account attached to that server.
(I also happen to think it's more consistently styled compared to the rest of the admin panel, but that's just my biased view :P)
305
The Pub / Improving SSI - if you use SSI, your opinion will be most desirable here
« on October 21st, 2011, 12:38 AM »
SSI is a big beast of a file, and it ends up loading a couple of thousand lines of code, of which a lot of users won't even be using. If, for example, you just do authentication with it, you won't use most of the code there.
Then you have the functions themselves. My personal favourite is ssi_boardNews, which is:
Code: [Select]
There are some issues with this. For example if you want to get the information back you can't just use (the rather logical):
Code: [Select]
It just doesn't work like that.
Then you have the facilities I built into http://custom.simplemachines.org/mods/index.php?mod=2280 for multiple boards and much more stuff. Which, you'll notice, doesn't one massive function call, you set all the options you want first.
So, I thought... how about we do something similar, but cleaner and able to be much more configurable?
Here's what I'm proposing.
Instead of ssi_boardNews(1); to get the news from board 1, I'm thinking about:
Code: [Select]
It looks worse, but hear me out. There are a bunch of things that can be achieved with this.
Firstly, we can remove all the SSI functions out of the file and put them somewhere else, so that you only load what you need, and we achieve this with a thing called an autoloader. (Specifically, an SPL one, but don't worry about that.)
So you just request SSI_boardNews() as a class like above, it goes and makes sure the class is available and boom, you can output the board news with it.
But having it set up like that means it's trivial to add different options at will - instead of having a massive function call to set the number of items, the start/length/whatever, you can set all those with separate calls, e.g. to get items 11 to 20 (page 2), the first 500 characters, you would do:
Code: [Select]
And there's no set order, no requirement to list all parameters, just the ones you want to change compared to the default. (I could even put the board number into the SSI_boardNews call itself for keeping it small's sake)
Thoughts?
:edit: Interesting side benefit, it would allow you to be able to load individual SSI components as needed without having to load the entire file.
Then you have the functions themselves. My personal favourite is ssi_boardNews, which is:
ssi_boardNews($board = null, $limit = null, $start = null, $length = null, $output_method = 'echo')There are some issues with this. For example if you want to get the information back you can't just use (the rather logical):
$var = ssi_boardNews($board = 1, $output_method = 'array');It just doesn't work like that.
Then you have the facilities I built into http://custom.simplemachines.org/mods/index.php?mod=2280 for multiple boards and much more stuff. Which, you'll notice, doesn't one massive function call, you set all the options you want first.
So, I thought... how about we do something similar, but cleaner and able to be much more configurable?
Here's what I'm proposing.
Instead of ssi_boardNews(1); to get the news from board 1, I'm thinking about:
$var = new SSI_boardNews();
$var->setBoard(1);
$var->output();It looks worse, but hear me out. There are a bunch of things that can be achieved with this.
Firstly, we can remove all the SSI functions out of the file and put them somewhere else, so that you only load what you need, and we achieve this with a thing called an autoloader. (Specifically, an SPL one, but don't worry about that.)
So you just request SSI_boardNews() as a class like above, it goes and makes sure the class is available and boom, you can output the board news with it.
But having it set up like that means it's trivial to add different options at will - instead of having a massive function call to set the number of items, the start/length/whatever, you can set all those with separate calls, e.g. to get items 11 to 20 (page 2), the first 500 characters, you would do:
$var = new SSI_boardNews();
$var->setBoard(1);
$var->setStart(10); // skipping 10 items, to start at 11, normally you start with the first 1 by skipping 0 items
$var->setLimit(10);
$var->setLength(500);
$var->output();And there's no set order, no requirement to list all parameters, just the ones you want to change compared to the default. (I could even put the board number into the SSI_boardNews call itself for keeping it small's sake)
Thoughts?
:edit: Interesting side benefit, it would allow you to be able to load individual SSI components as needed without having to load the entire file.
306
Features / Storing the modified-post user id
« on October 20th, 2011, 11:58 PM »
For a reason I've never understood, SMF never stored the user id of a modified post. It stores the name and the time - the bare minimum, I guess - but not the user id.
I figure we should store the user id and actually add that to the list of ids we query during Display startup, so that we can actually display not only the current name (as opposed to whatever name they used at the time) but we can link to it.
It also allows for some other interesting consequences, like if the last person who edited your post was a moderator, it could relatively easily prevent non-moderators then editing that post.
There is a storage cost (~3 bytes per message) and a slight performance hit though I'd argue that fairly often the editor on a post is someone who has already posted in the topic (recently) anyway, e.g. the author, or a moderator...
Thoughts?
I figure we should store the user id and actually add that to the list of ids we query during Display startup, so that we can actually display not only the current name (as opposed to whatever name they used at the time) but we can link to it.
It also allows for some other interesting consequences, like if the last person who edited your post was a moderator, it could relatively easily prevent non-moderators then editing that post.
There is a storage cost (~3 bytes per message) and a slight performance hit though I'd argue that fairly often the editor on a post is someone who has already posted in the topic (recently) anyway, e.g. the author, or a moderator...
Thoughts?
307
Off-topic / Hmm, worth spending a few minutes thinking about
« on October 20th, 2011, 04:47 PM »
http://www.theregister.co.uk/2011/10/20/are_ip_addresses_personal_data/
That's a very, very good question. You can probably figure out what my answer to that question is, from this blog post.[1]
Also rather interesting is to read the comments, in particular at the countries that do consider it to be personal data.
That's a very, very good question. You can probably figure out what my answer to that question is, from this blog post.[1]
Also rather interesting is to read the comments, in particular at the countries that do consider it to be personal data.
| 1. | If not, the answer is complicated. Yes, it can help identify an individual, but it's not that rock solid, and that there are quite a few ways to compromise it, so that it should be considered a reasonable piece of information, not a concrete 'this definitely identifies a unique user', because it doesn't. The result is that I'm downplaying the use of IP addresses for account-level items. |
308
Off-topic / I'm not quite sure how I'm supposed to deal with this
« on October 20th, 2011, 04:13 PM »309
Off-topic / The UK's idea of policing the internet
« on October 19th, 2011, 04:45 PM »
Have a read of http://www.theregister.co.uk/2011/10/19/proposals_on_defamation_law/
It has interesting consequences for us (well, me in particular :P)
I think the whole anonymous thing is going to bite people in the arse before long, personally, but one thing I do find interesting is the notion of publishing a complaint next to a post itself. That essentially means publishing the report-to-moderator stuff as freely as regular posting. I see two problems with this.
Firstly, it seems to me that the complainant will have to identify themselves, which if I were to - say - report a post because I find it offensive, I'm essentially telling the world that I personally have a problem with a post. While that's not a great example, imagine a forum with more sensitive discussions, e.g. personal abuse support. I certainly wouldn't want my name attached to a publicly-visible complaint.
Secondly, can we say spam magnet? Posts can be moderated but complaints don't appear to be such.
Sure, we can indicate 'type of complaint', such that personal complaints don't need to be made public and can be restricted to intra-forum matters, e.g. reporting spam, personal offence, and leave libel ones public. But that won't solve the spam bot problem, since they'll just learn to select 'libel' to have their crap posted publicly.
Thoughts?
It has interesting consequences for us (well, me in particular :P)
I think the whole anonymous thing is going to bite people in the arse before long, personally, but one thing I do find interesting is the notion of publishing a complaint next to a post itself. That essentially means publishing the report-to-moderator stuff as freely as regular posting. I see two problems with this.
Firstly, it seems to me that the complainant will have to identify themselves, which if I were to - say - report a post because I find it offensive, I'm essentially telling the world that I personally have a problem with a post. While that's not a great example, imagine a forum with more sensitive discussions, e.g. personal abuse support. I certainly wouldn't want my name attached to a publicly-visible complaint.
Secondly, can we say spam magnet? Posts can be moderated but complaints don't appear to be such.
Sure, we can indicate 'type of complaint', such that personal complaints don't need to be made public and can be restricted to intra-forum matters, e.g. reporting spam, personal offence, and leave libel ones public. But that won't solve the spam bot problem, since they'll just learn to select 'libel' to have their crap posted publicly.
Thoughts?
310
The Pub / When can I download Wedge? / Where can I download Wedge?
« on October 19th, 2011, 02:48 PM »
Right now, you can't. It's not done yet. And if we were to release it right now, it would really be inappropriate.
There's a lot of things that we want, and need, to do that haven't yet been done. Some things are fundamentally broken or missing critical functionality.
Even if you're a hardcore user, it's still not ready for you, because even the installation doesn't work off the bat without some work (the installer is not stored in the main folder, and has to be moved from another folder prior to installation to make it work properly)
We know you're eager, because we've told you all the goodies that are coming in Wedge, some that are done, some that are coming. But you really need to understand that firstly, it's just two of us writing it, and that we do have lives outside of Wedge - even though we're putting a vast amount of time into it.
This post will be updated in the future, though, as it becomes available.
Why did I even write this? It's because I'm frustrated. I've lost count of the number of people who've come here asking for downloads. Some post publicly, some privately message me, and I'm fed up of it. We don't owe anyone anything, and while I love working on it, I don't love feeling like it's a noose around my neck - and each time I see such a message, I feel like that's where it'll head, as people don't seem to realise that we do this for fun, and not because we're paid to make them something for nothing.
Wedge has a bright and amazing future but you have to let us make it happen in a way we're comfortable with - and that means not rushing releases. That means we take as long as we feel is necessary to make it work. You can see the progress in the New Revs thread. That should give you some idea of the scale of changes that are underway - commits happen every day or at worst every couple of days, far higher and far more thoroughly than a good number of open source projects manage, in fact.
I'm also annoyed a lot in the fact that people don't seem to look around before asking. Is it really that hard to grasp that it isn't ready yet? Is it really that hard to spend a little time looking around and seeing what we're about? I guess it actually is, given how many people I'm aware of have just come along, posted without reading just because they want cool free stuff, without taking the time to understand what we're about.
Anyway, here endeth the rant. Keep calm and carry on!
There's a lot of things that we want, and need, to do that haven't yet been done. Some things are fundamentally broken or missing critical functionality.
Even if you're a hardcore user, it's still not ready for you, because even the installation doesn't work off the bat without some work (the installer is not stored in the main folder, and has to be moved from another folder prior to installation to make it work properly)
We know you're eager, because we've told you all the goodies that are coming in Wedge, some that are done, some that are coming. But you really need to understand that firstly, it's just two of us writing it, and that we do have lives outside of Wedge - even though we're putting a vast amount of time into it.
This post will be updated in the future, though, as it becomes available.
Why did I even write this? It's because I'm frustrated. I've lost count of the number of people who've come here asking for downloads. Some post publicly, some privately message me, and I'm fed up of it. We don't owe anyone anything, and while I love working on it, I don't love feeling like it's a noose around my neck - and each time I see such a message, I feel like that's where it'll head, as people don't seem to realise that we do this for fun, and not because we're paid to make them something for nothing.
Wedge has a bright and amazing future but you have to let us make it happen in a way we're comfortable with - and that means not rushing releases. That means we take as long as we feel is necessary to make it work. You can see the progress in the New Revs thread. That should give you some idea of the scale of changes that are underway - commits happen every day or at worst every couple of days, far higher and far more thoroughly than a good number of open source projects manage, in fact.
I'm also annoyed a lot in the fact that people don't seem to look around before asking. Is it really that hard to grasp that it isn't ready yet? Is it really that hard to spend a little time looking around and seeing what we're about? I guess it actually is, given how many people I'm aware of have just come along, posted without reading just because they want cool free stuff, without taking the time to understand what we're about.
Anyway, here endeth the rant. Keep calm and carry on!
311
Plugins / Plugin servers / getting plugins to a system
« on October 13th, 2011, 06:19 PM »
So, this is one of the things I've been thinking about lately, is how to make plugin servers work, on a technical level.
This is going to be something of a stream of consciousness rather than a focused discussion, to start with. It's more about trying to make sense of all my thoughts, and if you have anything to add, please do.
Let's look at what SMF has (not what it actually uses). It's all in the Packages > Download Packages page.
Up front that's stupid. You click a page called Download, so that you can upload something. It's almost as backward as the logic of clicking a Start Button to shut down, though at least they have the argument of 'starting the shutdown process'.
Idiot question of the day... should uploading plugins from your computer be a separate page to downloading from a plugin server? Gut instinct says yes, it should, because they're totally different options and processes.
That also leads in nicely to something Dragooon mentioned, about plugins having an 'app storefront' kind of deal. I've mentioned before that I'd like to be able to support the environment where creators can publish paid plugins, and still make use of something like the package server facility, currently not possible in SMF. (Incidentally I was thinking about that almost 18 months ago, if not further back)
Hmm. Seems to me that the actual process of getting a list of plugins is at least as dependent on what interface to use to display, as anything else. SMF provides the ability to accept a list of plugins, and/or a list of categories, wherein you can browse categories. Thing is, that most people don't realise, is that you can also segment the package server list by category so you only need serve a list of what categories there are, then what's in each one - as opposed to the behemoth served by SMF currently that actually breaks some installs with low memory limits.
Then again, that's when you have a public list. If the list is potentially private or semi private, or in any way filterable, it needs to be accommodated by the server, not the client, which means that just serving a packages.xml type file isn't an answer. Hmm. I'm sensing that you'd make a request on a given page much you do with feeds, and make it essentially similar to a RESTful style implementation, that the URL http://example.com/forum/index.php?action=plugins would provide a list of plugins available for download, and adding ;cat=x would filter the list by the specified category. Of course, that would be a detail provided by the server.
I'm a little wary of providing something that amounts to a storefront structure but I'm OK with the architecture providing lists of what's available and so on, especially as for anything that's premium, you'd have to be a member of their site anyway and have access to the relevant downloads.
Hmm. Should a plugin be able to list the plugin server or servers where it can be found?
Also, what exactly is the process for plugins requesting updates? I'm sensing it would be a daily process job, where the system goes to all the plugin servers it knows, with whatever credentials it has, and supplies a list of plugins. (Active plugins, all plugins?) The server itself should be doing the work on filtering down plugins, not the client. Though, if the plugin itself indicates a server or servers where it can be found, presumably only those need to be queried?
One last thing. Do we really need to support both .zip and .tar.gz? Gut instinct says no, just zip will cover the bulk of what's actually needed? (even if it does provide a shade of inconvenience for those who use *nix / OS X that write plugins... which is going to be a limited enough group anyway?)
This is going to be something of a stream of consciousness rather than a focused discussion, to start with. It's more about trying to make sense of all my thoughts, and if you have anything to add, please do.
Let's look at what SMF has (not what it actually uses). It's all in the Packages > Download Packages page.
Up front that's stupid. You click a page called Download, so that you can upload something. It's almost as backward as the logic of clicking a Start Button to shut down, though at least they have the argument of 'starting the shutdown process'.
Idiot question of the day... should uploading plugins from your computer be a separate page to downloading from a plugin server? Gut instinct says yes, it should, because they're totally different options and processes.
That also leads in nicely to something Dragooon mentioned, about plugins having an 'app storefront' kind of deal. I've mentioned before that I'd like to be able to support the environment where creators can publish paid plugins, and still make use of something like the package server facility, currently not possible in SMF. (Incidentally I was thinking about that almost 18 months ago, if not further back)
Hmm. Seems to me that the actual process of getting a list of plugins is at least as dependent on what interface to use to display, as anything else. SMF provides the ability to accept a list of plugins, and/or a list of categories, wherein you can browse categories. Thing is, that most people don't realise, is that you can also segment the package server list by category so you only need serve a list of what categories there are, then what's in each one - as opposed to the behemoth served by SMF currently that actually breaks some installs with low memory limits.
Then again, that's when you have a public list. If the list is potentially private or semi private, or in any way filterable, it needs to be accommodated by the server, not the client, which means that just serving a packages.xml type file isn't an answer. Hmm. I'm sensing that you'd make a request on a given page much you do with feeds, and make it essentially similar to a RESTful style implementation, that the URL http://example.com/forum/index.php?action=plugins would provide a list of plugins available for download, and adding ;cat=x would filter the list by the specified category. Of course, that would be a detail provided by the server.
I'm a little wary of providing something that amounts to a storefront structure but I'm OK with the architecture providing lists of what's available and so on, especially as for anything that's premium, you'd have to be a member of their site anyway and have access to the relevant downloads.
Hmm. Should a plugin be able to list the plugin server or servers where it can be found?
Also, what exactly is the process for plugins requesting updates? I'm sensing it would be a daily process job, where the system goes to all the plugin servers it knows, with whatever credentials it has, and supplies a list of plugins. (Active plugins, all plugins?) The server itself should be doing the work on filtering down plugins, not the client. Though, if the plugin itself indicates a server or servers where it can be found, presumably only those need to be queried?
One last thing. Do we really need to support both .zip and .tar.gz? Gut instinct says no, just zip will cover the bulk of what's actually needed? (even if it does provide a shade of inconvenience for those who use *nix / OS X that write plugins... which is going to be a limited enough group anyway?)
312
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 />
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. |
313
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.
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.
314
Features / Birthday, calendar, plugin, core [VOTE NOW!]
« on October 10th, 2011, 05:11 PM »
As per http://wedge.org/pub/feats/6931/the-calendar/ I've been trying to get a feel for how to handle birthdays and the calendar. So instead of faffing about with discussion, simple poll instead. I've deliberately kept it to a fresh thread to allow it to be considered objectively.
Remember: any plugins that are based on core code originally will almost certainly be considered as 'official' plugins and thus maintained over time.
Remember: any plugins that are based on core code originally will almost certainly be considered as 'official' plugins and thus maintained over time.
315
The existing PM popup has long bugged me, and after Nas' enhanced PM popup, I thought I'd give it a shot in Wedge (as a core feature, rather than a plugin)
It's still a WIP but here's what I got so far. I may not finish it (and abandon my changes) or tweak it, haven't really decided yet.
(Yes, I know it needs a border, and some actual content.)
It's still a WIP but here's what I got so far. I may not finish it (and abandon my changes) or tweak it, haven't really decided yet.
(Yes, I know it needs a border, and some actual content.)