Bookstack: [Feature Request] Change names of objects in the hierarchy (eg, "Books" to "Products")

[bensulli]

It would be valuable to have a simple UI-accessible way to rename the _types_ of objects in the wiki hierarchy. I wanted to change from Books -> Chapters -> Pages, to Products -> Features -> Pages. I had to change these in the localization files so it'd be nice to have a simpler way to mass-change these names.

[spaceraccoon]

Note: This will have to change URL routes as well. @bensulli did you manage to do this?

[bensulli]

Sadly no, I'm not a developer, this is just something I'd find valuable.

Good point about the URLs though, might be tough to ensure those stay functional after the change.

[spaceraccoon]

I'm going to attempt it tomorrow, so I'll keep you posted if it works and
how I did it.

On Wed, Jul 26, 2017 at 1:47 AM Ben Sullivan [e-mail]
wrote:

Sadly no, I'm not a developer, this is just something I'd find valuable.

Good point about the URLs though, might be tough to ensure those stay
functional after the change.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/BookStackApp/BookStack/issues/406#issuecomment-317797474,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARj5GYgoF_9ftHVjvVOPLRzDHpikQs0wks5sRhwlgaJpZM4NsJhI
.

[spaceraccoon]

@bensulli I managed to complete it - the live demo is at http://18.220.76.71/ (it won't be up long) - as you can see I changed Books/Chapters/Pages to People/Series/Interviews (I was particularly worried about series since the plural and singular forms are the same and could cause problems, but I haven't found it yet). You can see that the routes have changed as well. You mentioned you're not a developer so I wrote some steps and can help you further if you contact me privately.

This assumes an already-installed instance of BookStack. I used a fresh AWS Ubuntu 16.04 instance with the BookStack install script. Warning: I haven't fully debugged or tested this comprehensively, so approach with caution and YMMV. This is a signpost, not official documentation. Additionally, running database migrations and rollbacks WILL WIPE YOUR DATABASE.

1. First, roll back the database migrations since the databases are also being modified. In the bookstack directory, run sudo php artisan migrate:reset.
2. Next, cd out into the parent directory. Start with renaming Books. Run the following in order:
   a. sudo grep -rl --binary-files=without-match Books bookstack/ | xargs sed -i 's/Books/YOURNEWNAMECAPITALIZEDPLURAL/g'
   b. sudo grep -rl --binary-files=without-match Book bookstack/ | xargs sed -i 's/Book/YOURNEWNAMECAPITALIZEDSINGULAR/g'
   c. sudo grep -rl --binary-files=without-match books bookstack/ | xargs sed -i 's/books/yournewnameplural/g'
   d. sudo grep -rl --binary-files=without-match book bookstack/ | xargs sed -i 's/book/yournewnamesingular/g'
   e. _Special step only for Books_ sudo grep -rl --binary-files=without-match YOURNEWNAMECAPITALIZEDSINGULAR bookstack/ | xargs sed -i 's/YOURNEWNAMECAPITALIZEDSINGULAR/BookStack/g' -> This is because step b breaks BookStack, so this restores it. Also revert your changes for the .env, since this will change your database username.
3. This will break some things because files and folders also need to be renamed, not just their contents. These files and folders are located in /app (e.g. /app/Book.php needs to be renamed to YOURNEWNAMECAPITALIZEDSINGULAR.php), /app/Http/Controllers, /resources/views, and more. You could also presumably automate this using the rename command or do it manually.
4. In the bookstacks directory, run sudo php artisan migrate. If there is an error, just follow the debugging message - I worked this out by correcting errors one by one.
5. Now visit your web page again. Play around and see if anything fails. The debug messages are great, so you should activate development environment and debugging in the .env file.
6. Repeat 1-5 for Chapters and Pages. For Pages, keep an eye out for page_revisions and page_drafts as well - those files and folders need to be renamed too.

Notes: You will have to roll back the changes for the vendor/ directory (I just deleted it and reinstalled after each iteration), because those are dependencies. Additionally for app/Providers/PaginationServiceProvider.php and probably others that deal with actual site pages due to the unfortunate namespace clash.

Hope this helps anyone who wants to adapt this great piece of work. @ssddanbrown Hope this helps for implementation; it should presumably occur during setup only. It's a blunt approach and I'm sure there's a better method out there.

[bridgeyuwa]

The above process will be overwhelming for users with no technical knowledge.. I think easing this process is necessary..

[noxify]

@bridgeyuwa the solution from @spaceraccoon describes how to change everything from "Book" to "".

If you only need to change the url and the labels, it should be enough to modify the names inside the routes.php and modifing the lang files.

EDIT: damn i'm wrong - currently, the routes doesn't have a ->name() defined.
So the solution from above is currently the only one :)

[spaceraccoon]

Yep. Just wanted to leave this here for more technical users. It's a pain and you definitely need to do some tweaking on your own. @noxify Did your edit mean it wasn't enough to just change routes.php? I was thinking of trying that as well.

[noxify]

Yes it's not enough to change the routes - but this is based on the missing ->name() method in the routes.

I have created also an issue/feature request #475 - maybe we can use this as starting point :)

[ssddanbrown]

Just want to re-iterate for less technical viewers of this issue that the methods describe above will be reverted and/or cause issues when updating.

[bensulli]

Thanks for the help all. The above is more or less exactly what I ended up doing (albeit my way was more laborious). I wrote this issue because I think it'd be valuable to have as a frontend option, even just during first-time setup.

Edit: Sorry, didn't mean to close. I do think this is a valid feature request still.

[bridgeyuwa]

Am craving for this feature to be added to the next release

[nekromoff]

this would be indeed useful

[genxlee]

indeed that would be useful

[D347HxD]

Been 1 year since this has been last mentioned, any news on this getting added to the front end for non-technical users (for me I'd want it so I won't need to manually redo these steps on every Bookstack update.)

[fbkala]

This would be useful for me if it can be implemented in the future release!

[ezzra]

I also just edited the language files, I guess that is a pretty good workaround. Do you think there are so much users who are aware of the urls? Of course it would also very much appreciate having the option to just rename the categories, but this means a lot of code work and even dynamic setup in all of the language files.

[cw1998]

@ssddanbrown @Abijeet I could have a go at this if it isn't already in the works? Seems to be requested frequently enough that it would add value if it was available in settings.

[nekromoff]

Please, also note that translations in different languages might have three
or even five different ending plurals for an entity in the hierarchy.

E.g.
EN: 1 Book, 2+ Books
SK: 1 Kniha, 2-4 Knihy, 5 Kníh
etc.

POEdit has this solved, see their wiki:
https://poedit.net/trac/wiki/Doc/PluralForms

On Wed, Apr 24, 2019 at 10:17 AM Christopher Wilkinson <
[email protected]> wrote:

@ssddanbrown https://github.com/ssddanbrown @Abijeet
https://github.com/Abijeet I could have a go at this if it isn't
already in the works? Seems to be requested frequently enough that it would
add value if it was available in settings.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/BookStackApp/BookStack/issues/406#issuecomment-486119237,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACBHPTJDOLW4NMI2U62AV53PSAJSZANCNFSM4DNQTBEA
.

[ssddanbrown]

@cw1998 Thanks for offering but I'm not sure this specific feature is something I want to support in the core project right now.

The current naming system is pretty core to what BookStack is, Supporting this would mean adding and maintaining another level of configurability that would effect every view and almost every URL. Every bit of UI development would have to consider this requirement and it will likely spawn its own set of issues and required user support if it was to be implemented. Additionally, implementing this would encourage BookStack use outside of the scope of the project definition which tends to have more of a strain on support and issue management here on GitHub and weakens what BookStack is.

---

Perhaps we can help achieve this in another way. We have the theme system, where views & icons can be overridden on a per-file basis. Maybe we can do something similar where translation strings can be overridden on a per-translation basis. We're already some language extension thing for the de_informal language so we might not be too far off. That way, if someone really wanted to, they could override all translations for hierarchy items. People could even share their translation override sets with others. Plus this system could be used for far more customisation than just hierarchy items, while keeping the core project focused.

That kind of aligns of where I'd like to take BookStack: Simple, configured and focused by default but flexible and extensible for those with the knowledge and effort.

You'd still have the original names in the URLs, which could be a deal-breaker for some, but may be okay for others.

[polarathene]

I have recently setup BookStack for a community to evaluate as their new wiki, but the community managers feel that the terms "Shelves" and "Books" will confuse the users a bit UX wise. They're otherwise quite happy with what BookStack is and offers feature wise.

