Misspelled Author name "Toshizou"

[Ekun]

Hi dear moderator / Admins,

I just found that an Author name is misspelled in the site.
If we search for; Toshizo it give as two series result,

https://j-novel.club/series?search=toshizo

... but instead if we search for; Toshizou with "U" at the end (large "O" in romanised Japanese ) it only give us one series result.

https://j-novel.club/series?search=toshizou

Which according to Amazon JAPAN, is the SAME author: by としぞう

https://www.amazon.co.jp/-/en/としぞう/e/B07SM4SJD3

Cheers fellas.

[Geezer Weasalopes]

@Ekun
As someone who has pointed out this very one in the past...

It appears to be a case where the works were published by different publishers in Japan, and the spelling to be used in English was set by the Japanese publisher as part of the licensing negotiations; the romanization used for each work is a contractual matter.

They are aware that it makes it hard to find both author entries depending upon which spelling you enter as your search term.
It is something they'd like to do something about down the line, but from a coding perspective it's of much lower priority than other matters related to the web site.

[Ekun]

@Geezer-Weasalopes
Thanks a lot for your answer.

Will it not be better to add a second tag in the author's first published work;
The Sidekick Never Gets the Girl, Let Alone the Protag’s Sister!
~ 'TsohizoU' with Toshizo,

I can NOT believe it will incur in any contractual breaching ... having 2 tag in the same Author pages, to facilitate the searching 👀

cheers!

~ PS: not that either will give much Coding work either ...

[killerrin]

@Ekun said in Misspelled Author name "Toshizou":

Will it not be better to add a second tag in the author's first published work;

While that could probably work as an easy solution. It would all depend on how JNC has their tagging system setup. If its setup to display everything in the DB for a series to the page, then they have to implement a flag to hide tags so they dont get shown first before they could do that.

And while it likely wouldn't take long to implement such a flag. They also likely have a million other things on the backlog that wouldn't take long to do, all with varying levels of priority.

And of course. If the legal contract was written in such a way as to prevent it ie. They have to make the distinction that they're different. Then of course nothing technical could be done.

[Geezer Weasalopes]

My coding experience, what there was of it, is some 30 years out of date, so take the following with a grain of salt when it comes to how it would be implemented.

It looks like the JNC search engine searches specified fields using a strict character by character match, but allowing anything beyond the final character of the search string to be considered a match when compared to the database contents.
If the search string is five characters, it'll compare the first five characters of the proper field in all relevant records and so long as those five characters match return that record as a 'hit'. A blank character, or lack of characters entirely, does not count as a match, so a five character search string will never return a four character entry.
Thus, a search for Toshizo will return both Toshizo and Toshizou, while searching Toshizou will exclude Toshizo as it doesn't have the requisite 'u'.

All the possible solutions I can think of require a pre-filter that search strings pass through before actually searching the database.
I'm working on the presumption that all searches funnel back into the same search engine after passing through the pre-filter, as there are no permanent relations being established within the database proper between variant spellings. [the database structure itself remains unchanged].
A search string gets entered, and is compared to a list maintained in a pre-filter.
If the search string finds a match, it truncates the search string to one which will pull up all variant spellings based upon information stored within the pre-filter [either using a truncate command if the language supports such, or saying "use this stored search string instead"].

It's a non-trivial task to set up and maintain such a thing, which makes it a rather low priority in comparison to other web site improvements under consideration at this time.