starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Enhancement]: Subtitle parsing to use customary English lexicographical symbols, i.e., : as well as - ; also seperated is misspelled. #1510

New Issue
Open
opened 2026-04-24 23:48:13 +02:00 by adam · 7 comments
adam commented 2026-04-24 23:48:13 +02:00
Owner
Copy Link
Copy Source

Originally created by @iconoclasthero on GitHub (Nov 4, 2023).

Describe the feature/enhancement

For those of us not locked into Microsoft's character restrictions on file names, i.e., anyone in linux, using a - for a subtitle separator instead of : is unnecessary and flouts the lexographic convention of how titles and subtitles have traditionally been punctuated (i.e., prior to MS-DOS being a thing). As such, the parsing of subtitle option that is described as

Extract subtitles from audiobook folder names.
Subtitle must be seperated by " - "
i.e. "Book Title - A Subtitle Here" has the subtitle "A Subtitle Here"

should be changed to include : such as:

Extract subtitles from audiobook folder names.
Subtitle must be seperated by " - " or " : "
i.e. "Book Title - A Subtitle Here" has the subtitle "A Subtitle Here"
or "Book Title: A Subtitle Separated by Colon" has the subtitle "A Subtitle Separated by Colon"

Originally created by @iconoclasthero on GitHub (Nov 4, 2023). ### Describe the feature/enhancement For those of us not locked into Microsoft's character restrictions on file names, i.e., anyone in linux, using a `-` for a subtitle separator instead of `:` is unnecessary and flouts the lexographic convention of how titles and subtitles have traditionally been punctuated (i.e., prior to MS-DOS being a thing). As such, the parsing of subtitle option that is described as > Extract subtitles from audiobook folder names. > Subtitle must be **seperated** by " - " > i.e. "Book Title - A Subtitle Here" has the subtitle "A Subtitle Here" should be changed to include `:` such as: > Extract subtitles from audiobook folder names. > Subtitle must be **seperated** by " - " or " : " > i.e. "Book Title - A Subtitle Here" has the subtitle "A Subtitle Here" > or "Book Title: A Subtitle Separated by Colon" has the subtitle "A Subtitle Separated by Colon"
adam added the enhancement label 2026-04-24 23:48:13 +02:00
adam commented 2026-04-24 23:48:14 +02:00
Author
Owner
Copy Link
Copy Source

@CLHatch commented on GitHub (Nov 5, 2023):

Describe the feature/enhancement

For those of us not locked into Microsoft's character restrictions on file names, i.e., anyone in linux, using a - for a subtitle separator instead of : is unnecessary and flouts the lexographic convention of how titles and subtitles have traditionally been punctuated (i.e., prior to MS-DOS being a thing). As such, the parsing of subtitle option that is described as

Extract subtitles from audiobook folder names.
Subtitle must be seperated by " - "
i.e. "Book Title - A Subtitle Here" has the subtitle "A Subtitle Here"

should be changed to include : such as:

Extract subtitles from audiobook folder names.
Subtitle must be seperated by " - " or " : "
i.e. "Book Title - A Subtitle Here" has the subtitle "A Subtitle Here"
or "Book Title: A Subtitle Separated by Colon" has the subtitle "A Subtitle Separated by Colon"

If this were to be done, it might be a good idea to allow parsing of ꞉ as well (the Unicode equiv of :). It's what I use in Windows, and the Libation app can optionally convert colons to it as well.

