Inactive
Inactive projects are classified due to one or more of the following:
Confirmed licensing and public distribution
Confirmation by a member-only poll to Abandon the project
(See related links on the specific overview page of the project for further information)
Stalled
Stalled projects are identified with the following notice:
{{Template:STALLED}}
This is due to one or more of the following:
No registered Translators.
Registered Staff are inactive.
Project has not progressed for at least 12 months.
"Please note, we have added a consequence for failure.Any contact with the chamber floor will result in an unsatisfactory mark on your official test record, followed by death. Good luck."
Regardless, I'm more in favor of a page of projects (split into sub-pages perhaps) with their last update status (only when new content gets posted).
Moving projects between categories is too confusing especially if something unexpected happens, and a project gets revived just shortly after being moved to inactive or something.
If I have time, I would actually do one, but alas......
Regardless, I'm more in favor of a page of projects (split into sub-pages perhaps) with their last update status (only when new content gets posted).
Moving projects between categories is too confusing especially if something unexpected happens, and a project gets revived just shortly after being moved to inactive or something.
If I have time, I would actually do one, but alas......
I've actually copy-pasted all of manga-updates BT release entries onto my computer. With a little java, it's not too difficult to fetch the most recent updates for all the projects, and print into into a wiki-compatible table format or something. It would be essentially an automatic process (copying from Manga Updates), adding it to the giant text file of all of BT updates, and then getting a program to parse for the most recent of each series; I don't imagine it would be too difficult to maintain if we wanted a real "Project Updates Page" on the Wiki instead of the one we have on the forum...
Ideally, we'd want some kind of MySQL database where we'd store all the info about the updates (someone would need to feed it updates)... and that would automatically print stats, pictures, and pretty summaries about all the projects in php... but... I'm too lazy to set up a database for this kind of thing. But it shouldn't be too difficult given that Manga Updates has all the data already.|D
Regardless, I'm more in favor of a page of projects (split into sub-pages perhaps) with their last update status (only when new content gets posted).
Moving projects between categories is too confusing especially if something unexpected happens, and a project gets revived just shortly after being moved to inactive or something.
If I have time, I would actually do one, but alas......
I'm looking towards making a page of project. Do we just arrange them in alphabetically?
EDIT: There are pages making use of templates to put updates onto their own main project page.
I think all of us have been too lazy to try making a projects page at the moment... |D
So, I tried porting my text file of updates to OpenOffice database... but after a couple hours it started crashing T____T More ideally, it'd be nice to put it on someplace with MySQL and query it for the most recent of each project... and return it automatically with PHP.... but now I'm rambling. xD This isn't the ideal solution anyways.
While I was wasting time yesterday, I found some potential methods to track updates without needing to rely on significant human effort... and is actually supported by MediaWiki.
The first one is "Revision Tagging". Notice how on there's a "Tag" filter on the Recent Changes page? If we could figure out a way to tag the revisions that are associated with completed chapters, we could get a recent updates page that looks like this.
Unfortunately... I'm not very clear on how to get these "tags". And it seems like they have to be added when edit is made.
Another hypothetical alternative would be to use a MediaWiki extension known as "Flaggedrevs", or perhaps figure out some other work around....... but at this point it's getting way too overcomplicated just to track some recent updates. |D
EDIT:
Interestingly, we could use the "Patrol log" as a workaround for marking completed chapters. No one really uses the mark edit as patrolled anyways. It's very nice, because you can also filter it by what the title of the page starts by.
Regardless, I'm more in favor of a page of projects (split into sub-pages perhaps) with their last update status (only when new content gets posted).
Moving projects between categories is too confusing especially if something unexpected happens, and a project gets revived just shortly after being moved to inactive or something.
If I have time, I would actually do one, but alas......
ooohhhh...shiiinnnnyyy!!!!
Front page does need a revamp! I want more proposals on the wiki, linked back here, with a summary why it's good and why it's better and how it will work with the sidebar and not break the baka EX mobile app.
I will review it and put the ones that i like on a community wide poll. That is all. Make it so. I want it on my desk pronto. The dog has a biscuit. This is sparta.
Edit: please email me a reminder. its the only way i know there is any progress around here.
"Please note, we have added a consequence for failure.Any contact with the chamber floor will result in an unsatisfactory mark on your official test record, followed by death. Good luck."
Is the app still actively being developed?
Is it open-source and available on git or something? That will allow someone to make changes to it (not me though, anyway, I think I already lost all my coding skills ).
If only we have direct access to the database of the wiki.
I was thinking of a possibility to make a wiki crawler to crawl baka-tsuki and build an external database of page names (we just need a standardized format of naming pages to identify project scope?) and links, and let BakaReader to query that database instead of parsing the wiki pages directly. Shrug, not too sure whether I'm on the right track with my thoughts.
larethian wrote:Is the app still actively being developed?
Is it open-source and available on git or something? That will allow someone to make changes to it (not me though, anyway, I think I already lost all my coding skills :lol:).
If only we have direct access to the database of the wiki.
I was thinking of a possibility to make a wiki crawler to crawl baka-tsuki and build an external database of page names (we just need a standardized format of naming pages to identify project scope?) and links, and let BakaReader to query that database instead of parsing the wiki pages directly. Shrug, not too sure whether I'm on the right track with my thoughts.
Direct access would be nice, but it would only make the data collection part faster not easier, since the data is the same -- unless you mean that we could use it to store the crawler data, which would indeed be a gift from heaven, especially if bundled with access to the web server to add a simple web interface. In fact, I needed a similar DB layout for my statistics web app.
The MediaWiki platform just isn't suited for the kind of structure we need... but iirc there have been discussions on this in the B-T app thread, and there's even this.
If you couldn't tell, I've been rather lazy... meaning, I haven't cleaned anything up. Also, IDK if we should keep the images. It's probably a huge strain on the server to list them all. This is really just a proof of concept.
Last week I registered a free server at 000webhost, pulled off all the data from mangaupdates, and then imported it in. Then, through php, a simple SQL query can fetch the most recent updates of each project.
Basically, you just have to go to the external place, copy the code, and paste it into the Full Projects listing page. The php automatically updates for the most recent updates, and automatically sorts things properly into stalled/active, etc.
Sometime later, I'll probably make a form that can let pretty much anyone enter new entries in. But... it works.
larethian wrote:Is the app still actively being developed?
Is it open-source and available on git or something? That will allow someone to make changes to it (not me though, anyway, I think I already lost all my coding skills ).
If only we have direct access to the database of the wiki.
I was thinking of a possibility to make a wiki crawler to crawl baka-tsuki and build an external database of page names (we just need a standardized format of naming pages to identify project scope?) and links, and let BakaReader to query that database instead of parsing the wiki pages directly. Shrug, not too sure whether I'm on the right track with my thoughts.
Direct access would be nice, but it would only make the data collection part faster not easier, since the data is the same -- unless you mean that we could use it to store the crawler data, which would indeed be a gift from heaven, especially if bundled with access to the web server to add a simple web interface. In fact, I needed a similar DB layout for my statistics web app.
The MediaWiki platform just isn't suited for the kind of structure we need... but iirc there have been discussions on this in the B-T app thread, and there's even this.
I don't know where Michael has vanished, but I'm slowly making that WebApp. But I'm a working person, so I don't have much time to work on it.
I'll say it beforehand, I'm aiming towards more control and automatics. But will try to make it be open as the wiki, in terms of editing posting and such things.
Still have to upload the code that I have in my local git repo.
Cloudii, so... as I understand, you scrape B-U and format it. Right ? If so, I'm gonna try to write a small py script that does the same, but a bit more dynamically. I hope you don't mind.
On other hand if you need an environment to run all that without restrictions(coding language, extensions, etc.), I could provide you these. If you want.
ePUB Generator <<Productive>> : BTE-GEN | Yay, I'm free. Let's see how long it takes for this place to go down.
at the moment there are several threads going on about changing BT Quality, the main page, etc.
Those are major changes, especially the discussion about how to improve the quality overall. In my humble opinion it would be nice if we first tend to some smaller things, to warm ourselves up for bigger tasks. In other words: If we could improve/solve a single thing before the year ends.
The Problem
So, one thing strikes the eye especially hard when one comes to BT. The sidebar. It's long and longer. Overloaded with all kinds of novels in all kinds of states.
"What you gonna do about it?"
Cautr's Humble Idea
Don't list the projects on the sidebar. Create a single (protected) page, which then lists the projects which would otherwise be listed on the sidebar. Just like the teaser category works.
This page then gets linked on the sidebar under the category "Light-Novels", which contains the sub-categories "(Full) Projects", "Teaser", "Abandoned", "Alternative Languages". Alternatively name "(Full) Projects" "Light-Novels", but it'd look stupid, wouldn't it?
The page could also be visibly linked on the front page.
Pro's and Con's
Contra: No more instant access to single series.
Pro: Administration-wise no different from the sidebar (if protected); less to no scrolling, all projects will be listed on one page; better use of widescreen-merits, as it uses the width of a monitor instead of the height; maybe some funky features like project banners; tidied up sidebar
Outro (Can Skip)
I have, of course, other ideas in mind like the "to make a project a full project, you have to translate at least one volume", but this wouldn't directly be a change to the sidebar, but to the project guidelines, which then affect the sidebar along, so this wouldn't be the right thread for it. (Would also only cut the sidebar by ~15%)
So, basically, what's wrong with this? As I am sick (be nice to me), I cannot think of too many reasons why this wouldn't work.
I believe Ctrl+F works just fine, and a majority of readers likely have the main page of the novel they wish to read bookmarked.
This type of proposal has been brought up before, and honestly I do partially agree with it, but while gaining greater organization it does hurt the immediate accessibility of a novel.
).