Additionally, implementing this would encourage BookStack use outside of the scope of the project definition which tends to have more of a strain on support and issue management here on GitHub and weakens what BookStack is.

What is meant by this? Because of the suggestion by this issues author for Books => Products? While allowing for substitutions, anything could be used... there are also practical ones, such as Shelves => Categories, Books => Topics. That wouldn't weaken what BookStack is would it?

A platform to create documentation/wiki content

The wiki for the community I'm assisting with for example has a few different sections of content they want to make available to users, which shelves would be suitable for, and each of those with their books with chapters/pages. It's just the terminology isn't ideal.

I don't mind it personally, and it's a neat analogy for organizing documentation, but I've never seen it described that way in other wiki/documentation myself. I believe being able to override it on page content via localization is better than nothing, and still make a difference. Beats having to manually maintain adjust the terminology like shown earlier in this issue.

Has any progress on what you've suggested been made since April? If not is it planned?

[nekromoff]

I also believe "shelves" and "books" do not describe common wiki entities
well. Even Wikipedia doesn't use this concept and goes with plain
categories and pages.

PS: You can always edit the language translation content to something else, even if this is not used for URLs.

On Fri, Oct 25, 2019 at 1:44 PM Brennan Kinney [e-mail]
wrote:

I have recently setup BookStack for a community to evaluate as their new
wiki, but the community managers feel that the terms "Shelves" and "Books"
will confuse the users a bit UX wise. They're otherwise quite happy with
what BookStack is and offers feature wise.

Additionally, implementing this would encourage BookStack use outside of
the scope of the project definition which tends to have more of a strain on
support and issue management here on GitHub and weakens what BookStack is.

What is meant by this? Because of the suggestion by this issues author for Books
=> Products? While allowing for substitutions, anything could be used...
there are also practical ones, such as Shelves => Categories, Books =>
Topics. That wouldn't weaken what BookStack is would it?

A platform to create documentation/wiki content

The wiki for the community I'm assisting with for example has a few
different sections of content they want to make available to users, which
shelves would be suitable for, and each of those with their books with
chapters/pages. It's just the terminology isn't ideal.

I don't mind it personally, and it's a neat analogy for organizing
documentation, but I've never seen it described that way in other
wiki/documentation myself. I believe being able to override it on page
content via localization is better than nothing, and still make a
difference. Beats having to manually maintain adjust the terminology like
shown earlier in this issue.

Has any progress on what you've suggested been made since April? If not is
it planned?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/BookStackApp/BookStack/issues/406?email_source=notifications&email_token=ACBHPTPUDNEKJIRXKHXJMQLQQLLZLA5CNFSM4DNQTBEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECIDIKQ#issuecomment-546321450,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACBHPTPLR7JES4ONNDDXOPDQQLLZLANCNFSM4DNQTBEA
.

[ssddanbrown]

The use of "shelves" and "books" was never supposed to align with other wiki systems, That's the point, that's BookStack's theme, that's what makes BookStack "BookStack", it has a set structure tied to a real world abstraction.

What is meant by this? Because of the suggestion by this issues author for Books => Products? While allowing for substitutions, anything could be used... there are also practical ones, such as Shelves => Categories, Books => Topics. That wouldn't weaken what BookStack is would it?

No, That particular case does not weaken what BookStack is but the fact that these things can be changed does. I takes the platform further to becoming a generic CMS.

Has any progress on what you've suggested been made since April? If not is it planned?

No progress and no plans other than It'd be good to allow translation overrides at some point. Though that won't solve the URL's which would leave the issue open thus I don't have much personal incentive to move forward to implement such as system myself right now.

[polarathene]

That's the point, that's BookStack's theme, that's what makes BookStack "BookStack", it has a set structure tied to a real world abstraction.

I get that, and I think it's pretty cool. It's just less likely to jive well with our intended userbase with an otherwise excellent wiki solution.

The users want a wiki that has a familiar hierarchy that you'd find with most other wiki's, they're not interested in different terminology relating it to books, it has no appeal to them, they're not even going to be aware it's BookStack afaik.

So while I appreciate the defaults being what they are, and how they align with establishing BookStack as more unique/memorable wiki from it's real world abstraction(which I'd have no problem with as a personal/internal wiki), I'm really not seeing how the justification matters here to the end users of the community that I and others set BookStack up for? We can change it either way since it's open-source, it's just a hacky way to go about it as it has to be done each time after an update..