@CLHatch commented on GitHub (Nov 5, 2023): > ### Describe the feature/enhancement > For those of us not locked into Microsoft's character restrictions on file names, i.e., anyone in linux, using a `-` for a subtitle separator instead of `:` is unnecessary and flouts the lexographic convention of how titles and subtitles have traditionally been punctuated (i.e., prior to MS-DOS being a thing). As such, the parsing of subtitle option that is described as > > > Extract subtitles from audiobook folder names. > > Subtitle must be **seperated** by " - " > > i.e. "Book Title - A Subtitle Here" has the subtitle "A Subtitle Here" > > should be changed to include `:` such as: > > > Extract subtitles from audiobook folder names. > > Subtitle must be **seperated** by " - " or " : " > > i.e. "Book Title - A Subtitle Here" has the subtitle "A Subtitle Here" > > or "Book Title: A Subtitle Separated by Colon" has the subtitle "A Subtitle Separated by Colon" If this were to be done, it might be a good idea to allow parsing of `꞉` as well (the Unicode equiv of `:`). It's what I use in Windows, and the Libation app can optionally convert colons to it as well.
adam commented 2026-04-24 23:48:15 +02:00
Author
Owner
Copy Link
Copy Source

@iconoclasthero commented on GitHub (Nov 5, 2023):

I've never ventured too much into those unicode replacements because I can
use the colon, but yeah, maybe the suggestion should be "parse subtitles?"
with an entry box for the delimiter.

On Sun, Nov 5, 2023 at 5:04 AM CLHatch @.***> wrote:

Describe the feature/enhancement

For those of us not locked into Microsoft's character restrictions on file
names, i.e., anyone in linux, using a - for a subtitle separator instead
of : is unnecessary and flouts the lexographic convention of how titles
and subtitles have traditionally been punctuated (i.e., prior to MS-DOS
being a thing). As such, the parsing of subtitle option that is described as

Extract subtitles from audiobook folder names.
Subtitle must be seperated by " - "
i.e. "Book Title - A Subtitle Here" has the subtitle "A Subtitle Here"

should be changed to include : such as:

Extract subtitles from audiobook folder names.
Subtitle must be seperated by " - " or " : "
i.e. "Book Title - A Subtitle Here" has the subtitle "A Subtitle Here"
or "Book Title: A Subtitle Separated by Colon" has the subtitle "A
Subtitle Separated by Colon"

If this were to be done, it might be a good idea to allow parsing of ꞉ as
well (the Unicode equiv of :). It's what I use in Windows, and the
Libation app can optionally convert colons to it as well.

—
Reply to this email directly, view it on GitHub
https://github.com/advplyr/audiobookshelf/issues/2286#issuecomment-1793691336,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEC3GVW3GBBJ4RRFSGPDHDYC5JBZAVCNFSM6AAAAAA65WB5EGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJTGY4TCMZTGY
.
You are receiving this because you authored the thread.Message ID:
@.***>

@iconoclasthero commented on GitHub (Nov 5, 2023): I've never ventured too much into those unicode replacements because I can use the colon, but yeah, maybe the suggestion should be "parse subtitles?" with an entry box for the delimiter. On Sun, Nov 5, 2023 at 5:04 AM CLHatch ***@***.***> wrote: > Describe the feature/enhancement > > For those of us not locked into Microsoft's character restrictions on file > names, i.e., anyone in linux, using a - for a subtitle separator instead > of : is unnecessary and flouts the lexographic convention of how titles > and subtitles have traditionally been punctuated (i.e., prior to MS-DOS > being a thing). As such, the parsing of subtitle option that is described as > > Extract subtitles from audiobook folder names. > Subtitle must be *seperated* by " - " > i.e. "Book Title - A Subtitle Here" has the subtitle "A Subtitle Here" > > should be changed to include : such as: > > Extract subtitles from audiobook folder names. > Subtitle must be *seperated* by " - " or " : " > i.e. "Book Title - A Subtitle Here" has the subtitle "A Subtitle Here" > or "Book Title: A Subtitle Separated by Colon" has the subtitle "A > Subtitle Separated by Colon" > > If this were to be done, it might be a good idea to allow parsing of ꞉ as > well (the Unicode equiv of :). It's what I use in Windows, and the > Libation app can optionally convert colons to it as well. > > — > Reply to this email directly, view it on GitHub > <https://github.com/advplyr/audiobookshelf/issues/2286#issuecomment-1793691336>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAEC3GVW3GBBJ4RRFSGPDHDYC5JBZAVCNFSM6AAAAAA65WB5EGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJTGY4TCMZTGY> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >
adam commented 2026-04-24 23:48:16 +02:00
Author
Owner
Copy Link
Copy Source

