You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support for external JSON meta files. I have lots of (a couple thousand) archives where the JSON metadata isn't included inside the ZIP file but inside the same directory as the ZIP file is located (visualized example below). This is mostly because they are torrents from ExH which don't include the metadata inside the ZIP. I don't really want to move the metadata inside those ZIP files as my torrent client would not recognize them anymore + other issues like file integrity.
The name of the metadata file can be an exact match but not always. When it's not: at least the title and the author/circle could used used as rules for a fuzzy matching.
Probably the name (e.g. プロトタイプ マドモアゼル below) could be the minimum requirement for a match (aside from whitespace) with an option to also match the author/circle (e.g. リンゴヤ (あるぷ) below).
Conflicts would probably be rare as usually people only have one version of the doujinshi, but of course not impossible. In that case LANraragi could maybe list all the conflicts in text form, but this is not as important at the moment I think.
The first two files and last two files should match together.
Those JSON files are in the standard format which is also used by the eze plugin. Example for [40010試作型] プロトタイプ マドモアゼル [DL版].json: [40010試作型] プロトタイプ マドモアゼル [DL版].txt
The extension here is txt because GitHub didn't allow uploading json files. Also, omitted links and other sensitive data.
The text was updated successfully, but these errors were encountered:
I think I've received this suggestion a few times before, so it's probably worth taking on.
The eze plugin could probably be extended to look for a json file in the archive's parent directory, which would solve this.
(See here for what the plugin currently looks for)
It'd probably only look for exact matches at first though, since fuzzy matching can result in conflicts as you said.
Great! That's probably the best direction to take on yeah.
I don't know Perl myself but I guess this might be a good chance to learn a little about it. It does look a bit like Ruby (makes sense as it was influenced by Perl).
Suggestion, and the problem it'd solve
Support for external JSON meta files. I have lots of (a couple thousand) archives where the JSON metadata isn't included inside the ZIP file but inside the same directory as the ZIP file is located (visualized example below). This is mostly because they are torrents from ExH which don't include the metadata inside the ZIP. I don't really want to move the metadata inside those ZIP files as my torrent client would not recognize them anymore + other issues like file integrity.
The name of the metadata file can be an exact match but not always. When it's not: at least the title and the author/circle could used used as rules for a fuzzy matching.
Probably the name (e.g.
プロトタイプ マドモアゼル
below) could be the minimum requirement for a match (aside from whitespace) with an option to also match the author/circle (e.g.リンゴヤ (あるぷ)
below).Conflicts would probably be rare as usually people only have one version of the doujinshi, but of course not impossible. In that case LANraragi could maybe list all the conflicts in text form, but this is not as important at the moment I think.
Examples:
📂archive_dir
┣ 📜(成年コミック) [40010試作型] プロトタイプ マドモアゼル.zip
┣ 📜[40010試作型] プロトタイプ マドモアゼル [DL版].json
┣ 📜(COMIC1☆11) [リンゴヤ (あるぷ)] TRANCE CONTROL (ラブライブ! サンシャイン!!).zip
┗ 📜(COMIC1☆11) [リンゴヤ (あるぷ)] TRANCE CONTROL (ラブライブ! サンシャイン!!).json
The first two files and last two files should match together.
Those JSON files are in the standard format which is also used by the eze plugin. Example for
[40010試作型] プロトタイプ マドモアゼル [DL版].json
: [40010試作型] プロトタイプ マドモアゼル [DL版].txtThe extension here is txt because GitHub didn't allow uploading json files. Also, omitted links and other sensitive data.
The text was updated successfully, but these errors were encountered: