mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-06 00:59:39 +03:00
[Feature Request] Change names of objects in the hierarchy (eg, "Books" to "Products") #347
Reference in New Issue
Block a user
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?
Originally created by @bensulli on GitHub (May 31, 2017).
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 commented on GitHub (Jul 25, 2017):
Note: This will have to change URL routes as well. @bensulli did you manage to do this?
@bensulli commented on GitHub (Jul 25, 2017):
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 commented on GitHub (Jul 25, 2017):
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:
@spaceraccoon commented on GitHub (Jul 26, 2017):
@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.
sudo php artisan migrate:reset.cdout 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 breaksBookStack, so this restores it. Also revert your changes for the .env, since this will change your database username./app(e.g./app/Book.phpneeds to be renamed toYOURNEWNAMECAPITALIZEDSINGULAR.php),/app/Http/Controllers,/resources/views, and more. You could also presumably automate this using therenamecommand or do it manually.sudo php artisan migrate. If there is an error, just follow the debugging message - I worked this out by correcting errors one by one..envfile.page_revisionsandpage_draftsas 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 forapp/Providers/PaginationServiceProvider.phpand 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 commented on GitHub (Aug 16, 2017):
The above process will be overwhelming for users with no technical knowledge.. I think easing this process is necessary..
@noxify commented on GitHub (Aug 16, 2017):
@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.phpand 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 commented on GitHub (Aug 17, 2017):
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 commented on GitHub (Aug 17, 2017):
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 commented on GitHub (Aug 17, 2017):
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 commented on GitHub (Aug 17, 2017):
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 commented on GitHub (Aug 28, 2017):
Am craving for this feature to be added to the next release
@nekromoff commented on GitHub (Sep 16, 2017):
this would be indeed useful
@genxlee commented on GitHub (Oct 4, 2017):
indeed that would be useful
@InspireToCode commented on GitHub (Oct 6, 2018):
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 commented on GitHub (Nov 28, 2018):
This would be useful for me if it can be implemented in the future release!
@ezzra commented on GitHub (Dec 12, 2018):
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 commented on GitHub (Apr 24, 2019):
@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 commented on GitHub (Apr 24, 2019):
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 commented on GitHub (Apr 24, 2019):
@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 commented on GitHub (Oct 25, 2019):
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.
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 asShelves => Categories,Books => Topics. That wouldn't weaken what BookStack is would it?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 commented on GitHub (Oct 25, 2019):
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:
@ssddanbrown commented on GitHub (Oct 25, 2019):
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.
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.
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 commented on GitHub (Oct 26, 2019):
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 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).
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.
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 commented on GitHub (Oct 26, 2019):
@ssddanbrown I'm not familiar with how the localization feature is working here. Is that specifically only for
de_informalcurrently and using thedeequivalent 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 commented on GitHub (Oct 26, 2019):
Hi @polarathene,
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.
Yeah, that content was specifically for de_informal although I recently ripped out that system in
masterdue 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.phpinto 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 commented on GitHub (Oct 26, 2019):
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:
@ssddanbrown commented on GitHub (Oct 26, 2019):
@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 commented on GitHub (Oct 26, 2019):
@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?
cf5d51e7b8/resources/views/shelves/create.blade.php (L9)2ab5df75dd/resources/views/partials/breadcrumbs.blade.php (L15)cf5d51e7b8/resources/views/common/header.blade.php (L33)31f5786e01/app/Entities/Bookshelf.php (L43)0ac50c0e50/resources/views/shelves/index.blade.php (L4)35f35bcba5/resources/views/common/home-shelves.blade.php (L4)1366fc45ce/routes/web.php (L15)2ab5df75dd/tests/Permissions/RolesTest.php (L255)2ab5df75dd/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_slugit 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 liketrans()/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?Awesome :) Somethings better than nothing! Thanks for taking the time to support it!
That's great 😃 Thanks for sharing the project and open-sourcing it.
@ssddanbrown commented on GitHub (Oct 26, 2019):
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:
/sausages/searchis failing.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.
Thanks ❤️
@polarathene commented on GitHub (Oct 27, 2019):
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.
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.
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?
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 don't see it as cynical, it's very reasonable. I can relate.
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 commented on GitHub (Jan 24, 2020):
You can do it man! Development is easy - just copy and paste from StackOverflow 😃
@boonduck commented on GitHub (Feb 2, 2021):
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 commented on GitHub (Feb 2, 2021):
@boonduck
Apologies, I will start realizing this and remain 100% fulfilled at all times from now on.
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.
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.
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
enfor non-english languages..envfile add the lineAPP_THEME=customand save.themesfolder. Within this create the folder pathcustom/lang/en.resources/lang/en/entities.phpinto yourtheme/custom/lang/en/folder.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 commented on GitHub (Feb 2, 2021):
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 commented on GitHub (May 13, 2021):
@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 commented on GitHub (May 13, 2021):
@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 commented on GitHub (May 14, 2021):
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 commented on GitHub (May 14, 2021):
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.
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?
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 commented on GitHub (May 14, 2021):
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 commented on GitHub (May 14, 2021):
If nobody cares, why change it?
Why do you think open source developers are obliged to act in the interest of users they never asked for?
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 commented on GitHub (May 14, 2021):
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'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 commented on GitHub (Aug 1, 2021):
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
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 commented on GitHub (Sep 19, 2021):
We can't use it unfortunaltely due to "book" and "shelves". What a pitty...We thought this was a KB.
@NSURLSession0 commented on GitHub (Jun 15, 2022):
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:
@Swelidingo commented on GitHub (Aug 31, 2022):
Works like charm. thanx alot
@petr-hybler commented on GitHub (Dec 23, 2022):
thx @Mauricevb
@ajnyga commented on GitHub (Nov 20, 2023):
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 commented on GitHub (Dec 4, 2023):
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 commented on GitHub (Jan 14, 2024):
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 commented on GitHub (Feb 5, 2024):
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?
@ssddanbrown commented on GitHub (Feb 5, 2024):
@Flavelius correct.
@lifewcody commented on GitHub (Feb 16, 2024):
I would like to +1 this as well, since our organization is using those for our documentation.
While we understand the terminology, our specific use case would be better suited with changed terminology.
@gleamland commented on GitHub (Mar 11, 2024):
i think it's the simplest solution for now. is there any update that i missed?
@sand123 commented on GitHub (Apr 28, 2024):
To apply same replacements to browser tab title add this
right before line
Also I recommend change
window.onload = function(){}towindow.addEventListener('DOMContentLoaded', function(){})because first waits for images and static resources loading and old titles blink on screen, butDOMContentLoadedcalled when html DOM is ready and it's much sooner@songokussm commented on GitHub (Apr 11, 2025):
building off of @sand123
Added checks to not modify document text.
@regmeg commented on GitHub (Nov 1, 2025):
This is best done through renaming things in the locale. I have added a zip with the following renames:
"shelves": "categories"
"shelf": "category"
"books": "topics"
"book": "topic"
"chapters": "sections"
"chapter": "section"
To employ it:
I have tested this with Docker Compose, but it should work in every environment. You should figure out the folder locations, where to define env variables yourself, for how you launch the project.
en.zip
@mtcoffee commented on GitHub (Nov 2, 2025):
@regmeg thanks for sharing this! @ssddanbrown has a few demo's on YouTube that covers this topic in full,
https://www.youtube.com/watch?v=gLy_2GBse48
https://www.youtube.com/watch?v=Tf74_2iphz0