@CLHatch commented on GitHub (Nov 6, 2023):

I've never ventured too much into those unicode replacements because I can use the colon, but yeah, maybe the suggestion should be "parse subtitles?" with an entry box for the delimiter.
…
On Sun, Nov 5, 2023 at 5:04 AM CLHatch @.> wrote: Describe the feature/enhancement For those of us not locked into Microsoft's character restrictions on file names, i.e., anyone in linux, using a - for a subtitle separator instead of : is unnecessary and flouts the lexographic convention of how titles and subtitles have traditionally been punctuated (i.e., prior to MS-DOS being a thing). As such, the parsing of subtitle option that is described as Extract subtitles from audiobook folder names. Subtitle must be seperated by " - " i.e. "Book Title - A Subtitle Here" has the subtitle "A Subtitle Here" should be changed to include : such as: Extract subtitles from audiobook folder names. Subtitle must be seperated by " - " or " : " i.e. "Book Title - A Subtitle Here" has the subtitle "A Subtitle Here" or "Book Title: A Subtitle Separated by Colon" has the subtitle "A Subtitle Separated by Colon" If this were to be done, it might be a good idea to allow parsing of ꞉ as well (the Unicode equiv of :). It's what I use in Windows, and the Libation app can optionally convert colons to it as well. — Reply to this email directly, view it on GitHub <#2286 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEC3GVW3GBBJ4RRFSGPDHDYC5JBZAVCNFSM6AAAAAA65WB5EGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJTGY4TCMZTGY . You are receiving this because you authored the thread.Message ID: @.>

Personally, I'd use the unicode replacements even if my file system did allow the colon in the filename. Just so I wouldn't have any issues if I wanted to copy them to another system that doesn't support it.

@CLHatch commented on GitHub (Nov 6, 2023): > I've never ventured too much into those unicode replacements because I can use the colon, but yeah, maybe the suggestion should be "parse subtitles?" with an entry box for the delimiter. > […](#) > On Sun, Nov 5, 2023 at 5:04 AM CLHatch ***@***.***> wrote: Describe the feature/enhancement For those of us not locked into Microsoft's character restrictions on file names, i.e., anyone in linux, using a - for a subtitle separator instead of : is unnecessary and flouts the lexographic convention of how titles and subtitles have traditionally been punctuated (i.e., prior to MS-DOS being a thing). As such, the parsing of subtitle option that is described as Extract subtitles from audiobook folder names. Subtitle must be *seperated* by " - " i.e. "Book Title - A Subtitle Here" has the subtitle "A Subtitle Here" should be changed to include : such as: Extract subtitles from audiobook folder names. Subtitle must be *seperated* by " - " or " : " i.e. "Book Title - A Subtitle Here" has the subtitle "A Subtitle Here" or "Book Title: A Subtitle Separated by Colon" has the subtitle "A Subtitle Separated by Colon" If this were to be done, it might be a good idea to allow parsing of ꞉ as well (the Unicode equiv of :). It's what I use in Windows, and the Libation app can optionally convert colons to it as well. — Reply to this email directly, view it on GitHub <[#2286 (comment)](https://github.com/advplyr/audiobookshelf/issues/2286#issuecomment-1793691336)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEC3GVW3GBBJ4RRFSGPDHDYC5JBZAVCNFSM6AAAAAA65WB5EGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJTGY4TCMZTGY> . You are receiving this because you authored the thread.Message ID: ***@***.***> Personally, I'd use the unicode replacements even if my file system did allow the colon in the filename. Just so I wouldn't have any issues if I wanted to copy them to another system that doesn't support it.
adam commented 2026-04-24 23:48:16 +02:00
Author
Owner
Copy Link
Copy Source

@iconoclasthero commented on GitHub (Nov 6, 2023):