I takes the platform further to becoming a generic CMS.

I don't see BookStack as a generic CMS and I doubt many of your users would choose to use BookStack for that purpose. There are plenty of other CMS options out there. Regardless, your free to make it very clear that BookStack is focused on being a wiki solution and not a generic CMS, if such a confusion were to occur, it's not like you have to support any issues from users trying to treat BookStack differently from being a wiki(this issue is not about that, even if it could be, it serves a valid purpose for wiki deployment).

No progress and no plans other than It'd be good to allow translation overrides at some point. Though that won't solve the URL's which would leave the issue open

It'd still be really nice to have. Users are more likely to have issue with UI text than the URL(since they'd have used plenty of sites where those can contain gibberish in the form of hashes.

I don't have much personal incentive to move forward to implement such as system myself right now.

Are you the primary developer/owner of BookStack? I haven't looked into development history/contributors yet, but I have seen your respond to various issues over the years here.

How much effort/time would you estimate implementing this support would take? I'm not a PHP developer but I am experienced with a few other languages and contributed to other projects on github before, if the translation override approach is not too difficult or time consuming to implement, I could take a shot at it and send a PR through(if it'd be likely to be merged).

URL concerns are a separate one to me and others here, that could close this issue and open a new issue specifically about that.

[polarathene]

@ssddanbrown I'm not familiar with how the localization feature is working here. Is that specifically only for de_informal currently and using the de equivalent locale as fallback for anything missing?

If so is it doing this fallback dynamically with each trans() call throughout the codebase, or is the merge a once off cost at init? Curious if this would be a good place to handle the override by using a regex to replace string content for words when an override file(perhaps json with mappings) is provided for a locale.

Would this handle all UI usage of the terms?

[ssddanbrown]

Hi @polarathene,

Are you the primary developer/owner of BookStack? I haven't looked into development history/contributors yet, but I have seen your respond to various issues over the years here.

Yeah, Contribution info can be seen at a glance here:
https://github.com/BookStackApp/BookStack/graphs/contributors
It's mainly myself doing what I can in my free time but other awesome people help out every so often.

I'm not familiar with how the localization feature is working here. Is that specifically only for de_informal currently and using the de equivalent locale as fallback for anything missing?

Yeah, that content was specifically for de_informal although I recently ripped out that system in master due to changes in how translations are managed.

---

I've just opened #1749 which ties the idea of custom translation strings into the theme system. I've added instructions to that pull request to indicate how these would be used. For this use case it would mostly be a matter of copying resources/lang/en/entities.php into your theme folder and switching out relevant text.

Not as easy as your find/replace suggestion from your point of view, where you're targeting specific words, but it keeps the functionality aligned with the core code & lessens then logic and chance for side-effects.

[nekromoff]

Hi Dan,

would you be open to include a custom config directive to allow for URL
switch/rewrite as well in addition to the translations.

I could look into it as I have some experience with Laravel.

On Sat, Oct 26, 2019, 14:01 Dan Brown [e-mail] wrote:

Hi @polarathene https://github.com/polarathene,

Are you the primary developer/owner of BookStack? I haven't looked into
development history/contributors yet, but I have seen your respond to
various issues over the years here.

Yeah, Contribution info can be seen at a glance here:
https://github.com/BookStackApp/BookStack/graphs/contributors
It's mainly myself doing what I can in my free time but other awesome
people help out every so often.

I'm not familiar with how the localization feature is working here. Is
that specifically only for de_informal currently and using the de
equivalent locale as fallback for anything missing?

Yeah, that content was specifically for de_informal although I recently
ripped out that system in master due to changes in how translations are

managed.

I've just opened #1749
https://github.com/BookStackApp/BookStack/pull/1749 which ties the idea
of custom translation strings into the theme system. I've added
instructions to that pull request to indicate how these would be used. For
this use case it would mostly be a matter of copying
resources/lang/en/entities.php into your theme folder and switching out
relevant text.

