[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 notifications@github.com 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

[Anichiraku-Main]

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.

[cnfw]

@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 < notifications@github.com> 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 notifications@github.com 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 notifications@github.com 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.

[jamotaylor]

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 😃

[boonduck]

I am working with BookStack on a daily basis in an academic setting. It took me weeks to get used to the hierarchy represented by "bookshelves", "books", "chapters", and "pages". And I am still struggling. To me, it's an arbitrarily chosen denomination meant to differentiate between 4 organizational levels of data. And quite frankly, that's all it is. In my opinion, ssddanbrown should realize that he created a software product that is ACTUALLY IN ACTIVE USE by users all over the world. That is the highest level of fulfillment any developer could wish for and few actually achieve. It also means that whatever concept you as a developer introduce in your software, will be validated in real-life scenarios. And that is done by users. Developers develop, and users use. And as such, it is only to be expected that users will have difficulties adapting to an arbitrarily chosen "bookshelves", "books", "chapters", "pages" analogy that might at some time seemed logical to the developer. My suggestion would be to implement a simple and straightforward way to allow users to change the labels "bookshelves", "books", "chapters", "pages" displayed in the User Interface to something they feel more comfortable with. I myself would immediately set this to "Spaces", "Sections", "Subdivisions", and "Sheets". Why? Because it makes sense to ME. Implementing this cannot be difficult while it immediately strengthens and improves the adaptability of BookStack to real-life situations. Presenting a BookStack implementation to solve a particular problem that displays jargon users are familiar with, makes BookStack much more appealing and increases user adaptation.

[ssddanbrown]

@boonduck

In my opinion, ssddanbrown should realize that he created a software product that is ACTUALLY IN ACTIVE USE by users all over the world. That is the highest level of fulfillment any developer could wish for and few actually achieve.

Apologies, I will start realizing this and remain 100% fulfilled at all times from now on.

It also means that whatever concept you as a developer introduce in your software, will be validated in real-life scenarios. And that is done by users. Developers develop, and users use. And as such, it is only to be expected that users will have difficulties adapting to an arbitrarily chosen "bookshelves", "books", "chapters", "pages" analogy that might at some time seemed logical to the developer. My suggestion would be to implement a simple and straightforward way to allow users to change the labels "bookshelves", "books", "chapters", "pages" displayed in the User Interface to something they feel more comfortable with. I myself would immediately set this to "Spaces", "Sections", "Subdivisions", and "Sheets". Why? Because it makes sense to ME.

If I just went ahead and included every option, customization or configuration that everyone requested this project would be an amorphous, unmaintainable and would loose any character. The book theme really does help hold together the UI and direction of the project.

Implementing this cannot be difficult

It's always fun being told that but, to be fair, that is correct; Simply implementing a feature is often the easy part these days. Maintaining it, resolving issues, dealing with the added technical dept and ensuring forwards compatibility are often the hard parts.

Presenting a BookStack implementation to solve a particular problem that displays jargon users are familiar with, makes BookStack much more appealing and increases user adaptation.

User adoption/popularity is not a primary focus for me, Exists users are. Chasing popularity is a dangerous path, likely to inch the project ever closer to being that amorphous open source blob. I've found that focusing on existing users is much more manageable and often brings a steady increase of popularity with it anyway.

---

As an added note, If anyone wanted to change the terms, and didn't care if the URLs use the default old terms, this can be done pretty easily using the theme system following the steps below. Note, You'll have to change out references of en for non-english languages.

1. Within your .env file add the line APP_THEME=custom and save.
2. Within your BookStack folder you'll find a themes folder. Within this create the folder path custom/lang/en.
3. Copy the file found at resources/lang/en/entities.php into your theme/custom/lang/en/ folder.
4. Open that file up and find/replace any Shelf/Book/Chapter/Page terms as required.

Upon future updates you may need to refresh that file you copied as new things get added but I always re-use existing terms where possible to limit this. There may be a few other references dotted about the language files but most of them will be in that file.

[bensulli]

For what it's worth, the above meets my particular use case! While I'd prefer for URLs to change as well, no one in my organization will likely notice or care.

This is @ssddanbrown 's and I feel he's made his position clear, so I'm going to close this feature request as it meets my needs as the OP.

[NickBezdel]

@ssddanbrown is this a money question, maybe? Find Bookstack to be one of the cleanest and easiest to use KB, but books/shelves are killing me. Willing to pay for it. I assume, many more are.

[bensulli]

@NickBezdel I don't mean to speak for @ssddanbrown here (I absolutely do not), but having followed this thread as the OP, I think he's been pretty clear this isn't a question of time/resources, it's about the vision of what differentiates BookStack from other wikis. He's also provided a theming system that achieves the intended outcome for many users.

If you're willing to spend on this, and if you'll forgive the entirely unsolicited suggestion, you could hire a developer to set up the theming system for your deployment, or even fork the project if you really want this feature.

[NickBezdel]

Thank you for your time and answer, @bensulli , but in my opinion, there are no other wiki's like Bookstack, both UI/UX wise with similar structure and usefulness. So (IMO, again) it's about time that its author, @ssddanbrown stopped being modest and stubborn and realized that he's already won his crowd of customers. And ease off the idea of "getting there by being different". Bookstack's already "there". The only thing Bookstack lacks is cutomisation and UI options for that. And that is also the only downside why me (and many others, I guess) are stuck: other wiki's are worse in various fields (taste and usability being among them), but Bookstack's not letting anyone go off the hook of "shelves/books". In my example, I'm in need of a well-structured knowledgebase for expats in The Netherlands, which I'm willing to set up and maintain for free, for everybody's gain, but "shelves/books" are not helping the structure of extensive immigration and everyday stuff FAQ at all.

P.S.: At the moment I'm actually considering averting my attention to a paid helpdesk solution (with knowledge base integrated), as this is quicker and easier for me than trying to prove to someone that they have nothing to prove :D Just to illustrate the predicament.

[watschi]

So (IMO, again) it's about time that its author, @ssddanbrown stopped being modest and stubborn and realized that he's already won his crowd of customers.

Why don't you stop being "modest" and "stubborn"? Please refrain from calling out FLOSS maintainers and expecting them to act on your will. That's a great way to lose open source projects. Also, there is no BookStack "customers", since it is provided entirely for free.

The only thing Bookstack lacks is cutomisation and UI options for that. And that is also the only downside why me (and many others, I guess) are stuck: other wiki's are worse in various fields (taste and usability being among them), but Bookstack's not letting anyone go off the hook of "shelves/books".

There is a customization option provided only a few comments above yours. If your not willing to put in the little effort required to modify BookStack as described, why should the maintainer be?

P.S.: At the moment I'm actually considering averting my attention to a paid helpdesk solution (with knowledge base integrated), as this is quicker and easier for me than trying to prove to someone that they have nothing to prove :D Just to illustrate the predicament.

You are free to use another product. Open source projects do not benefit from users like you if maintainers have to sacrifice their already sparce free time to argue, even after they made their position clear, as bensulli already mentioned.

[boonduck]

I think @NickBezdel has a valid point here and actually confirms my point I've made earlier. To be absolutely clear and prevent any misunderstanding, this is in no way criticism towards developer @ssddanbrown . Brown did a marvelous job developing BookStack and without his efforts we wouldn't even have this discussion. But as a developer, you cannot always predict how your software is going to be used or applied. Practice shows that users have the need to be able to change the names of the organizational levels. That's all -- who cares what the levels are called anyway? The difference is that it is a valid need felt by users and a need that immediately increases BookStacks' perceived value for its users. That should be reason enough for any developer to look into a solution. To me, the sad thing is that the energy put into debating this need felt by users, already seems to supersede the energy required to make the changes in the software.

[watschi]

That's all -- who cares what the levels are called anyway?

If nobody cares, why change it?

That should be reason enough for any developer to look into a solution.

Why do you think open source developers are obliged to act in the interest of users they never asked for?

To me, the sad thing is that the energy put into debating this need felt by users, already seems to supersede the energy required to make the changes in the software.

The sad thing is that you guys are still debating this in such a presumptuous way, even after Dan already spent the time making his position clear.

[ssddanbrown]

it's about time that its author, @ssddanbrown stopped being modest and stubborn and realized that he's already won his crowd of customers. And ease off the idea of "getting there by being different". Bookstack's already "there".

Ooof. It's never been about winning "his crowd of customers". That is almost opposite to the fact, My focus has been supporting the existing user-base that's happy with the current configuration and idea of what BookStack is.

there are no other wiki's like Bookstack, both UI/UX wise with similar structure and usefulness

other wiki's are worse in various fields (taste and usability being among them)

There's a reason for this. As you travel down the path of making a platform more customizable and extensible, it becomes very difficult for the "core" not to become more abstract & plain. Each option or configuration is another branch of logic to support and test, and these things can exponentially add up. BookStack is only in the state that it is right now due to starting off being opinionated.

Just to confirm, It's not that I don't see the need and I'm not saying this will never happen. As new things are developed I generally am implementing them in a more open manner. You can already override all text and icons. When I come to re-thinking the URLs I'll likely have this kind of thing in mind, but it's all a matter to judging the worth of a feature against the cost of maintenance & support (Not just the initial implementation, that's usually the lesser concern).