from the simple fact that I've chosen iconoclast as part of my nick, it's fairly safe to assume i don't really care much about that convention or the problem of having to go back to windows, however, should I ever need to:

find . -iname "*:*" -exec sh -c 'mv "$1" "${1//:/꞉}"' _ {} \;

Certainly more efficient than having to put U-A789 in each time I want to use a colon.

@iconoclasthero commented on GitHub (Nov 6, 2023): from the simple fact that I've chosen iconoclast as part of my nick, it's fairly safe to assume i don't really care much about that convention or the problem of having to go back to windows, however, should I ever need to: `find . -iname "*:*" -exec sh -c 'mv "$1" "${1//:/꞉}"' _ {} \;` Certainly more efficient than having to put U-A789 in each time I want to use a colon.
adam commented 2026-04-24 23:48:17 +02:00
Author
Owner
Copy Link
Copy Source

@CLHatch commented on GitHub (Nov 6, 2023):

from the simple fact that I've chosen iconoclast as part of my nick, it's fairly safe to assume i don't really care much about that convention or the problem of having to go back to windows, however, should I ever need to:

find . -iname "*:*" -exec sh -c 'mv "$1" "${1//:/꞉}"' _ {} \;

Certainly more efficient than having to put U-A789 in each time I want to use a colon.

I was thinking more in terms of if you wanted to copy some of the books to flash drive, for use on a system that doesn't support certain characters. Seems more efficient to me to just have them named with the unicode chars to begin with, especially since it's usually done for me automatically. But you do you. Myself, I prefer to use a char set that all systems support.

@CLHatch commented on GitHub (Nov 6, 2023): > from the simple fact that I've chosen iconoclast as part of my nick, it's fairly safe to assume i don't really care much about that convention or the problem of having to go back to windows, however, should I ever need to: > > `find . -iname "*:*" -exec sh -c 'mv "$1" "${1//:/꞉}"' _ {} \;` > > Certainly more efficient than having to put U-A789 in each time I want to use a colon. I was thinking more in terms of if you wanted to copy some of the books to flash drive, for use on a system that doesn't support certain characters. Seems more efficient to me to just have them named with the unicode chars to begin with, especially since it's usually done for me automatically. But you do you. Myself, I prefer to use a char set that all systems support.
adam commented 2026-04-24 23:48:17 +02:00
Author
Owner
Copy Link
Copy Source

@iconoclasthero commented on GitHub (Nov 7, 2023):

This is getting off topic; while I am not asking permission, I'm sure I'm not the only linux user (amongst 33 million others) who likes to use DOS-prohibited characters in their file names;* and in the 15 or so years I've been doing audiobooks on linux, this [flash drive, other OS issue] has literally never come up with the exception of one torrent site. (In truth the last one has little to do with my file system since it is apparently not a problem with bittorrent in general and *that site wouldn't have that as a check just for me,)

@iconoclasthero commented on GitHub (Nov 7, 2023): This is getting off topic; while I am not asking permission, I'm sure I'm not the only linux user (amongst 33 million others) who likes to use DOS-prohibited characters in their file names;* and in the 15 or so years I've been doing audiobooks on linux, this [flash drive, other OS issue] has literally never come up with the exception of one torrent site. (In truth the last one has little to do with my file system since it is apparently not a problem with bittorrent in general and *that site wouldn't have that as a check just for me,)
adam commented 2026-04-24 23:48:17 +02:00
Author
Owner
Copy Link
Copy Source

@iconoclasthero commented on GitHub (Jul 12, 2024):

It would be great if there was some movement on this. All of my book titles/subtitles are fowled up now as a result of this.
it is pretty maddening that i cannot use the proper symbols for the title: subtitle designation where my OS permits it just because the OS of others doesn't.

@iconoclasthero commented on GitHub (Jul 12, 2024): It would be great if there was some movement on this. All of my book titles/subtitles are fowled up now as a result of this. it is pretty maddening that i cannot use the proper symbols for the title: subtitle designation where my OS permits it just because the OS of others doesn't.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#1510
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?