Allow specifying an alternate name for an artist to be used for a single album/song.

We could allow selecting one of the aliases, but what happens if the alias is deleted and replaced?

Alternatively, if the name is saved for the album/song link, then if the same name is used for multiple albums/songs, and the name needs to be changed, all these names would have to be changed separately.

The third option is to allow multiple "primary" names for an artist. This would be the most complicated option, but it would also allow translations.

Sometimes it would be better to hide individual producers or voicebank variations from artist string, even if they're still credited normally.

Could also be a dropdown with 3 options: Default, Always hide, Always show.

Related to #77

For songs we usually want to credit individuals, but the artist might still appear under their group name in the artist string. For example, 1640mP.

Similarly for albums, we want to add both producers and the group/circle to album, but the artist string should only contain the group name. "XenonP, XM feat. various" doesn't sound right.

UtaiteDB has solved this by "abusing" the support status: the name appearing in the artist string is chosen by marking other artists as support.

We should come up with a better solution for this. As a suggestion, allow editors to select the artist to be credited under their group name instead of individuals. If the entry already includes the group name, only that will be shown and the producer name is hidden from artist string. For example, if the song is credited for 40mP, 164 and 1640mP, and both 40mP and 164 are selected to be credited under their group name 1640mP, then only 1640mP would appear in the artist string.

It should be noted that the artists may belong to multiple groups, so a boolean switch is not enough.

Would it be possible to automate this with conventions? It would potentially save the editors a lot of work. If both the artist and their group are added, only the group is listed in artist string. The artist is still credited in the entry details, as "artist (credited as group)", for example "XenonP (credited as XM)". Is there any case where we would want both the producer and group appearing in the artist string for the same entry?

This is similar to #68, with the difference that the displayed name is artist's group instead of one of the aliases.

Most tags have usage notes. Separating usage notes from description encourages writing both, and the title can clearly be translated.

How should usage notes be translated? The purpose of description and usage notes is different.

Currently there is an exclamation mark in the "Account" button and a report count in the "Entry reports" menu item as long as there's non-zero amount of open reports globally.

However what if these are all reports that a user can't or doesn't want to act on. In this case it would be nice to click a button such as "Mark all as read" and have the notification go away, until more reports arrive and need to be checked out.

As currently the ever-present exclamation mark doesn't play its role in notifying to re-check the reports section, as you never know if there is something new, or it's just the old ones you've already seen.

Default should still inherit category from series. There are exceptions, for example, Magical Mirai 2017 Song Contest

Currently, a user is only able to select one service under My settings > Interface > Preferred streaming service.

If

• I select "YouTube" (because I like Google's speed)
• but also prefer only audio (piapro, SoundCloud, etc.)
• and don't like NND (for various reasons)

and

• An entry has only
• 1. NND and
• 2. bilibili and
• 2. piapro

VocaDB will choose NND for me. It would be nice if a user could create a list of fallbacks instead.

UTAU voicebanks tend to have more appends/variations than Vocaloid banks, and the differences are often relatively minor. Creating artist entries for all those appends would be too complex to manage.

One suggestion was to add "appends" tab for UTAU entries where these appends would be listed, together with descriptions and possibly pictures and links. The problem with this suggestion is making the searches and translations work for these alternate voicebanks.

Number of artists, albums, songs, tags etc.

Possible other random statistics such as total number of edits.

Currently we're linking to account settings, but there should be a link that directly takes the user to a page where they can easily unsubscribe to from the type of email they're getting. This requires some sort of security mechanism, there needs to be at least some unique token.

Currently only last 3 are shown

Comments of a specific entry or discussion thread. Get email notification when a message is posted. Automatically offer subscription when posting.

Some frequent problems and misunderstandings happen due to mistakes in song creation (verbatim from @riipah):

• Songs missing producers or Vocaloids (there is a warning for this)
• Wrong Romanization (usually Romanizing loanwords - this should be more clearly on the edit page)
• Cover/remix is missing mention of original (there is warning for this)
• Unnecessary text in the title (usually this happens if the Nico title doesn't follow the common format and can't be automatically parsed, some people include "cover" or artists)
• Covers that are added as originals (song type should be cover)

We can help users avoid these issues by changing the form's functionality as described below. The idea is to keep the old form around for experienced users, but make this one the default.

1. A group is available while there is no failure preceding it.
2. Checks are client-side.
3. Greyed out elements show why they are greyed out (icon with hover text).
4. Warning text should look scary

{}      Group (Visually distinct)
[]      Text input
< ()>   Drop-down (default option first, other options follow)
▣ □     Checkbox
◉ ○     Radio
(X)     Group-local selection identifier

*       "On selection of..."
%       "On field focus..."
@       "On form submission..."

!       "Fail while..."
?       "If"
->      "Do"

MSG     Display message
DRF     Force-enable {Draft}
REP     Submit report

{URL}

    [original PV]
    [reprint of the PV]

{Intro}

    ○ "Song has vocaloids singing in it" (A)
    ○ "Song does not have vocaloids singing in it" (B)
        □ "Song is part of an album that contains vocaloid songs"
        □ "Song is the Original to many vocaloid covers"

    /------------
    | * ? (B) -> MSG http://wiki.vocadb.net/wiki/39/vocadb-editing-faq
    | @ ? (B) -> DRF
    | ! (B) is the _only_ selection.
    \------------

{Title}

    <Original Title Language ("Please Select", ..., "Other")> (A)    ( FIXME: Disambiguate "Title". Someone might think "lyrics" )

    ? (A) != "English":
        [Non-English]
        □ "The artist has provided an English translation"      ( Skip if user.knows_language(lang) )
            [English]
        [Romanized]                                             ( Un-grey if user.has_read_romanization_guide )

    ? (A) == "English":
        [English]

    /------------
    | % MSG Short description and wiki URL
    | * ? (A) != "Please select" -> Un-grey the rest of the group
    | * ? BAD_TITLE_PCRE -> MSG
    | @ ? BAD_TITLE_PCRE -> REP, DRF
    | ! All are blank
    \------------

    Example: BAD_TITLE_PCRE = /-P$|\bf(ea)?t[. ]|【|】|\b(cover|remix)\b/

{Producers}

    [Producers]

    /------------
    | % MSG http://wiki.vocadb.net/wiki/21/artist-roles
    | ! No producer added || {Intro} says there are no vocaloids
    \------------

{Vocaloid/UTAU}

    [Vocaloids]    ( Return only humans if {Intro} says there are no vocaloids )

    ▣ "I am not 100% sure about the vocaloid versions used" (A)

    /------------
    | @ ? (A) -> DRF, REP
    | ! No vocalist added
    \------------

{PVs}

    ◉ "A PV is available" (A)
        [Original PV]
        [Reprint PV]
    ○ "No PV is available" (B)

    /------------
    | * ? (B) -> MSG cases where lack of PV is OK
    | @ ? (B) -> DRF, REP
    | ! (A) checked && URL missing / duplicate.
    \------------

{Type}

    <Song Type ("Not sure", ...)> (A)

    ? (A) in ("Cover", "Remix"):
        [Original Song]                                         ( Grey if (B) )
        □ "The original song is out of scope" (B)

    /------------
    | * MSG http://wiki.vocadb.net/wiki/6/song-types
    | ? (A) == "Not sure" || (B) -> DRF, REP
    \------------

{Draft}

    □ Draft

Currently using Mailgun to send emails using the SMTP API, it'd be more efficient to have an implementation using their REST API instead. Should only require implementing IUserMessageMailer interface.

The word "Support" is vague for someone who has not carefully gone through Wiki/Artist Roles. According to that, "Support" means "Vocal Tuning Assistant".

The term "Support" could stay, but if the use-cases are as specific as described above, I think a mouse-over popup over the "Support" checkboxes could help.

For events that happen yearly at the same time. This would be most useful for character anniversaries. Possibility to enter multiple dates might be useful, though not mandatory.

Suggest date for a new event in the series based on the next free date.

Requested.

Voicebanks that are sold/distributed together. For example Rin/Len, also some UTAU.

• Should this include appends/voicebank variations?
• What about multiple different bundles (Miku V3 can be bought with and without the English voicebank)?

Would be useful for VocaVerse.

The main problem is that the current embeddable player contains nested iframes. First the VocaDB player is embedded, and inside that another embed. The reason for this is server-side switching of PVs. This should probably be replaced with JavaScript implementation.

Currently indicated with tags. For example Kyary Pamyu Pamyu. An artist link could be more appropriate, but a new role is needed.

Benefits:

• Artist type can be specified
• Artist can be tagged

Drawbacks:

• Need to customize roles

Only if the actual tags are not already suggested.

VocaDB routing supports "friendly" URLs with entry title in the URL, for example http://vocadb.net/S/18410/gift-nor-art. There's even code for generating these URLs based on entry names (EntryUrlFriendlyNameFactory). What needs to be resolved is to make sure these URLs are used everywhere. Those URLs should also be saved to the database or at least cached, to avoid affecting performance too much.

Advertisements etc.

When the series is (almost) always held at a specific location. For example, Pixiv Apollo and Nico Nico Chokaigi. Can be overridden by events.

Another issue raised by @riipah.

The textarea in entry-edit-description could have a placeholder such as

This doesn't help when something has been already written in the Description field, but is more likely to be noticed otherwise.

Like the musical compatibility on last.fm

Having wiki links on song/artist/album edit views would help reducing some common mistakes, such as those related to romanization. This would also make the wiki pages more known and in turn, could make the wiki pages more detailed.

These links could be embedded (hidden) into existing ".editor-label"s on the edit pages, and on click, they would open the wiki page as a new tab. For labels that have help tips (dash underlines), the link text could be added to the hover popup box. I'm not sure how to handle the cursor value in this case (help or pointer type).

Romanized - wiki/1/romanization-guidelines (on all edit pages)
External links - wiki/5/external-links (on all edit pages)

Release event - wiki/36/events (albums/songs)
Artist tab -> roles wiki/21/artist-roles (albums/songs)
Artist tab -> support wiki/21/artist-roles#Support-status (albums/songs)

Song type - wiki/6/song-types (songs)
Media tab -> Type wiki/32/pv-types (songs)

Artist type - wiki/23/artist-types (artists)
Main picture - wiki/41/choosing-the-main-picture-for-artist-entries (artists)

Record type - wiki/8/album-types-and-artist-participation (albums)

Additionally, wiki pages such as merging-entries and
search-terms-cheat-sheet could be added to their respective pages.

Admin function for privacy when requested by artist or another party with authority.

Need to delete the image from the database and thumbnails from the disk.

Current workaround is uploading an empty image and hiding revisions with the previous image, which is acceptable if the situation is rare.

At least for those hosted on VocaDB (localfile). Maybe for piapro as well.

Requested by user.

For the voicebank anniversaries ("birthdays"), and other related events. It should be possible to associate more than one vocalist to a single event (many to many).

For example, Miku's birthday and Kaito paradise.

Similar to marketplaces on Discogs and MyFigureCollection. Users could offer their albums for sale or request an album to be bought.

• Price (optional)
• Shipping method
• Condition (new/used)

From http://vocadb.net/discussion/topics/19

If the user is looking to buy the album but there are no purchase links, they can subscribe to be notified when a store link is added.

Cover version is generally made by an artist other than the original. The term "cover" has strong association with "not my work". In the Vocaloid/UTAU world, it is common that the artist remakes their own songs with new voicebanks. In this case the term self-cover (セルフカバー on NicoNicoDouga) is used. Because it's a derived version and thus cannot be classified as "original version", the song type is "cover", but this offends some artists who don't want to be labeled as makers of cover songs.

If this really becomes a problem, we may need to add a new song type for self-covers. Most likely the new song type would be called "self-cover".

Probably only shown on voicebank page?

Is there enough benefit to this considering the role would need to be clarified in description anyway?

If we decide to keep the artbooks, it would be useful to be able to connect characters featured in the artbooks with the "subject" role.

• Should this role only apply to artbooks? It would be useful for animation PVs as well.
• Should this be the default role for Vocaloids in artbooks? Currently it's not possible to customize the roles for Vocaloids. Do we need other roles?
• Could the subject role be used for character designs as well, for example Hagane Miku? See VocaDB/vocadb#1341.

User request:

Old conversation, but I just accidentally added a duplicate entry because of this problem.

For example, when someone

searches for "後面" ("behind" in trad. Chinese), the search engine will also look for "后面"
後 ("back")'s simplified form is 后
searches for "王后" ("queen" in both simp. and trad. Chinese), the search engine will also look for "王後"
後's simplified form is 后
后's traditional form is usually 後
Note that "王後" is not the correct traditional form of "王后": 後 ("back") was merged into 后 ("queen") in the simplification process.
searches for "系统" ("system" in simp. Chinese), the search engine will also look for "系統" (correct), "繫統" (technically incorrect), and "係統" (also technically incorrect)
繫 ("to tie")'s simplified form is 系
統 ("to relate")'s simplified form is 系
And finally, 系 ("system") is also its own character in traditional Chinese.

Problems with making it work:

First is that converting between traditional and simplified Chinese isn't exactly trivial. There are some ways to do that, probably a library could be used, but I'm not sure if those are 100% complete. I already checked, and Unicode normalization doesn't seem to do anything to Traditional/Simplified Chinese.

Additionally, making multiple searches with different variations affects performance, no matter how you do it. Of course we could normalize all Chinese names (and the queries to them) to one form, so that only one query would be ever needed, but I'm not sure if that's acceptable because it would mean the other form(s) can't be saved at all.

Maybe 7 days from changing?

Mostly useful for mashups. Has been requested a few times, for TouhouDB as well.

Would obviously require changing the current association from one-to-many to many-to-many. Could possibly make the performance worse. To mitigate performance penalty we could still use the old original song property to minimize the number of times the collection needs to be accessed.

Still need to evaluate whether it's feasible to implement due to increased complexity and lower performance.

Also need to consider how to implement "filter by parent version" feature. Probably the many-to-many list would need to include the whole parent hierarchy, and maintaining that could be very complicated.

Open issues: if multiple parents are specified, from which should the lyrics and characters be inherited? Could we always use the first parent song (most derived songs only have one parent anyway)?

Long album/song names are problematic, convoluting listings. They should be truncated, probably using CSS or lodash truncate.

Which is better? Pixel or character limit?

After the problem with the miku with you setlist
http://vocadb.net/E/1619/miku-with-you

even for http://vocadb.net/E/1397/magical-mirai-2017

there could be 3 setlists, it would be better for everyone (IMO)

we can just have a number (and a custom name as well) for the running order (afternoon concert, evening concert) or by days

Currently there's fields for one original PV and one reprint. Should add dropdowns for selecting type for each PV (by default the first can be original and second a reprint). Possibly a button for adding more PVs as well.

If more than one original PV is entered, how to load metadata (artist, song title)? First original Nico PV? What if the PV type is changed? Maybe there should always be one (fixed) field for original PV?

Provide generic filters for the main entity to be filtered. For example:

• Publish date (range)
• Artist type (possibly a subset such as only vocalist types)
• Song type
• PV type (original/reprint/other)
• Tag(s)

Additionally, provide the value to be reported:

• Number of songs
• Rating total

Requested.

Current date formats are based on .NET cultures. The closest we have is YYYY/MM/DD for the Japanese culture. There is no commonly used culture with the "." separator, so a custom culture needs to be defined.

We could add a new user setting for date format, to allow choosing the date formatting independently from culture. This could replace the current "Date and number formatting" setting.

How to handle time formatting? If the user wants YMD with 24 or 12 hour clock? Do we still need a separate setting for number formatting?

To combine the "group" membership and "voicebank developer" tag.

Consider the following suggestion --

Clicking "Select" on the original song when adding a cover should also fill in all three titles of the cover to be added, from the song that the user has selected.

Example: https://lut.im/Y6f3Wt75iA/JuUJuEABXhIQ21G9.png
In this case after clicking "Select" the "Non-English" and "Romanized" names should be automatically filled in.

Currently this needs to be done manually via first opening the original in a new browser tab and then copy-pasting each title into its field on the song addition page, which is inconvenient.

Thanks