[amrohendawi]

All I had to do to remap the names of the entities(Shelves, Books, Pages, etc.) is to copy entities.php file from the source code at resources/lang/de/entities.php, modify the names and then add an extra line to the docker-compose.yml

volumes:
  - ./bookstack/:/config
  - ./entities.php:/var/www/html/resources/lang/de/entities.php

In my case I modified and mapped the german version of entities.php since my Bookstack instance's default language is set to German.

[ghost]

We can't use it unfortunaltely due to "book" and "shelves". What a pitty...We thought this was a KB.

[NSURLSession0]

If you put the following code in the <head> element (Settings -> Customization -> Custom HTML Head Content), you can replace all occurrences of "books", "shelves" etc. I'm definitely not proud of this code, but hey, it works 😂 The performance is not even that bad on my machine. Because we're hacking this into the frontend using the custom HTML feature, it won't break your BookStack instance when you update. Of course this solution isn't ideal, but in my case it's good enough (for now).

The dirty fix:

<script>
  var replace = {
    "shelves": "categories",
    "shelf": "category",
    "books": "topics",
    "book": "topic",
    "chapters": "sections",
    "chapter": "section"
  }

  var regex = new RegExp(Object.keys(replace).join("|"),"gi");

  function walkText(node) {
    if (node.className == "tri-layout-middle") {
        return;
    }

    if (node.nodeType == 3) {
      node.data = node.data.replace(regex, function(matched) {
        const replaced = replace[matched.toLowerCase()];

        if (matched.charAt(0) === matched.charAt(0).toUpperCase()) {
          return capitalizeFirstLetter(replaced);
        } else {
          return replaced;
        }
      });
    }

    if (node.nodeType == 1 && node.nodeName != "SCRIPT") {
      for (var i = 0; i < node.childNodes.length; i++) {
        walkText(node.childNodes[i]);
      }
    }
  }

  function capitalizeFirstLetter(string) {
    return string.charAt(0).toUpperCase() + string.slice(1);
  }

  window.onload = function() {
    walkText(document.body);
  };
