Fix up a bunch of pages
This commit is contained in:
Paul Friederichsen
parent
8007351af9
commit
8acf752bc3
|
|
@ -1,3 +1,8 @@
|
|||
---
|
||||
hide:
|
||||
- navigation
|
||||
---
|
||||
|
||||
# Virtual Memory Under Linux
|
||||
|
||||
## Why does hydrus keep crashing under Linux when it has lots of virtual memory?
|
||||
|
|
@ -65,7 +70,7 @@ Set `vm.overcommit_memory=1` this prevents the OS from using a heuristic and it
|
|||
#### What about swappiness?
|
||||
Swapiness is a setting you might have seen, but it only determines Linux's desire to spend a little bit of time moving memory you haven't touched in a while out of real memory and into virtual memory, it will not prevent the OOM condition it just determines how much time to use for moving things into swap.
|
||||
|
||||
# Why does my Linux system studder or become unresponsive when hydrus has been running a while?
|
||||
## Why does my Linux system studder or become unresponsive when hydrus has been running a while?
|
||||
|
||||
You are running out of pages because Linux releases I/O buffer pages only when a file is closed. Thus the OS is waiting for you to hit the watermark(as described in "why is hydrus crashing") to start freeing pages, which causes the chug. When contents is written from memory to disk the page is retained so that if you reread that part of the disk the OS does not need to access disk it just pulls it from the much faster memory. This is usually a good thing, but Hydrus does not close database files so it eats up pages over time. This is really good for hydrus but sucks for the responsiveness of other apps, and will cause hydrus to consume pages after doing a lengthy operation in anticipation of needing them again, even when it is thereafter idle. You need to set `vm.dirtytime_expire_seconds` to a lower value.
|
||||
|
||||
|
|
@ -84,7 +89,7 @@ https://www.kernel.org/doc/Documentation/sysctl/vm.txt
|
|||
|
||||
|
||||
|
||||
# Why does everything become clunky for a bit if I have tuned all of the above settings?
|
||||
## Why does everything become clunky for a bit if I have tuned all of the above settings?
|
||||
|
||||
The kernel launches a process called `kswapd` to swap and reclaim memory pages, its behaviour is goverened by the following two values
|
||||
|
||||
|
|
@ -11,7 +11,7 @@ Short for <b>P</b>ublic <b>T</b>ag <b>R</b>epository, a now community managed r
|
|||
Most of the things in this document also applies to [self-hosted servers](https://hydrusnetwork.github.io/hydrus/help/server.html), except for tag guidelines.
|
||||
|
||||
## Connecting to the PTR
|
||||
The easiest method is to use the built in function, found under `help -> add the public tag repository`. For adding it manually, if you so desire, read the Hydrus help document on [access keys](https://hydrusnetwork.github.io/hydrus/help/access_keys.html).
|
||||
The easiest method is to use the built in function, found under `help -> add the public tag repository`. For adding it manually, if you so desire, read the Hydrus help document on [access keys](access_keys.md).
|
||||
If you are starting out completely fresh you can also download a fully synced client [here](https://koto.reisen/quicksync/). Though possibly a bit (couple of days or so usually) out of date it will none the less save time. Some settings may differ from the defaults of an official installation.
|
||||
Once you are connected Hydrus will proceed to download and then process the update files. The progress of this can be seen under `services -> review services -> remote -> tag repositories -> public tag repository`. Here you can view its status, your account (the default account is a shared public account. Currently only janitors and the administrator have personal accounts), tag status, and how synced you are. Being behind on the sync by a certain amount makes you unable to push tags and petitions until you are caught up again.
|
||||
|
||||
|
|
@ -53,7 +53,7 @@ Janitors are the people that review petitions. You can meet us at the community
|
|||
|
||||
## Tag Guidelines
|
||||
|
||||
These are a mix of standard practice used by various boorus and changes made by Hydrus Developer and PTR users, ratified by the janitors that actually have to manage all of this. The "full" document is viewable at [Cuddle's git repo](https://raw.githubusercontent.com/CuddleBear92/Hydrus-Presets-and-Scripts/master/tag%20guidelines). See Hydrus Developer's [thoughts on a public tagging schema](https://hydrusnetwork.github.io/hydrus/help/tagging_schema.html).
|
||||
These are a mix of standard practice used by various boorus and changes made by Hydrus Developer and PTR users, ratified by the janitors that actually have to manage all of this. The "full" document is viewable at [Cuddle's git repo](https://raw.githubusercontent.com/CuddleBear92/Hydrus-Presets-and-Scripts/master/tag%20guidelines). See Hydrus Developer's [thoughts on a public tagging schema](tagging_schema.html).
|
||||
|
||||
If you are looking to help out by tagging low tag-count files, remember to keep the tags objective, start simple by for example adding the characters/persons and big obvious things in the image or what else. Tagging every little thing and detail is a sure path to burnout.
|
||||
If you are looking to petition removal of tags then it is preferable to sibling common misspellings, underscores, and defunct tags rather than deleting them outright. The exception is for ambiguous tags where it is better to delete and replace with a less ambiguous tag. When deleting tags that don't belong in the image it can be helpful if you include a short description as to why.
|
||||
|
|
|
|||
|
|
@ -22,14 +22,14 @@ I recommend using the shared read-only account, below, to start with, but if you
|
|||
|
||||
I have tried very hard to ensure the PTR respects your privacy. Your account is a very barebones thing--all a server stores is a couple of random hexadecimal texts and which rows of content you uploaded, and even the memory of what you uploaded is deleted after a delay. The server obviously needs to be aware of your IP address to accept your network request, but it forgets it as soon as the job is done. Normal users are never told which accounts submitted any content, so the only privacy implications are against janitors or (more realistically, since the janitor UI is even more buggy and feature-poor than the hydrus front-end!) the server owner or anyone else with raw access to the server as it operates or its database files.
|
||||
|
||||
Most users should have very few worries about privacy. The general rule is that it is always healthy to use a VPN, but please check [here for a full discussion and explanation of the anonymisation routine](privacy.html).
|
||||
Most users should have very few worries about privacy. The general rule is that it is always healthy to use a VPN, but please check [here for a full discussion and explanation of the anonymisation routine](privacy.md).
|
||||
|
||||
## a note on resources { id="ssd" }
|
||||
|
||||
!!! danger
|
||||
**If you are on an HDD, or your SSD does not have at least 64GB of free space, do not add the PTR!**
|
||||
|
||||
The PTR has been operating since 2011 and is now huge, more than a billion mappings! Your client will be downloading and indexing them all, which is currently (2021-06) about 6GB of bandwidth and 50GB of hard drive space. It will take _hours_ of total processing time to catch up on all the years of submissions. Furthermore, because of mechanical drive latency, HDDs are too slow to process all the content in reasonable time. Syncing is only recommended if your [hydrus db is on an SSD](database_migration.html). Even then, it is healthier and allows the client to 'grow into' the PTR if the work is done in small pieces in the background, either during idle time or shutdown time, rather than trying to do it all at once. Just leave it to download and process on its own--it usually takes a couple of weeks to quietly catch up. You'll see tags appear on your files as it proceeds, first on older, then all the way up to new files just uploaded a couple days ago. Once you are synced, the daily processing work to stay synced is usually just a few minutes. If you leave your client on all the time in the background, you'll likely never notice it.
|
||||
The PTR has been operating since 2011 and is now huge, more than a billion mappings! Your client will be downloading and indexing them all, which is currently (2021-06) about 6GB of bandwidth and 50GB of hard drive space. It will take _hours_ of total processing time to catch up on all the years of submissions. Furthermore, because of mechanical drive latency, HDDs are too slow to process all the content in reasonable time. Syncing is only recommended if your [hydrus db is on an SSD](database_migration.md). Even then, it is healthier and allows the client to 'grow into' the PTR if the work is done in small pieces in the background, either during idle time or shutdown time, rather than trying to do it all at once. Just leave it to download and process on its own--it usually takes a couple of weeks to quietly catch up. You'll see tags appear on your files as it proceeds, first on older, then all the way up to new files just uploaded a couple days ago. Once you are synced, the daily processing work to stay synced is usually just a few minutes. If you leave your client on all the time in the background, you'll likely never notice it.
|
||||
|
||||
## easy setup
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ For example, whenever you tag a file with _ak-47_, you probably also want to tag
|
|||
|
||||
|
||||
|
||||
Another time, you might tag a file _character:eddard stark_, and then also have to type in _house stark_ and then _series:game of thrones_. (you might also think _series:game of thrones_ should actually be _series:a song of ice and fire_, but that is an issue for [siblings](advanced_siblings.html))
|
||||
Another time, you might tag a file _character:eddard stark_, and then also have to type in _house stark_ and then _series:game of thrones_. (you might also think _series:game of thrones_ should actually be _series:a song of ice and fire_, but that is an issue for [siblings](advanced_siblings.md))
|
||||
|
||||
Drawing more relationships would make a significantly more complicated venn diagram, so let's draw a family tree instead:
|
||||
|
||||
|
|
|
|||
|
|
@ -5,13 +5,13 @@ title: Making a Downloader
|
|||
# Making a Downloader
|
||||
|
||||
!!! caution
|
||||
Creating custom downloaders is only for advanced users who understand HTML or JSON. Beware! If you are simply looking for how to add new downloaders, please head over [here](adding_new_downloaders.html).
|
||||
Creating custom downloaders is only for advanced users who understand HTML or JSON. Beware! If you are simply looking for how to add new downloaders, please head over [here](adding_new_downloaders.md).
|
||||
|
||||
## this system { id="intro" }
|
||||
|
||||
The first versions of hydrus's downloaders were all hardcoded and static--I wrote everything into the program itself and nothing was user-creatable or -fixable. After the maintenance burden of the entire messy system proved too large for me to keep up with and a semi-editable booru system proved successful, I decided to overhaul the entire thing to allow user creation and sharing of every component. It is designed to be very simple to the front-end user--they will typically handle a couple of png files and then select a new downloader from a list--but very flexible (and hence potentially complicated) on the back-end. These help pages describe the different compontents with the intention of making an HTML- or JSON- fluent user able to create and share a full new downloader on their own.
|
||||
|
||||
As always, this is all under active development. Your feedback on the system would be appreciated, and if something is confusing or you discover something in here that is out of date, please [let me know](contact.html).
|
||||
As always, this is all under active development. Your feedback on the system would be appreciated, and if something is confusing or you discover something in here that is out of date, please [let me know](contact.md).
|
||||
|
||||
## what is a downloader? { id="downloader" }
|
||||
|
||||
|
|
@ -43,8 +43,8 @@ The Gallery Downloader is the most complicated downloader and uses all the possi
|
|||
|
||||
So we have three components:
|
||||
|
||||
* [**Gallery URL Generator (GUG):**](downloader_gugs.html) faces the user and converts text input into initialising Gallery URLs.
|
||||
* [**URL Class:**](downloader_url_classes.html) identifies URLs and informs the client how to deal with them.
|
||||
* [**Parser:**](downloader_parsers.html) converts data from URLs into hydrus-understandable metadata.
|
||||
* [**Gallery URL Generator (GUG):**](downloader_gugs.md) faces the user and converts text input into initialising Gallery URLs.
|
||||
* [**URL Class:**](downloader_url_classes.md) identifies URLs and informs the client how to deal with them.
|
||||
* [**Parser:**](downloader_parsers.md) converts data from URLs into hydrus-understandable metadata.
|
||||
|
||||
URL downloaders and watchers do not need the Gallery URL Generator, as their input _is_ an URL. And simple downloaders also have an explicit 'just download it and parse it with this simple rule' action, so they do not use URL Classes (or even full-fledged Page Parsers) either.
|
||||
|
|
@ -85,7 +85,7 @@ Again: the real problem with downloading is not finding new things, it is keepin
|
|||
|
||||
## subscriptions
|
||||
|
||||
Subscriptions are a way to automatically recheck a good query in future, to keep up with new files. Many users come to use them. When you are comfortable with downloaders and have an idea of what you like, come back and read the subscription help, which is [here](getting_started_subscriptions.html).
|
||||
Subscriptions are a way to automatically recheck a good query in future, to keep up with new files. Many users come to use them. When you are comfortable with downloaders and have an idea of what you like, come back and read the subscription help, which is [here](getting_started_subscriptions.md).
|
||||
|
||||
## other downloading { id="other_downloaders" }
|
||||
|
||||
|
|
|
|||
|
|
@ -30,11 +30,11 @@ When you first boot the client, you will see a blank page. There are no files in
|
|||
|
||||
[](images/import.png)
|
||||
|
||||
The files are being imported into the client's database. [The client discards their filenames.](faq.html#filenames)
|
||||
The files are being imported into the client's database. [The client discards their filenames.](faq.md#filenames)
|
||||
|
||||
Notice your original folder and its files are untouched. You can move the originals somewhere else, delete them, and the client will still return searches fine. In the same way, you can delete from the client, and the original files will remain unchanged--import is a **copy**, not a move, operation. The client performs all its operations on its internal database, which holds copies of the files it imports. If you find yourself enjoying using the client and decide to completely switch over, you can delete the original files you import without worry. You can always export them back again later.
|
||||
|
||||
[FAQ: can the client manage files from their original locations?](faq.html#external_files)
|
||||
[FAQ: can the client manage files from their original locations?](faq.md#external_files)
|
||||
|
||||
Now:
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ I try to release a new version every Wednesday by 8pm EST and write an accompany
|
|||
By default, hydrus stores all its data—options, files, subscriptions, _everything_—entirely inside its own directory. You can extract it to a usb stick, move it from one place to another, have multiple installs for multiple purposes, wrap it all up inside a truecrypt volume, whatever you like. The .exe installer writes some unavoidable uninstall registry stuff to Windows, but the 'installed' client itself will run fine if you manually move it.
|
||||
|
||||
!!! info "For macOS users"
|
||||
The Hydrus App is **non-portable** and puts your database in ~/Library/Hydrus (i.e. /Users/\[You\]/Library/Hydrus). You can update simply by replacing the old App with the new, but if you wish to backup, you should be looking at ~/Library/Hydrus, not the App itself.
|
||||
The Hydrus App is **non-portable** and puts your database in `~/Library/Hydrus` (i.e. `/Users/[You]/Library/Hydrus`). You can update simply by replacing the old App with the new, but if you wish to backup, you should be looking at `~/Library/Hydrus`, not the App itself.
|
||||
|
||||
## running
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ To run the client:
|
|||
|
||||
=== "Linux"
|
||||
|
||||
* Run the 'client' executable in the base directory. You may be able to double-click it, otherwise you are talking './client' from the terminal.
|
||||
* Run the 'client' executable in the base directory. You may be able to double-click it, otherwise you are talking `./client` from the terminal.
|
||||
* If you experience virtual memory crashes, please review [this thorough guide](Fixing_Hydrus_Random_Crashes_Under_Linux.md) by a user.
|
||||
|
||||
## updating
|
||||
|
|
@ -82,7 +82,7 @@ The update process:
|
|||
|
||||
Unless the update specifically disables or reconfigures something, all your files and tags and settings will be remembered after the update.
|
||||
|
||||
Releases typically need to update your database to their version. New releases can retroactively perform older database updates, so if the new version is v255 but your database is on v250, you generally only need to get the v255 release, and it'll do all the intervening v250->v251, v251->v252, etc... update steps in order as soon as you boot it. If you need to update from a release more than, say, ten versions older than current, see below. You might also like to skim the release posts or [changelog](changelog.html) to see what is new.
|
||||
Releases typically need to update your database to their version. New releases can retroactively perform older database updates, so if the new version is v255 but your database is on v250, you generally only need to get the v255 release, and it'll do all the intervening v250->v251, v251->v252, etc... update steps in order as soon as you boot it. If you need to update from a release more than, say, ten versions older than current, see below. You might also like to skim the release posts or [changelog](changelog.md) to see what is new.
|
||||
|
||||
Clients and servers of different versions can usually connect to one another, but from time to time, I make a change to the network protocol, and you will get polite error messages if you try to connect to a newer server with an older client or _vice versa_. There is still no _need_ to update the client--it'll still do local stuff like searching for files completely fine. Read my release posts and judge for yourself what you want to do.
|
||||
|
||||
|
|
@ -138,4 +138,4 @@ By default, hydrus stores all your user data in one location, so backing up is s
|
|||
!!! danger
|
||||
Do not put your live database in a folder that continuously syncs to a cloud backup. Many of these services will interfere with a running client and can cause database corruption. If you still want to use a system like this, either turn the sync off while the client is running, or use the above backup workflows to safely backup your client to a separate folder that syncs to the cloud.
|
||||
|
||||
I recommend you always backup before you update, just in case there is a problem with my code that breaks your database. If that happens, please [contact me](contact.html), describing the problem, and revert to the functioning older version. I'll get on any problems like that immediately.
|
||||
I recommend you always backup before you update, just in case there is a problem with my code that breaks your database. If that happens, please [contact me](contact.md), describing the problem, and revert to the functioning older version. I'll get on any problems like that immediately.
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ There are many ways to export files from the client:
|
|||
|
||||
Just dragging from the thumbnail view will export (copy) all the selected files to wherever you drop them.
|
||||
|
||||
The files will be named by their ugly hexadecimal [hash](faq.html#hashes), which is how they are stored inside the database.
|
||||
The files will be named by their ugly hexadecimal [hash](faq.md#hashes), which is how they are stored inside the database.
|
||||
|
||||
If you use this to open a file inside an image editing program, remember to go 'save as' and give it a new filename! The client does not expect files inside its db directory to change.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: subscriptions
|
|||
|
||||
# getting started with subscriptions
|
||||
|
||||
Do not try to create a subscription until you are comfortable with a normal gallery download page! Go [here](getting_started_downloading.html).
|
||||
Do not try to create a subscription until you are comfortable with a normal gallery download page! Go [here](getting_started_downloading.md).
|
||||
|
||||
Let's say you found an artist you like. You downloaded everything of theirs from some site, but one or two pieces of new work is posted every week. You'd like to keep up with the new stuff, but you don't want to manually make a new download job every week for every single artist you like.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ If any of this is confusing, a simpler guide is [here](https://github.com/Zweiba
|
|||
|
||||
So, you have stored some media in your database. Everything is hashed and cached. You can search by inbox and resolution and size and so on, but if you really want to find what we are looking for, you will have to use _tags_.
|
||||
|
||||
[FAQ: what is a tag?](faq.html#tags)
|
||||
[FAQ: what is a tag?](faq.md#tags)
|
||||
|
||||
Your client starts with one local tags service, called 'my tags', which keeps all of its file->tag mappings in your client's database where only you can see them. It is a good place to practise. So, select a file and press F3:
|
||||
|
||||
|
|
@ -71,7 +71,7 @@ Tag repos store many file->tag relationships. Anyone who has an access key to th
|
|||
|
||||
Anyone can run a tag repository, but it is a bit complicated for new users. I ran a public tag repository for a long time, and now this large central store is run by users. It has over a billion tags and is free to access and contribute to.
|
||||
|
||||
To connect with it, please check [here](access_keys.html). **Please read that page if you want to try out the PTR. It is only appropriate for someone on an SSD!**
|
||||
To connect with it, please check [here](access_keys.md). **Please read that page if you want to try out the PTR. It is only appropriate for someone on an SSD!**
|
||||
|
||||
If you add it, your client will download updates from the repository over time and, usually when it is idle or shutting down, 'process' them into its database until it is fully synchronised. The processing step is CPU and HDD heavy, and you can customise when it happens in _file->options->maintenance and processing_. As the repository synchronises, you should see some new tags appear, particularly on famous files that lots of people have.
|
||||
|
||||
|
|
@ -93,4 +93,4 @@ I recommend you not spam tags to the public tag repo until you get a rough feel
|
|||
|
||||
You can connect to more than one tag repository if you like. When you are in the _manage tags_ dialog, pressing the up or down arrow keys on an empty input switches between your services.
|
||||
|
||||
[FAQ: why can my friend not see what I just uploaded?](faq.html#delays)
|
||||
[FAQ: why can my friend not see what I just uploaded?](faq.md#delays)
|
||||
|
Before Width: | Height: | Size: 33 KiB After Width: | Height: | Size: 33 KiB |
|
Before Width: | Height: | Size: 23 KiB After Width: | Height: | Size: 23 KiB |
|
|
@ -30,4 +30,18 @@ And can be extended to download from more locations using easily shareable user-
|
|||
|
||||
The program's emphasis is on your freedom. There is no DRM, no spying, no censorship. The program never phones home.
|
||||
|
||||
If you would like to try it, I _**strongly**_ recommend you check out the [help and getting started guide](help/index.html). A copy is included with the release as well.
|
||||
If you would like to try it, I _**strongly**_ recommend you check out the [help and getting started guide](introduction.md). A copy is included with the release as well.'
|
||||
|
||||
## Screenshots
|
||||
|
||||
[](images/screenshot_empty.png "An empty page. You can search based on file metadata such as filesize and image resolution, not just tags.")
|
||||
[](images/screenshot_general_search.png "A simple tag search.")
|
||||
[](images/screenshot_desu.png "You can add more tags to specify a search. Also pictured is the media viewer, for viewing media in larger size.")
|
||||
[](images/screenshot_thread_watcher.png "The thread watcher works for 4chan and 8chan.")
|
||||
[](images/screenshot_deviant_art.png "The gallery downloader will search for all the files for a particular artist or tag and download them, parsing tags as it goes.")
|
||||
[](images/screenshot_big_search.png "The client can easily search, display and manage thousands of files.")
|
||||
[](images/screenshot_gunnerkrigg_collect.png "Files can be sorted and collected by their tags.")
|
||||
[](images/screenshot_fullscreen_blame.png "The media viewer can work as a resizable window or completely fullscreen. It is clean and fast.")
|
||||
[](images/screenshot_video.png "Many file formats are supported.")
|
||||
[](images/screenshot_booru.png "You can run your own (simple!) booru")
|
||||
[](images/screenshot_advanced_autocomplete.png "The client can get complicated if you want it to. This screenshot shows a tag sibling, where one tag is immediately swapped with another, and a non-local search, where results that are known but not on the computer are shown.")
|
||||
|
|
@ -34,7 +34,7 @@ None of the above are currently true, but I would love to live in a world where
|
|||
|
||||
I try to side with the person over the authority, the distributed over the centralised. I still use gmail and youtube just like pretty much everyone, but I would rather be using different systems, especially in ten years. No one seemed to be making what I wanted for file management, so I decided to do it myself, and here we are.
|
||||
|
||||
If, after a few months, you find you enjoy the software and would like to further support it, I have set up a simple no-reward patreon, which you can read more about [here](support.html).
|
||||
If, after a few months, you find you enjoy the software and would like to further support it, I have set up a simple no-reward patreon, which you can read more about [here](support.md).
|
||||
|
||||
## license
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Which gives you a full listing of all below arguments, however this will not wor
|
|||
|
||||
##**`-d DB_DIR, --db_dir DB_DIR`**
|
||||
|
||||
Lets you customise where hydrus should use for its base database directory. This is install_dir/db by default, but many advanced deployments will move this around, as described [here](database_migration.html). When an argument takes a complicated value like a path that could itself include whitespace, you should wrap it in quote marks, like this:
|
||||
Lets you customise where hydrus should use for its base database directory. This is install_dir/db by default, but many advanced deployments will move this around, as described [here](database_migration.md). When an argument takes a complicated value like a path that could itself include whitespace, you should wrap it in quote marks, like this:
|
||||
|
||||
```
|
||||
-d="E:\\my hydrus\\hydrus db"
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
# local booru
|
||||
|
||||
!!! warning
|
||||
This was a fun project, but it never advanced beyond a prototype. The future of this system is other people's nice applications plugging into the [Client API](client_api.html).
|
||||
This was a fun project, but it never advanced beyond a prototype. The future of this system is other people's nice applications plugging into the [Client API](client_api.md).
|
||||
|
||||
The hydrus client has a simple booru to help you share your files with others over the internet.
|
||||
|
||||
|
|
@ -61,4 +61,4 @@ You can review all your shares on _services->review services_, under _local->boo
|
|||
|
||||
## future plans { id="future" }
|
||||
|
||||
This was a fun project, but it never advanced beyond a prototype. The future of this system is other people's nice applications plugging into the [Client API](client_api.html).
|
||||
This was a fun project, but it never advanced beyond a prototype. The future of this system is other people's nice applications plugging into the [Client API](client_api.md).
|
||||
|
|
@ -45,4 +45,4 @@ You can generate a profile by hitting _help->debug->profile mode_, which tells t
|
|||
|
||||
Turn on profile mode, do the thing that runs slow for you (importing a file, fetching some tags, whatever), and then check your database folder (most likely _install_dir/db_) for a new 'client profile - DATE.log' file. This file will be filled with several sets of tables with timing information. Please send that whole file to me, or if it is too large, cut what seems important. It should not contain any personal information, but feel free to look through it.
|
||||
|
||||
There are several ways to [contact me](contact.html).
|
||||
There are several ways to [contact me](contact.md).
|
||||
|
|
@ -1,94 +1,119 @@
|
|||
<html>
|
||||
<head>
|
||||
<title>tagging schema</title>
|
||||
<link href="hydrus.ico" rel="shortcut icon" />
|
||||
<link href="style.css" rel="stylesheet" type="text/css" />
|
||||
</head>
|
||||
<body>
|
||||
<div class="content">
|
||||
<p class="warning">This document was originally written for when I ran the Public Tag Repository. This is now run by users, so I am no longer an authority for it. I am briefly editing the page and leaving it as a record for some of my thoughts on tagging if you are interested. You can, of course, run your own tag repositories and do your own thing additionally or instead.</p>
|
||||
<p class="warning">A newer guide and schema for the PTR is <a href="https://github.com/Zweibach/text/blob/master/Hydrus/PTR.md">here</a>.</p>
|
||||
<h3 id="intro"><a href="#intro">seriousness of schema</a></h3>
|
||||
<p>This is not all that important; it just makes searches and cooperation easier if most of us can mostly follow some guidelines.</p>
|
||||
<p>We will never be able to easily and perfectly categorise every single image to everyone's satisfaction, so there is no point defining every possible rule for every possible situation. If you do something that doesn't fit, fixing mistakes is not difficult.</p>
|
||||
<p>If you are still not confident, just lurk for a bit. See how other people have tagged the popular images and do more of that.</p>
|
||||
<h3 id="take_it_easy"><a href="#take_it_easy">you can add pretty much whatever the hell you want, but don't screw around</a></h3>
|
||||
<p>The most important thing is: <b>if your tag is your opinion, don't add it</b>. 'beautiful' is an unhelpful tag because no one can agree on what it means. 'lingerie', 'blue eyes', and 'male' or 'female' are better since reasonable people can generally agree on what they mean. If someone thinks blue-eyed women are beautiful, they can search for that to find beautiful things.</p>
|
||||
<p>You can start your own namespaces, categorisation systems, whatever. Just be aware that everyone else will see what you do.</p>
|
||||
<p>If you are still unsure about the difference between objective and subjective, here's some more examples:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<p>objective tags: (add these!)</p>
|
||||
<ul>
|
||||
<li>firetruck</li>
|
||||
<li>hors d'œuvre</li>
|
||||
<li>high heels</li>
|
||||
<li>character:jean-luc picard</li>
|
||||
<li>person:okita anri</li>
|
||||
<li>title:the tragical history of hamlet, prince of denmark</li>
|
||||
<li>page:17</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<p>subjective tags: (don't add these!)</p>
|
||||
<ul>
|
||||
<li>awesome</li>
|
||||
<li>faggot level:super-gay<li>
|
||||
<li>4 stars</li>
|
||||
<li>this is boring, why did anyone upload this here</li>
|
||||
<li>moran communist and ONE TERM PRESIDENT!!! SARAH PALIN 2012! FOR JESUS CHRIST</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<p>Of course, if you are tagging a picture of someone holding a sign that says 'beautiful', you can bend the rules. Otherwise, please keep your opinions to yourself!</p>
|
||||
<h3 id="numbers"><a href="#numbers">numbers</a></h3>
|
||||
<p>Numbers should be written '22', '1457 ce', and 'page:3', unless as part of an official title like 'ocean's eleven'. When the client parses and sorts numbers, it does so intelligently, so just use '1' where you might before have done '01' or '001'. I know it looks ugly sometimes to have '2 girls' or '1 cup', but the rules for writing numbers out in full are hazy for special cases.</p>
|
||||
<p>(Numbers written as 123 are also readable by many different language-speakers, while 'tano', 'deux' and 'seven' are not.)</p>
|
||||
<h3 id="plurals"><a href="#plurals">plurals</a></h3>
|
||||
<p>Nouns should generally be singular, not plural. 'chair' instead of 'chairs', 'cat' instead of 'cats', even if there are several of the thing in the image. If there really are <i>many</i> of the thing in the image, add a seperate 'multiple' or 'lineup' tag as apppropriate.</p>
|
||||
<p>Ignore this when the thing is normally said in its plural (usually paired) form. Say 'blue eyes', not 'blue eye'; 'breasts', not 'breast', even if only one is pictured.</p>
|
||||
<h3 id="synonyms"><a href="#synonyms">acronyms and synonyms</a></h3>
|
||||
<p>I personally prefer the full 'series:the lord of the rings' rather than 'lotr'. If you are an advanced user, please help out with tag siblings to help induce this.</p>
|
||||
<h3 id="namespace_disambiguation"><a href="#namespace_disambiguation">character:anna (frozen)</a></h3>
|
||||
<p>I am not fond of putting a series name after a character because it looks unusual and is applied unreliably. It is done to separate same-named characters from each other (particularly when they have no canon surname), which is useful in places that search slowly, have thin tag areas on their web pages, or usually only deal in single-tag searches. For archival purposes, I generally prefer that namespaces are stored as the namespace and nowhere else. 'series:harry potter' and 'character:harry potter', not 'harry potter (harry potter)'. Some sites even say things like 'anna (disney)'. It isn't a big deal, but if you are adding a sibling to collapse these divergent tags into the 'proper' one, I'd prefer it all went to the simple and reliable 'character:anna'. Even better would be migrating towards a canon-ok unique name, like 'character:princess anna of arendelle', which could have the parent 'series:frozen'.</p>
|
||||
<p>Including nicknames, like 'character:angela "mercy" ziegler' can be useful to establish uniqueness, but are not mandatory. 'character:harleen "harley quinn" frances quinzel' is probably overboard.</p>
|
||||
<h3 id="protip"><a href="#protip">protip: rein in your spergitude</a></h3>
|
||||
<p>In developing hydrus, I have discovered two rules to happy tagging:</p>
|
||||
<ol>
|
||||
<li>Don't try to be perfect.</li>
|
||||
<li>Only add those tags you actually use in searches.</li>
|
||||
</ol>
|
||||
<p>Tagging can be fun, but it can also be complicated, and the problem space is gigantic. There is always works to do, and it is easy to exhaust onesself or get lost in the bushes agonising over whether to use 'smile' or 'smiling' or 'smirk' or one of a million other split hairs. Problems are easy to fix, and this marathon will never finish, so do not try to sprint. The ride never ends.</p>
|
||||
<p>The sheer number of tags can also be overwhelming. Importing all the many tags from the boorus is totally fine, but if you are typing tags yourself, I suggest you try not to exhaustively tag <a href="http://safebooru.org/index.php?page=post&s=list&tags=card_on_necklace">everything</a> <a href="http://gelbooru.com/index.php?page=post&s=list&tags=collarbone">in</a> <a href="https://e621.net/post/index?tags=cum_on_neck">the</a> <a href="http://danbooru.donmai.us/posts?tags=brown_vest">image</a>. You will save a lot of time and ultimately be much happier with your work. Anyone can see what is in an image just by looking at it--tags are primarily for finding things. Character, series and creator namespaces are a great place to start. After that, add what you are interested in, be that 'blue sky' or 'midriff'.</p>
|
||||
<h3 id="presentation"><a href="#presentation">newer thoughts on presentation preferences</a></h3>
|
||||
<p>Since developing and receiving feedback for the siblings system, and then in dealing with siblings with the PTR, I have come to believe that the most difficult disagreement to resolve in tagging is not in what is in an image, but how those tags should present. It is easy to agree that an image contains a 'bikini', but should that show as 'bikini' or 'clothing:bikini' or 'general:bikini' or 'swimwear:bikini'? Which is better?</p>
|
||||
<p>This is impossible to answer definitively. There is no perfect dictionary that satisfies everyone, and opinions are fairly fixed. My intentions for future versions of the sibling and tag systems is to allow users to broadly tell the client some display rules such as 'Whenever you have a clothing: tag, display it as unnamespaced' and eventually more sophisticated ones like 'I prefer slang, so show pussy instead of vagina'.</p>
|
||||
<h3 id="siblings_and_parents"><a href="#siblings_and_parents">siblings and parents</a></h3>
|
||||
<p>Please do add <a href="advanced_siblings.html">siblings</a> and <a href="advanced_parents.html">parents</a>! If it is something not obvious, please explain the relationship in your submitted reason. If it <i>is</i> something obvious (e.g. 'wings' is a parent of 'angel wings'), don't bother to put a reason in; I'll just approve it.</p>
|
||||
<p>My general thoughts:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<h3 id="siblings"><a href="#siblings">siblings</a></h3>
|
||||
<p>In general, the correctness of a thing is in how it would describe itself, or how its creator would describe it.</p>
|
||||
<p>For shorthand, I will say 'a'->'b' to mean 'a' is replaced by 'b'.</p>
|
||||
<p>For instance, japanese names are usually written surname first and western forename first, so let's go 'character:rei ayanami'->'character:ayanami rei' but leave 'person:emma watson' and other western names as they are.</p>
|
||||
<p>Unless it is too obscure, replace the english version of a word with any more proper or original foreign name. But stick to something a westerner can read. Do things like 'series:the melancholy of haruhi suzumiya'->'series:haruhi suzumiya no yuuutsu' or 'series:princess mononoke'->'series:mononoke hime'. There's even an argument for things like 'series:harry potter and the sorcerer's stone'->'series:harry potter and the philosopher's stone'.</p>
|
||||
<p>Accents and other unusual/unicode characters are great in tags if they reflect the official marketed name, and should be preferred, but make sure there's an ascii->unicode sibling to make it easy for most users to type. 'series:pokemon'->'series:pok<6F>mon' is excellent, as it both reflects official branding and also helps anyone who can't easily produce '<27>' on their keyboard find it.</p>
|
||||
<p>I don't care about popularity as much as accuracy. Given 'series:pretty cure' and 'series:precure', I would prefer 'series:pretty cure' because it is the 'full and proper' rendering, even though there are more instances of 'precure' on the boorus.</p>
|
||||
<p>Do correct for common plural mistakes. ear->ears, women->female, and so on.</p>
|
||||
<p>And feel free to replace any 'character (series)' booru artifacts as with the 'anna (frozen)' example above. 'character:anna (frozen)'->'character:princess anna of arendelle' is great wherever it makes sense.</p>
|
||||
<p>But please <b>do not</b> go 'blah'->'character:blah' unless the name is popular and unique. No one is going to be confused by 'ayanami rei'->'character:ayanami rei', but going 'archer'->'<a href="http://typemoon.wikia.com/wiki/Archer_%28Fate/stay_night%29">character:archer</a>' is going to create a lot of false positives. There's a similar problem with something like 'character:mercy'->'character:angela "mercy" ziegler'--although the left hand side is namespaced, there are still plenty of <i>characters</i> named 'mercy', so a sibling that converts all Mercys to Overwatch's Mercy is not appropriate.</p>
|
||||
<p>If the character name is the same as the series name, make the unnamespaced version go to the series version. For instance, set 'harry potter'->'series:harry potter', since we don't know which one it is and 'character:harry potter' ⊂ 'series:harry potter'. (If a <a href="https://danbooru.donmai.us/posts/1899356">picture of just Hermione</a> that for some reason was not providing namespace information had 'hermione granger' (the character) and 'harry potter' (the series), we wouldn't want to infer 'character:harry potter' by accident.</p>
|
||||
<p>In general, swap out slang for proper terms. 'lube'->'lubricant', 'series:zelda'->'series:the legend of zelda'.</p>
|
||||
</li>
|
||||
<li>
|
||||
<h3 id="parents"><a href="#parents">parents</a></h3>
|
||||
<p>Be shy about adding character:blah->series:whatever unless you are certain the character name is unique. 'character:harry potter'->'series:harry potter' seems fairly uncontroversial, for instance, but adding specific sub-series just to be completionist, such as 'character:miranda lawson->series:mass effect: redemption' is asking for trouble.</p>
|
||||
<p>Remember that parents define a relationship that is always true. Don't add 'blonde hair' to 'character:elsa', even though it is true in most files--add 'animal ears' to 'cat ears', as cat ears are always animal ears, no matter what an artist can think up.</p>
|
||||
<p>Also, tag parents are only worth something if the parent is useful for searching. Adding 'medium:blue background'->'blue' isn't useful since 'blue' itself is not very valuable, but 'fishnet stockings'->'stockings' is useful as both tags are common and used in searches by plenty of people.</p>
|
||||
<p>You can create a complicated tree like the firearms diagram on my parents page, but if it only adds seven tags that you probably wouldn't ever use yourself, you probably wasted your time.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
<html>
|
||||
<head>
|
||||
<title>tagging schema</title>
|
||||
<style>
|
||||
a { color: #222; text-decoration: none; font-weight: bold; }
|
||||
a:hover { color: #555 }
|
||||
body { font-family: "Calibri", Arial, sans-serif; color: #555; line-height: 1.5; }
|
||||
h3 { color: #222; }
|
||||
ul li { list-style: none; margin: 1.0em 0em; }
|
||||
ul.bulletpoint li { list-style: disc; margin: 1.0em 0em; }
|
||||
th { text-align: center; }
|
||||
tr { text-align: center; }
|
||||
|
||||
.de { color: #d00 }
|
||||
.su { color: #0d0 }
|
||||
.dealwithit { color: #ff0000; text-shadow:
|
||||
1px 1px 0 #ff7f00,
|
||||
2px 2px 0 #ffff00,
|
||||
3px 3px 0 #00ff00,
|
||||
4px 4px 0 #0000ff,
|
||||
5px 5px 0 #6600ff,
|
||||
6px 6px 0 #8b00ff; }
|
||||
.warning { color: #d00 }
|
||||
.warning a { color: #00d }
|
||||
.apiborder { border-left: 5px; border-left-color: #333377; border-style: hidden hidden hidden solid; padding: 0.5em; margin: 1.0em; }
|
||||
.lololol { text-decoration: line-through; }
|
||||
.right { text-align: right; }
|
||||
.screenshot { float: right; clear: both; margin: 10px; }
|
||||
.spoiler:not(:hover) { color: #000; background-color: #000 }
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="content">
|
||||
<p class="warning">This document was originally written for when I ran the Public Tag Repository. This is now run by users, so I am no longer an authority for it. I am briefly editing the page and leaving it as a record for some of my thoughts on tagging if you are interested. You can, of course, run your own tag repositories and do your own thing additionally or instead.</p>
|
||||
<p class="warning">A newer guide and schema for the PTR is <a href="https://github.com/Zweibach/text/blob/master/Hydrus/PTR.md">here</a>.</p>
|
||||
<h3 id="intro"><a href="#intro">seriousness of schema</a></h3>
|
||||
<p>This is not all that important; it just makes searches and cooperation easier if most of us can mostly follow some guidelines.</p>
|
||||
<p>We will never be able to easily and perfectly categorise every single image to everyone's satisfaction, so there is no point defining every possible rule for every possible situation. If you do something that doesn't fit, fixing mistakes is not difficult.</p>
|
||||
<p>If you are still not confident, just lurk for a bit. See how other people have tagged the popular images and do more of that.</p>
|
||||
<h3 id="take_it_easy"><a href="#take_it_easy">you can add pretty much whatever the hell you want, but don't screw around</a></h3>
|
||||
<p>The most important thing is: <b>if your tag is your opinion, don't add it</b>. 'beautiful' is an unhelpful tag because no one can agree on what it means. 'lingerie', 'blue eyes', and 'male' or 'female' are better since reasonable people can generally agree on what they mean. If someone thinks blue-eyed women are beautiful, they can search for that to find beautiful things.</p>
|
||||
<p>You can start your own namespaces, categorisation systems, whatever. Just be aware that everyone else will see what you do.</p>
|
||||
<p>If you are still unsure about the difference between objective and subjective, here's some more examples:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<p>objective tags: (add these!)</p>
|
||||
<ul>
|
||||
<li>firetruck</li>
|
||||
<li>hors d'œuvre</li>
|
||||
<li>high heels</li>
|
||||
<li>character:jean-luc picard</li>
|
||||
<li>person:okita anri</li>
|
||||
<li>title:the tragical history of hamlet, prince of denmark</li>
|
||||
<li>page:17</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<p>subjective tags: (don't add these!)</p>
|
||||
<ul>
|
||||
<li>awesome</li>
|
||||
<li>faggot level:super-gay<li>
|
||||
<li>4 stars</li>
|
||||
<li>this is boring, why did anyone upload this here</li>
|
||||
<li>moran communist and ONE TERM PRESIDENT!!! SARAH PALIN 2012! FOR JESUS CHRIST</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<p>Of course, if you are tagging a picture of someone holding a sign that says 'beautiful', you can bend the rules. Otherwise, please keep your opinions to yourself!</p>
|
||||
<h3 id="numbers"><a href="#numbers">numbers</a></h3>
|
||||
<p>Numbers should be written '22', '1457 ce', and 'page:3', unless as part of an official title like 'ocean's eleven'. When the client parses and sorts numbers, it does so intelligently, so just use '1' where you might before have done '01' or '001'. I know it looks ugly sometimes to have '2 girls' or '1 cup', but the rules for writing numbers out in full are hazy for special cases.</p>
|
||||
<p>(Numbers written as 123 are also readable by many different language-speakers, while 'tano', 'deux' and 'seven' are not.)</p>
|
||||
<h3 id="plurals"><a href="#plurals">plurals</a></h3>
|
||||
<p>Nouns should generally be singular, not plural. 'chair' instead of 'chairs', 'cat' instead of 'cats', even if there are several of the thing in the image. If there really are <i>many</i> of the thing in the image, add a seperate 'multiple' or 'lineup' tag as apppropriate.</p>
|
||||
<p>Ignore this when the thing is normally said in its plural (usually paired) form. Say 'blue eyes', not 'blue eye'; 'breasts', not 'breast', even if only one is pictured.</p>
|
||||
<h3 id="synonyms"><a href="#synonyms">acronyms and synonyms</a></h3>
|
||||
<p>I personally prefer the full 'series:the lord of the rings' rather than 'lotr'. If you are an advanced user, please help out with tag siblings to help induce this.</p>
|
||||
<h3 id="namespace_disambiguation"><a href="#namespace_disambiguation">character:anna (frozen)</a></h3>
|
||||
<p>I am not fond of putting a series name after a character because it looks unusual and is applied unreliably. It is done to separate same-named characters from each other (particularly when they have no canon surname), which is useful in places that search slowly, have thin tag areas on their web pages, or usually only deal in single-tag searches. For archival purposes, I generally prefer that namespaces are stored as the namespace and nowhere else. 'series:harry potter' and 'character:harry potter', not 'harry potter (harry potter)'. Some sites even say things like 'anna (disney)'. It isn't a big deal, but if you are adding a sibling to collapse these divergent tags into the 'proper' one, I'd prefer it all went to the simple and reliable 'character:anna'. Even better would be migrating towards a canon-ok unique name, like 'character:princess anna of arendelle', which could have the parent 'series:frozen'.</p>
|
||||
<p>Including nicknames, like 'character:angela "mercy" ziegler' can be useful to establish uniqueness, but are not mandatory. 'character:harleen "harley quinn" frances quinzel' is probably overboard.</p>
|
||||
<h3 id="protip"><a href="#protip">protip: rein in your spergitude</a></h3>
|
||||
<p>In developing hydrus, I have discovered two rules to happy tagging:</p>
|
||||
<ol>
|
||||
<li>Don't try to be perfect.</li>
|
||||
<li>Only add those tags you actually use in searches.</li>
|
||||
</ol>
|
||||
<p>Tagging can be fun, but it can also be complicated, and the problem space is gigantic. There is always works to do, and it is easy to exhaust onesself or get lost in the bushes agonising over whether to use 'smile' or 'smiling' or 'smirk' or one of a million other split hairs. Problems are easy to fix, and this marathon will never finish, so do not try to sprint. The ride never ends.</p>
|
||||
<p>The sheer number of tags can also be overwhelming. Importing all the many tags from the boorus is totally fine, but if you are typing tags yourself, I suggest you try not to exhaustively tag <a href="http://safebooru.org/index.php?page=post&s=list&tags=card_on_necklace">everything</a> <a href="http://gelbooru.com/index.php?page=post&s=list&tags=collarbone">in</a> <a href="https://e621.net/post/index?tags=cum_on_neck">the</a> <a href="http://danbooru.donmai.us/posts?tags=brown_vest">image</a>. You will save a lot of time and ultimately be much happier with your work. Anyone can see what is in an image just by looking at it--tags are primarily for finding things. Character, series and creator namespaces are a great place to start. After that, add what you are interested in, be that 'blue sky' or 'midriff'.</p>
|
||||
<h3 id="presentation"><a href="#presentation">newer thoughts on presentation preferences</a></h3>
|
||||
<p>Since developing and receiving feedback for the siblings system, and then in dealing with siblings with the PTR, I have come to believe that the most difficult disagreement to resolve in tagging is not in what is in an image, but how those tags should present. It is easy to agree that an image contains a 'bikini', but should that show as 'bikini' or 'clothing:bikini' or 'general:bikini' or 'swimwear:bikini'? Which is better?</p>
|
||||
<p>This is impossible to answer definitively. There is no perfect dictionary that satisfies everyone, and opinions are fairly fixed. My intentions for future versions of the sibling and tag systems is to allow users to broadly tell the client some display rules such as 'Whenever you have a clothing: tag, display it as unnamespaced' and eventually more sophisticated ones like 'I prefer slang, so show pussy instead of vagina'.</p>
|
||||
<h3 id="siblings_and_parents"><a href="#siblings_and_parents">siblings and parents</a></h3>
|
||||
<p>Please do add <a href="advanced_siblings.html">siblings</a> and <a href="advanced_parents.html">parents</a>! If it is something not obvious, please explain the relationship in your submitted reason. If it <i>is</i> something obvious (e.g. 'wings' is a parent of 'angel wings'), don't bother to put a reason in; I'll just approve it.</p>
|
||||
<p>My general thoughts:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<h3 id="siblings"><a href="#siblings">siblings</a></h3>
|
||||
<p>In general, the correctness of a thing is in how it would describe itself, or how its creator would describe it.</p>
|
||||
<p>For shorthand, I will say 'a'->'b' to mean 'a' is replaced by 'b'.</p>
|
||||
<p>For instance, japanese names are usually written surname first and western forename first, so let's go 'character:rei ayanami'->'character:ayanami rei' but leave 'person:emma watson' and other western names as they are.</p>
|
||||
<p>Unless it is too obscure, replace the english version of a word with any more proper or original foreign name. But stick to something a westerner can read. Do things like 'series:the melancholy of haruhi suzumiya'->'series:haruhi suzumiya no yuuutsu' or 'series:princess mononoke'->'series:mononoke hime'. There's even an argument for things like 'series:harry potter and the sorcerer's stone'->'series:harry potter and the philosopher's stone'.</p>
|
||||
<p>Accents and other unusual/unicode characters are great in tags if they reflect the official marketed name, and should be preferred, but make sure there's an ascii->unicode sibling to make it easy for most users to type. 'series:pokemon'->'series:pok<6F>mon' is excellent, as it both reflects official branding and also helps anyone who can't easily produce '<27>' on their keyboard find it.</p>
|
||||
<p>I don't care about popularity as much as accuracy. Given 'series:pretty cure' and 'series:precure', I would prefer 'series:pretty cure' because it is the 'full and proper' rendering, even though there are more instances of 'precure' on the boorus.</p>
|
||||
<p>Do correct for common plural mistakes. ear->ears, women->female, and so on.</p>
|
||||
<p>And feel free to replace any 'character (series)' booru artifacts as with the 'anna (frozen)' example above. 'character:anna (frozen)'->'character:princess anna of arendelle' is great wherever it makes sense.</p>
|
||||
<p>But please <b>do not</b> go 'blah'->'character:blah' unless the name is popular and unique. No one is going to be confused by 'ayanami rei'->'character:ayanami rei', but going 'archer'->'<a href="http://typemoon.wikia.com/wiki/Archer_%28Fate/stay_night%29">character:archer</a>' is going to create a lot of false positives. There's a similar problem with something like 'character:mercy'->'character:angela "mercy" ziegler'--although the left hand side is namespaced, there are still plenty of <i>characters</i> named 'mercy', so a sibling that converts all Mercys to Overwatch's Mercy is not appropriate.</p>
|
||||
<p>If the character name is the same as the series name, make the unnamespaced version go to the series version. For instance, set 'harry potter'->'series:harry potter', since we don't know which one it is and 'character:harry potter' ⊂ 'series:harry potter'. (If a <a href="https://danbooru.donmai.us/posts/1899356">picture of just Hermione</a> that for some reason was not providing namespace information had 'hermione granger' (the character) and 'harry potter' (the series), we wouldn't want to infer 'character:harry potter' by accident.</p>
|
||||
<p>In general, swap out slang for proper terms. 'lube'->'lubricant', 'series:zelda'->'series:the legend of zelda'.</p>
|
||||
</li>
|
||||
<li>
|
||||
<h3 id="parents"><a href="#parents">parents</a></h3>
|
||||
<p>Be shy about adding character:blah->series:whatever unless you are certain the character name is unique. 'character:harry potter'->'series:harry potter' seems fairly uncontroversial, for instance, but adding specific sub-series just to be completionist, such as 'character:miranda lawson->series:mass effect: redemption' is asking for trouble.</p>
|
||||
<p>Remember that parents define a relationship that is always true. Don't add 'blonde hair' to 'character:elsa', even though it is true in most files--add 'animal ears' to 'cat ears', as cat ears are always animal ears, no matter what an artist can think up.</p>
|
||||
<p>Also, tag parents are only worth something if the parent is useful for searching. Adding 'medium:blue background'->'blue' isn't useful since 'blue' itself is not very valuable, but 'fishnet stockings'->'stockings' is useful as both tags are common and used in searches by plenty of people.</p>
|
||||
<p>You can create a complicated tree like the firearms diagram on my parents page, but if it only adds seven tags that you probably wouldn't ever use yourself, you probably wasted your time.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
Loading…
Reference in New Issue