Not as easy as your find/replace suggestion from your point of view, where
you're targeting specific words, but it keeps the functionality aligned
with the core code & lessens then logic and chance for side-effects.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/BookStackApp/BookStack/issues/406?email_source=notifications&email_token=ACBHPTJJSDHN5MVDOUJ6LELQQQWS3A5CNFSM4DNQTBEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECKGNFY#issuecomment-546596503,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACBHPTPIQJMNMQUOWSJHRELQQQWS3ANCNFSM4DNQTBEA
.

[ssddanbrown]

@nekromoff Probably not at this time I'm afraid. I really don't want to have to deal with the extra abstraction and complication in the majority of URL handling for the future lifespan of the project.

[polarathene]

@ssddanbrown what complications would it be adding? When looking through the codebase, I noticed you have cases where the URL is hard-coded strings like /shelves? That could just be a variable which could point to a central PHP file when these values are used?

I know that abstracts it out a bit more, but honestly isn't that less complications with future updates in the project since it would be more clear where the code for such is compared to scattered through the current codebase with hard-coded string?

https://github.com/BookStackApp/BookStack/blob/cf5d51e7b8c9172906f7943d2d70b6b37801a2c4/resources/views/shelves/create.blade.php#L9

https://github.com/BookStackApp/BookStack/blob/2ab5df75dda7d0c0625a83783b655588f1fb657d/resources/views/partials/breadcrumbs.blade.php#L15

https://github.com/BookStackApp/BookStack/blob/cf5d51e7b8c9172906f7943d2d70b6b37801a2c4/resources/views/common/header.blade.php#L33

https://github.com/BookStackApp/BookStack/blob/31f5786e01fc5ed439f347c6979679612baca4fb/app/Entities/Bookshelf.php#L43

https://github.com/BookStackApp/BookStack/blob/0ac50c0e50bb8a8db35e6218b7a937740721a8f3/resources/views/shelves/index.blade.php#L4

https://github.com/BookStackApp/BookStack/blob/35f35bcba5866c288a7b22666b940aedb64fe1ed/resources/views/common/home-shelves.blade.php#L4

https://github.com/BookStackApp/BookStack/blob/1366fc45ce7849b744ea0f84b9b4587e7d0e61ba/routes/web.php#L15

https://github.com/BookStackApp/BookStack/blob/2ab5df75dda7d0c0625a83783b655588f1fb657d/tests/Permissions/RolesTest.php#L255

https://github.com/BookStackApp/BookStack/blob/2ab5df75dda7d0c0625a83783b655588f1fb657d/tests/Permissions/RolesTest.php#L262

Some of those may not be relevant to URL handling, just a quick search. If the URL values were instead something like $shelves_slug it doesn't differ too much from /shelves, and depending on editor I assume the variable might be able to reveal the value relatively easily? I'm not familiar enough with PHP atm, I see what appears to be globals like trans()/userCan() etc in the blade templates being injected(?) from somewhere?

If the various locations referenced a variable instead for the slugs, you could add those to localization or use the same approach(or just a json mapping like I suggested earlier). In other languages syntax like shelves_slug = json_data.shelves_slug || '/shelves' would likely work easily enough? If you run into issues it should at least be simpler to debug due to the shared slugs being centralized better? There isn't much benefit for them being repeated as hard-coded strings throughout the codebase is there?

---

Not as easy as your find/replace suggestion from your point of view, where you're targeting specific words, but it keeps the functionality aligned with the core code & lessens then logic and chance for side-effects.

Awesome :) Somethings better than nothing! Thanks for taking the time to support it!

It's mainly myself doing what I can in my free time but other awesome people help out every so often.

That's great :smiley: Thanks for sharing the project and open-sourcing it.

[ssddanbrown]

I get that it would seem like a simple thing to quickly add, and it frankly would be, but it isn't the implementation time that makes me adverse to this. I get that hard-coding the URL components can seem like "inefficient code" or a "code smell". If this was raised earlier in the project lifespan I'd perhaps agree but for me they provide some grounding.

Extracting them out could make it easier to change in future development but they almost never do so there's really not any efficiency gain in doing so. I think the abstraction would work against development, at least for me personally. Even if the current strings are replaced with similarly named variables it's an extra thing for the mind to parse. When debugging or helping resolve an issue it's an extra fork in the road for the mind to travel, and those forks just seem to keep building up in the project.

When I think about what would happen after releasing such a feature, My mind instantly goes to imagining a series of fresh GitHub issues popping up:

• [Feature Request] Add interface to easily change item URL slugs via settings
• [Bug] Changing URL slugs causes issues for existing content
• [Help] I changed the book slug to settings and can no longer access the settings page.
• [Issue] Getting an error in the console that a request to /sausages/search is failing.
• [Feature Request] Would be interesting to be able to use slashes in the custom slugs

I know that this appears cynical, and it totally is, but I grow more and more haunted by the issue list. Each issue created represents time that has to be spent to understand, review and form a response to. The vast majority of the people creating such issues genuinely care or like the project so I feel it's important to think about each request and provide a proper response. Being a massive introvert causes me to overthink my responses so they often stay trapped, orbiting in the mind until they can be formalised. All this is time not spent on the code.

Some of my thinking on this overlaps with the thoughts on my post here.

Just to confirm, since my comments above will appear negative, I still understand why this feature would be desired and this issue will remain open for discussion and consideration. I may even wake up tomorrow and feel totally different on this, Could just be in a bad mindset right now.

---

Awesome :) Somethings better than nothing! Thanks for taking the time to support it!
That's great :smiley: Thanks for sharing the project and open-sourcing it.

Thanks :heart:

[polarathene]

I get that hard-coding the URL components can seem like "inefficient code" or a "code smell"

Definitely a code smell to me, but I'm not maintaining the project with zero contributions thus far, it's for the most part yourself, so whatever makes most sense to you is fine.

there's really not any efficiency gain in doing so

For your own purposes, there's little reason to support it, you already have your preferred terminology and are making this software available to others freely, there's very little benefit to you. The feature would make it far more easier for others to adjust even in an unofficially supported sense via their own forks where only one central file needs to be patched.

The benefit for overriding like this also means a user would get any new updates where the hard-coded URL would have been added, without having to go through commit history and search for the keywords which may or may not be slug related to add to their patching process.

Even if the current strings are replaced with similarly named variables it's an extra thing for the mind to parse. When debugging or helping resolve an issue it's an extra fork in the road for the mind to travel, and those forks just seem to keep building up in the project.

I understand and respect that concern. Although I'd like to point out the well known DRY concept. Couldn't you just as likely run into a situation you're debugging where you have to mentally note where all your hard-coded slugs for a certain keyword(and variants, eg shelf/shelves) are used?

As shown above, it's spread across the codebase and not easy to search for afaik since it's mixed with the usage of the same keyword elsewhere(localization and business logic). If anything, centralizing your slug strings lightens the load there. There is one file where you mentally know to look for where your slug strings are defined, even if they remain hard-coded in that file, with no support for user replacement.

Additionally, depending on your dev environment, your editor might be smart enough to show the variable value where it's referenced, as well as easily jump you to it's definition file, alleviating you from any additional mental load?

When I think about what would happen after releasing such a feature, My mind instantly goes to imagining a series of fresh GitHub issues popping up

That's a very valid concern! There's plenty of open issues already with little development resources available to the project. Some of the examples can be easily avoided/rejected, but they're still a burden on your time to handle.

If you centralized the slugs to a single file, you provide an unofficial way to more easily maintain alternative slugs that you don't have to provide support for issue wise. I'm sure for those interested, they could overwrite the file with their own preferred slugs just like the localization override support? You wouldn't need to add any additional logic and could stick to hard-coded strings.

Anyone who does contribute would also have a clearer understanding about how slugs are defined, so if they contribute code related to them, or code that adds a new slug for a feature, they can be nicely organized? (more useful when you're not the majority contributor, since you generally know where all these definitions are if you want to deal with them...for others, it's added mental weight to map out)

I know that this appears cynical, and it totally is, but I grow more and more haunted by the issue list.

I don't see it as cynical, it's very reasonable. I can relate.

Just to confirm, since my comments above will appear negative, I still understand why this feature would be desired and this issue will remain open for discussion and consideration.

Not negative, just a different perspective.

If you'd like to go forward on centralizing the hard-coded strings to be referenced elsewhere via vars, I'm happy to help contribute code towards such, just let me know how you would like to handle it.

[nwtnwrkshp]

Sadly no, I'm not a developer, this is just something I'd find valuable.

Good point about the URLs though, might be tough to ensure those stay functional after the change.

You can do it man! Development is easy - just copy and paste from StackOverflow 😃