</script>

[Swelidingo]

Reference to previous comment

Works like charm. thanx alot

[petr-hybler]

thx @Mauricevb

[ajnyga]

I realize that the issue is closed but just wanted to add a +1 for a feature like this. Our organisation is considering using the application for documentation, but the used taxonomy with shelves, books etc. is something that is considered problematic. Our concern is whether the users understand it well enough. We are considering maintaining our own translation (I already did some work with the Finnish translation), but are not sure if we want the extra burden when upgrading.

Anyway, thanks for the nice and clean software!

[anvarjamalsaifi]

I liked the software for our needs. Deployed it and works wells on a test server. But I think it might not go to prod because of the ability to change super simple taxonomies like books, shelves etc. For SaaS companies, this I think is a must have! Anyways, kudos for the open-source community for building this!

[mtcoffee]

If you put the following code in the <head> element (Settings -> Customization -> Custom HTML Head Content), you can replace all occurrences of "books", "shelves" etc.

If it helps anyone else, I found that this solution was also replacing the word bookstack in any article to topicstack. Updating the regex in line 9 to an exact match prevented this: var regex = new RegExp("\\b(" + Object.keys(replace).join("|") + ")\\b", "gi");

[Flavelius]

I'd be interested in this too (customization of the fixed 'Shelves' and 'Books' names, which don't fit our usecase). Every feature request seems to be redirected to this closed one, which suggests, that this is not supported, and currently not planned to be supported officially, is that correct?