mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-05 00:29:48 +03:00
Feature request - Content localizable #478
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 @AriasBros on GitHub (Oct 24, 2017).
Desired Feature
In my organization we need to have our content in several languages.
Do you have in your roadmap implement localizable content?
Current Behavior
In this moment we can create books/chapters/pages in the languages we need, but translations have no connection to each other and all content in all languages appears to the user.
Expected Behavior
Would be fantastic if only the content in the current language of the user is shown, with links to the available translations and fallback to the default language if missing translation.
If you have not planned this functionality yet, I would like to collaborate with you by implementing it.
@ssddanbrown commented on GitHub (Nov 7, 2017):
Hi @AriasBros,
Thank you for your suggestion. This is currently not on the roadmap as it has not been requested before.
To be totally honest this is quite a chunky feature that will require maintenance so I'd be apprehensive about including this without a very high demand.
@AlexWerz commented on GitHub (Nov 21, 2018):
I plan to use BookStack to add books in multiple languages. The user can then decide which language of the book (in my case manuals) he wants to read. This makes updates easier as they often just need to be translated from the english master.
As this is not a feature (yet?) I plan on using tags to set the language and book shelfs to organize languages. Are there any other approaches currently used for maintaining different languages of the same book?
@Drakone commented on GitHub (Dec 6, 2018):
COmmunecter aimerait également pouvoir proposer sa documentation en plusieurs langues : doc.co.tools.
La solution proposée par @AlexWerz est intéressante. On va essayer.
@Orchal commented on GitHub (Dec 11, 2018):
Hi,
I'm also very interested by this feature as I work in a public research organization which is international.
Sure we can use tags and double all the pages but it would be very nice to have a language switch somewhere and only have one language displayed at the same time.
By the way thank you for all your work, this is pretty good!
@lreiher commented on GitHub (Jan 2, 2019):
I also want to express my need for a multi-language wiki. Of course most of us understand English nowadays, but it would definitely help a lot if certain pages could simply be read in your preferred language with English as the fallback.
Thanks for all your work so far!
@TobiasDax commented on GitHub (Mar 2, 2019):
Any updates on this? Is there a roadmap for this feature?
@ssddanbrown commented on GitHub (Mar 2, 2019):
@TobiasDax I'm afraid not, no updates and this is currently not on the roadmap.
@p2kkx commented on GitHub (Aug 22, 2019):
First of all: Thanks for this amazing software! I really love it!
I also have a need for a translation feature. I write manuals with BookStack and would make my life so much easier.
You said it will be hard to implement. Maybe starting with a "lite" approach would make it easier.
What I mean is e.g.:
1.1 Click on create translation
I know it will be hard to deal with updates, this would require more complex code. But with this solution at least the pages are directly connected to each other and I can switch between them. And other editor will instantly see that there is another translation that needs to be updated. In the bookshelf he will forget about that.
@Drakone commented on GitHub (Aug 22, 2019):
Here is the method I used while waiting for the new feature: : https://doc.co.tools/shelves
@p2kkx commented on GitHub (Aug 22, 2019):
@Drakone so you basically have two shelves for different languages or did I miss something? As I wrote having multiple shelves / books is not really what I want because it makes it hard to connect the single pages directly with each other.
@tgraveleau commented on GitHub (Oct 4, 2019):
Hey,
We have customers from different country and we would appreciate this feature too.
Hope it will be available.
@tcatlas commented on GitHub (Dec 7, 2019):
Our organization has a need for this. Throwing in my hat for support.
@ferranrego commented on GitHub (Oct 15, 2020):
Hello! I think this could be an amazing feature to have, as Bookstack could work also as a Help Center. I would love to see it for my project, any update on this? Did you reconsider adding this feature on the roadmap?
Thanks!
@Ombrelin commented on GitHub (Nov 2, 2020):
Hello, I love Bookstack and I second what was said : translatable books would be a great new feature
@gagarine commented on GitHub (Dec 25, 2020):
We are publishing free school book. We are using automatic translation to make them accessible to a wider audience. We are looking to a new platform but content translation at the page level is a must. One viable option at the moment seem Drupal but it will require lot of customisation.
@digitall-it commented on GitHub (Feb 21, 2021):
You guys are incredible. Thank you.
@dhigby commented on GitHub (Mar 1, 2021):
We live in a multilingual world. I love the BookStack app and experimented with the demo site. It is a great solution, one of the best I've seen, but I can't go with it because my Book/manual needs to be kept up to date in between 2-7 different languages.
@ssddanbrown commented on GitHub (Mar 2, 2021):
Just to re-confirm my position on this, since it's been a while:
I appreciate this would help out a bunch of different use-cases, but it would be a fairly bulky feature to implement while being hard & time consuming to work this into the platform in a manner that does not hinder the user-experience of existing non-multi-linugal use-cases. Additionally, the kind of changes this would entail would have an ongoing dragging cost on future further development.
I was recently approached by a charity that wanted to use BookStack, with this feature being a requirement; and while I really wanted to support them by looking to implement this feature, I could not warrant the cost it would have, at least at this point in the project's life.
@SubJunk commented on GitHub (Mar 12, 2021):
I would be very interested in this as well. If I contributed a Pull Request to make a version of the feature, would you be interested, or still no?
@ssddanbrown commented on GitHub (Mar 12, 2021):
@SubJunk thanks for offering but likely not due to my concerns above.
@soflane commented on GitHub (Dec 20, 2021):
First, thanks so much for this amazing soft! I'm starting using it as much for my work and personal life. I came from wiki.js and bookstack is way better for my usage, and for an internal doc use In a business. But indeed I had translation in wikijs and it's kinda a pain in the ass where I have different books with plenty of pages to manage. I would looove to have this feature implemented, as I already love this app and I will use it everyday more!
Big up for this soft!
Peace, love & unity ✌️
@AliShaatani commented on GitHub (Dec 27, 2021):
thank you for this awesome piece of application,
but, as you can see, you can't use it, as an official knowledge base section, without multi-language selection
since the public visitor may want to change language, in certain places like technical documentation, where you need to use universal language, which is English in this case, and other languages in places like help and how to
@a-mawlawi commented on GitHub (Jan 13, 2022):
Thanks to the maintainers for this great app, and I vote for the multilingual feature also.
+1
@ssoulaimana commented on GitHub (Jan 31, 2022):
+1 for multi language support in Bookstack.
Thanks
@jasell commented on GitHub (Feb 13, 2022):
+1 for multi-language support and easy/predefined integration to translation management system (like Crowdin or other).
@robertfshort commented on GitHub (Feb 24, 2022):
+1 for this feature
@ffranchina commented on GitHub (Feb 28, 2022):
Hello everyone! I was about to open a feature request for a kind of relatable feature but I thought that maybe would be better to ask here first and, in case, discuss it.
Proposal
From the perspective of the semantic web it would be quite nice to be able to specify the language of a single book though the attribute
lang(https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/lang): it can improve the indexing and the accessibility of the resources and it can be useful also for retrieving the resources in an automatable way.Such change should be quite easy to implement since it is just an additional attribute to store for every book and could be shown only at html-level (for elements that are
data-entity-type="book", for instance).Such feature could also be implemented in a less invasive way though the usage of the already implemented tags but it would require anyway some custom logic in order to place the respective
langattribute in the html.Extensions
Having such feature implemented could also open to some interesting scenarios:
Conclusions
I think this would be a valuable addition by itself, but can also be seen as starting point for interesting scenarios. I think I will end up implementing such feature by myself but, if welcomed by @ssddanbrown, I would be very happy of implementing it according to his view of the project!
Thanks!
@ssddanbrown commented on GitHub (Feb 28, 2022):
Hi @ffranchina, Thanks for putting forward the idea. From my perspective I'd rather crawl towards a fuller solution than sooner implement a half-solution that does not have direct and/or clear usage/benefit within the system itself. I can see how your proposed idea may help in some scenarios but I try not to implement features based upon possibilities or opening interesting scenarios, Instead I try to focus on fundamental desires that fit the usage of BookStack and the vocal desire is proper multi language page support.
If your proposal would help you at the current time, I believe this could be done with tags (as you mention) along with the visual theme system to apply the
langtags where required. If you'd like some further guidance on that feel free to open a new issue.Just to state my updated view on this, since it's been almost a year, I'm still aligned with my previous view but there's a potential chance I may soon transition to work on the project full time and hence it may be more feasible to include. Either way things go, page-translations will be in mind when making other fundamental changes to slowly get us moving towards the feature, or at least not fully block us off.
@jasell commented on GitHub (Feb 28, 2022):
What are your plans for managing the translations? Do you plan to integrate with existing TMS systems, like Crowdin? Or are you planning to build your own translation support?
I spoke to Crowdin and they are happy to support as they wish to see more platforms integrating their support (as they gain business from that).
@ssddanbrown commented on GitHub (Feb 28, 2022):
I have no specific plans for that. The primary goal would be multiple languages per page in the current editor experiences. Automation outside of that would probably be delegated to API use via external apps/middleware. Doesn't make sense for us to support specific translation services/platforms.
@jasell commented on GitHub (Feb 28, 2022):
I would agree that every page would need its separate "copy" in other languages. I would not publish the translated version nested with the original language. I would make parallel books, or bookshelves in your case (i'm not sure what make most sense). As a user would not jump between language versions when consuming the book. They typically have a preset for what language they wish to use.
So when storing each book I would use a folder for each language high up in the hierarchy. In your TMS you decide for a which languages to offer. This system will monitor the original language and make a copy under a new language folder. If there are additions or changes to original the TMS will see that and copy those to the translated folders.
The TMS would track what is translated and also approved so you can present a status or offer a threshold how much need to be translated before you publish. i.e. it could be ok if 99% is translated for the remaining 1% it would show the untranslated original text.
This way I think the effort on your side could be kept at minimum. On the publishing side you need to provide a GUI for selecting language version, you would also need to offer some official language tags so systems can chose automatically based on the users "locale". You would need to figure out the integration to the TMS, how the TMS can read and scan your sql storage. And how the TMS can add a new language and write and update the translated language version.
I assume that the images would be the same for all languages versions, so only one assets library to serve all language versions.
With TMS I think Crowdin could be a good start, you already use them for localization of the Bookstack application and they seem to be willing to help out in doing this. I have no relation to Crowdin by the way, I'm just trying to build my toolchain for translating my GUI and Guides. If Bookstack and Crowdin where integrated this would have solved my needs.
@jasell commented on GitHub (Apr 4, 2022):
We are still very much interested in a solution like Bookstack but we require content translation support.
Can we some how help to make this happen?
What would be your preferred option to get this moving?
Can Bookstack use GitHub for storage? If so many translation system already have integrations to GitHub.
Short outline what needs needs to be done...
(I'm not a developer so I might got some things wrong here...)
Would storing texts and images on GitHub be a solution?
Either so the user can select themselves or language is specified on the URL when calling bookstack.
@ssddanbrown commented on GitHub (Apr 4, 2022):
Hi @jasell, Thanks for offering support.
Just to quote and re-iterate the statement from my previous comment:
So I would consider any TMS/external-system-support outside of the scope of this issue. Maybe that could be requested afterwards, once we have the multi-language infrastructure in place, but It's likely I'd still consider that specific solution out of scope of the core project at that time since platform-specific support does not make sense in terms of maintenance and efforts, it's better for us as a platform to focus on providing the API for abstract usage.
To be honest, neither. Someone else developing a feature so wide will likely just guilt me to force focus of my efforts.
As I've touched upon in previous comments, It's not so much the implementation but also the long term impact of such a feature, relative to the demand. Potentially some commitment of ongoing financial support could help, but I'm not sure how to officially formulate that, I may have to explore similar circumstances in other open source projects.
Since my last comment, I am now aiming to work on the project full time, and that's my current plan, which makes such a feature more viable to proceed with. It's now just a case of why this feature should take priority over any other work, especially for it's impact.
@jasell commented on GitHub (Apr 17, 2022):
@ssddanbrown, Thanks for elaborating on your reason.
So if we decided to make such integration, we still depend on some support on the architecture. As how translated pages are stored. Page by page, book by book or shelf by shelf.
Most likely all language versions will refer to the same resources, etc.
Would you be willing to look into this?
I asked before, would GitHub be a candidate for storing the content during editing? That would simplify integration with TMS system as these often has an integration to GitHub.
@ssddanbrown commented on GitHub (Apr 17, 2022):
@jasell
Yes, that's the entire idea of this issue and my comments in regard to working on this are in the last paragraphs of my previous comment.
No, As I stated above multiple times I would not look to support specific external platforms in the scope of this issue/feature. You would be free to use GitHub in your own translation pipeline/process (Via connecting with BookStack APIs or extension systems) but our focus would be the core system and the provision of a generic API for any external usage.
@BashTec commented on GitHub (Apr 21, 2022):
Hi together,
first of all many thanks for this great project!
For scientific and research institutes in Germany, the lack of multilingualism is unfortunately an obstacle for widespread use.
We would love to see this feature and I think it could significantly drive the adoption of BookStack.
@keyhelp commented on GitHub (Apr 26, 2022):
Hello!
just came here to thank you for this great software!
I would also highly appreciate the feature discussed here ;).
Right now I'm using different shelves to manage different languages.
That's fine, as long as the user
Nice to hear, you may have time in the future to implement such a feature! Keep up the fantastic work ;).
@angevi commented on GitHub (Nov 22, 2022):
Is there an update on this issue? There is strong interest from three different sister-social enterprises here. The need arises from countries with more than one language. Creating knowledge bases in several languages is an issue of social inclusion.
@jasell commented on GitHub (Nov 22, 2022):
We are still open for this and can contribute with either money or time.
I would suggest an integration to Crowdin, as that tool is already tied to BookStack for translating the UI.
@rmibelgium commented on GitHub (Nov 30, 2022):
Same interest on the side of our organization. We're continuing to analyse how we could do that with Logical Theme and without forking the code.
@Silverlan commented on GitHub (Dec 23, 2022):
I would also like to express my interest for this.
Artificial Intelligence has become exceptionally good at translating lately and all that's stopping me from using that to offer my wiki in a bunch of different languages is the lack of this feature.
@2-click commented on GitHub (Feb 13, 2023):
Honestly that feature would be so great
@jasell commented on GitHub (Feb 14, 2023):
@ssddanbrown would you have time to share an update on this topic?
Seems like we are a several who are interested in this and we can probably contribute if you can put forward what could help you prioritize this request, whether it is funding or development resources?
@ssddanbrown commented on GitHub (Feb 14, 2023):
The primary blocker for me, as alluded to in my previous comments, is the lack of motivation for what would be taking on a significant amount of technical, maintenance & support dept in the system complexity this would add.
While funding would help that motivation, it would really need to be long-term funding since the costs are long-term. While I've had several offers from businesses in funding this feature now, I've never had a single actual figure put forward, since most seem to act like this is a one-off business transaction that they want a deal on.
While I'm very grateful @jasell that you have offered funding and resources, I've been hesitant to inquire further since within this thread you have seemed to misunderstand the direction and scope I'd want to take for this feature. I have responded above three times that external systems would be out of scope for this core request, and you have still requested that since.
This (The core feature, not external platform support) is still something I want to implement, I just need to find the right moment and motivation. Might not be too far as I look what add next in the roadmap. The initial move will probably be me starting threads, and linking them here, to ask questions on usage and/or put out initial implementation proposals for feedback.
@jasell commented on GitHub (Feb 14, 2023):
Thanks for sharing your update @ssddanbrown .
We are willing to discuss either a one time fee or subscription for this, whatever could motivate you do this.
My need is a support for authoring, translating and rendering of my guides. I see bookstack currently supporting two of these three needs.
My suggestions on external system was an attempt to reduce the work on you, but that is not a requirement as long we can get the toolchain/pipeline for the three needs mentioned above. To me it seems that building a complete TMS is harder than making a stable integration to an existing TMS. As you already have a TMS integration for your own UI I naturally looked at that as a first option. But if you wish to provide a TMS as part of bookstack I see no problem to use it, but it appears as more work and responsibility for you.
If you are not considering this during foreseeable future, would you consider to draft some guidelines on how an integration to a TMS would work? As you know some about TMS (as you translate your own UI) and you are the one with the best knowledge of Bookstack and its API.
I could think of to setups, you tell which the better option:
One benefit of using an external TMS is that we can use it for our own UI as well (we currently use Crowdin as you do), then the translation memory can be shared across the Guides and UI, as I assume your TMS would only support your guides.
@ssddanbrown commented on GitHub (Apr 9, 2023):
Hello everyone 👋
I've been doing a fair bit of thinking on this recently.
I was going down the road of changing a lot of our data structure to support language variation, but as I went deeper the added complexities seemed to make less sense and be less worthwhile as they built up, and this led me to think I may be approaching this in the wrong way, thinking about technical implementation first over the fundamental requirements & needs here, and that there may be simpler alternatives to explore that would be better overall.
Therefore, to held explore options, I'd like to approach this at a different angle with the help of feedback from those that desire this feature.
So here's my question to you:
Right now it's technically possible to service multiple languages through copied/duplicated content, like having separate books for different languages. Compared to what you need (and by that I really mean only what you need, not what you think might be good or what might be "interesting") how do existing options like that fall short?
Please think about your answer only in respect to user possibilities, goals and outcomes rather then thinking about a specific technical implementation you may desire.
As a pre-emptive reminder: external platforms & translation management systems, outside of our existing standard REST API, are out of scope for this conversation.
@angevi commented on GitHub (Apr 9, 2023):
For a simple book with max two permission levels and max. two languages, it is no problem to have two books. It becomes complicated to manage several books when: 1.) The permissions are more complicated, 2.) The end users switch between languages to better understand, 3.) There are more than two languages. It becomes higher specialized and knowledge bases in organizations need to be easy to use/easy to access/ easy to manage. Especially when employees are diverse in age, background, language.
@jasell commented on GitHub (Apr 10, 2023):
Thanks for looking into this!
I haven’t looked into all you can do with API:s, so I might go out bounds here, sorry about that.
We are documenting our software, Guide is the primary assets, but there is release notes and additional way of working content and other value adding information.
I could guess for every language the system generates a new bookshelf with books in the new language. Our translators will then translate and publish when done.
Our users can select a language through their personal settings and will have read-only guest access.
Authors and translators will have a dedicated login. We don’t need to control which books or languages they can edit/translate, but it would be a bonus if we could.
We have a lot of illustration which we don’t intended to translate, so I would like all translated “copies” to use the same picture library. It should be nice, but no must, to replace some pictures in the translated versions, but that would be an exception.
What I understand since before, your plan is to build a “complete” translation management system, rather than provide a default integration to an existing TMS, like the one you have for the application. That is ambitious, we are happy with either solution.
@Tagirijus commented on GitHub (May 3, 2023):
I hope I understand it correct that you ask, what would fall short, when basically doing some kind of "workaround" for the multi-language-content by e.g. copying a book. A user already mentioned some points, which I can second:
Booksas well. So it would list languages the user might not understand and if they understand it, it would basically "double the content" in the end.This comes to my mind offhand.
@ASparwasser commented on GitHub (Jun 30, 2023):
I would really appreciate this feature!!!
@jessicakuijer commented on GitHub (Jul 6, 2023):
me too please!
@beeing commented on GitHub (Jul 21, 2023):
Hi, just my 2 cents:
The feature needs to address usability for both the authoring / editor and viewer. The technical implementation need not to be complex as most of the time, it is more towards UI.
For authoring side, usually we need to know the last updated date/time of the related pages (same page, diff language). This will help authors to see if some pages need to be updated for different languages. For a simple "diff" UI on the pages, we can just place 2 pages side by side on independent scrollable iframe / divs.
To ease the page configuration (permissions), the rest of the linked pages can be in-synced with the parent page, where all settings to be based on.
As for viewer side, they just need a language selector (can be in header / footer), which will show available languages for that page. Navigation to another page will remember the current language and if the destination does not have the language, it will fall-back to the primary page.
Hope that this is something doable and this project looks awesome!
Have a great day.
@Man-in-Black commented on GitHub (Sep 14, 2023):
I also am very interested in this feature, but I also can understand the concerns about it.
But maybe there is a "simpler" solution to that.
Since automatic translations gotten better and better over the last years (imho), maybe it could be a compromise to use the builtin translation of nearly every browser nowadays.
So each user can translate the content to whatever language he needs.
The only thing which should be added for wider use would be a button somewhere in bookstack which translates the content to the desired language or at least opens up the menu from the browser.
I also know that this is not perfect, but its better than nothing.
@jasell commented on GitHub (Sep 14, 2023):
We tried using Chromes built in translation for both our software and the online guide but the result was far from acceptable, some laughter though. We seen better result when trying some AI-tools.
The challenge lays in the special terminology, invented words and abbreviations, we wish to translate from English to Japanese and Chinese...
@jeansanson commented on GitHub (Oct 18, 2023):
I am also interested in this feature.
@hieste commented on GitHub (Oct 25, 2023):
Hello @all,
Here is a smooth opensource solution:
https://github.com/LibreTranslate/LibreTranslate
Perhabs it is a possipility to do a post-hook event and translate the content...
@jasell commented on GitHub (Oct 25, 2023):
Have you made any attempts to integrate this with Bookstack?
@hieste commented on GitHub (Dec 7, 2023):
Yes. We install an local instance of libretranslate on a powerfull host. We wrote a programm to get all pages from bookstack step by step via rest api and check if there was an update. If yes, we remove all html tags and put it to libretranslate via rest api (we translate to 3 languages: German, French, Englisch). The response, we put in seperate tags in bookstack with the key of the language. So you can search in the language you want.
@LHBL2003 commented on GitHub (Dec 7, 2023):
I also carefully read through the article from 2017. I also agree that Bookstack needs a multi-language function, as we and many others are working together more and more globally. A good variant would be like Microsoft, where either the content is available in x human-written languages. Or if it was only written in German, there should be an info in the English page that this page was automatically translated from the original language. When searching, the pages should first be displayed in the preferred language and then in other languages.
I even like the option of using the Google translator to start with. However, for reasons I can't yet explain, this is not possible. I have read here that it has already been used. The Chrome translation is neither suggested locally nor in the demo version of Chrome. Does anyone have any idea why this is the case or does it work for others?
Greetings from Germany, where the global English language is not omnipresent.
@szabeszg commented on GitHub (Dec 7, 2023):
That reminded me of this: https://processwire.com/talk/topic/24567-fluency-integrated-deepl-powered-content-translation/
Which is a good example of how others are dealing with issues like this.
@cgsmith commented on GitHub (Jan 3, 2024):
I would like to offer a possible solution. It definitely requires a big change. Here is how I would go about the changes:
jsondatatype. Store localizations as JSON for name fields or small fields like descriptionlocaleto the page entity.Maybe set a setting for a fallback_locale under settings. That way if a route doesn't exist with the locale the fall back will be present.
I think technical debt is fairly limited with a proper test plan and unit testing. I also think automated translations and outside integrations are outside of the scope.
@quirkiest commented on GitHub (Mar 18, 2024):
We are a multi-lingual company based in Japan and Australia. As I see it the challenge, from an admin perspective, is that maintaining content in separate places (e.g. books) means that the synchronisation becomes very manual and very likely to fall out of sync quickly. So while a translation solution does not IMO need to be super-complex, it does need to have some way to allow admins to manage the same content in different languages holistically.
One idea that occurred to me was that perhaps this could work well in-page tabs, which would be a feature not exclusively aimed at translation but which could take us a lot of the way there. If we can manage both our Japanese and English content in the same document (page) and have some way for users to flick to the version that they can read it would (at least for our company) be a really nice feature. And I figure tabs are a cool feature to have anyway...
P.S. in the meantime we are using collapsible blocks - not an awful workaround tbh.
@carlossierra311 commented on GitHub (Jul 31, 2024):
Hi @ssddanbrown. I'll try to provide some feedback for one of your questions:
The problem we have found with this approach is that when we copy the original book, all hyperlinks on the new book will point to the original book's pages (i.e. to the original language book instead of the translated language book), so besides translating all our text (which is expected), we also need to rework all the hyperlinks (which is unexpected). (By the way, is this the expected behavior, or are we misusing BookStack?)
Best regards!
@vmario89 commented on GitHub (Oct 11, 2024):
i was looking for the same feature of localization too. Changing the ui lang is cool, but it does not help for anything if the content itself is not in the language, the user excepts to see. the only scenario would be to have different shelves for differen languages, yes. but if we want to translate content 1:1, this is really not maintainable
btw. my motivation for thinking about all this: doing a documentation with bookstack for a large open source software project for an already existing community, which is spread accross europe.
i was thinking about doing some stuff like hosting
... sharing the same database of users, groups, etc., but have some kind of master database which means we cannot create or modify new users or groups in all other databases
... with an environment which is fixed to the certain language, so ui language = content language
... synchronizing page ids and other table related stuff, but storing the different language content per page in the certain database
caveats would be:
@Lord-KalEl commented on GitHub (Nov 30, 2024):
Hello to everybody and espacially @ssddanbrown
I know, that this could be a little complex, to do, but as you see, there are not less people, who want this feature.
I, personally, don't like PHP and I wanted to get rid of it. But I choose Bookstack, because the idea and the features are really great. There are 2 things I'm missing:
What can be the solution?
At first, we can make a variable, witch language it is. This will be stored in the url, after the domain. E.G. bookstacks.org/en or bookstacks.org/en_US … this depends on you.
As now, every Object (Shelves, Books, Chapters, Pages, Images and so on) has an ID - you need to store additionaly the Language_Code AND the Original_ID. (you will store always as foreignkeys the Oringinal_ID when you connect the shelves, the Books and so on together).
The Primary Key is the ID,
The Original ID and Language Code are Unique …
With that Chance, you won't have to rewrite everything … but you can use this, to add a feature, that that can easily expand …
For example:
If you don't want to change much things … you can show every book, ervery caption, every page and so on by making a select WHERE the ID is …
If you like to extant that, you can make some great charts, witch language is used more, bind up an KI to translate it automaticly and so on …
I don't think, that this will be easy … but I think, that this is very usefull in our nower days …
Thanks for reading. And maybe we will have a good announcement …
Have a good before Christmas time …
Kal
@BartoszStepien-3DArtist commented on GitHub (Feb 21, 2025):
Hi @ssddanbrown. First of all, thank you for the software. It is great. I join the request for multi-language support. +1
@ssddanbrown commented on GitHub (Apr 17, 2025):
Please don't add any +1 style comments, they add noise and notification, so I will delete them. Just add a 👍 reaction to the original post instead.
Just an update on this request, I have recently spent a while thinking through options again.
The more I think about it, the more it makes sense that this is managed via multiple instances instead of at the same instance, since that allows a lot of flexibility without adding a lot of the BookStack level complexity required.
Of course that may be more burdensome for smaller scenarios, but it's tricky to judge where on the scale the average scale of desire for this sits relative to that burden.
Regardless, a multi-instance setup would still require a fair bit of built in helper logic & UI to solve many of the challenges noted here in comments; Things like language switching control, cross-lang content sync/comparison/referencing etc...
Then there could be extra challenges of a multi-instance setup, upon the maintenance/management of multiple instances. Things like permission management and user management (which could be partially helped via SSO).
A tricky factor is that the best approach can change quite a bit depending on needs, user-approach/desire and scale, hence I tend towards a more flexible yet higher burden implementation.
I've kinda burnt myself out thinking about this for now, but will try to ruminate upon this potential approach/direction.
@jasell commented on GitHub (Apr 17, 2025):
Thanks for the update!
Can you share anything about the timing, to manage our expectations?
Does this mean it's on the roadmap and will happen within a year or is this a next millennium thing?
@ssddanbrown commented on GitHub (Apr 17, 2025):
@jasell Can't promise anything on timings. History would suggest that it won't be this year.
I usually cycle through ideas & requests, then rapidly proceed if I see a viable/suitable implementation path forward, hence no longer term roadmap. I checked in on this as a highly requested feature, to potentially implement for the 10 year anniversary of BookStack, but burnt out on it while planning, so will just have to cycle back in the future, probably after thinking though the path described above in the background. That might be later this year, or might not.
@Superjamp commented on GitHub (Apr 17, 2025):
thanks, too :)
I understand that adding this feature after the fact might be really tricky. I haven't looked at the code in detail, but I think you know best how much time and headaches it will take to do so.
It is also definitely a challenging task for content creators to implement books in a [n] instance approach and for the organization to keep multiple instances with roles and permissions on par. Synchronization between instances could probably be achieved with a few scripts. An easy workaround for content creators today would be to structure their books using tags and/or using tags in their titles. (but messy)
From a user perspective, I'd like to have the content when it's available in my browser or preferred language. Then the content creator has to update both, and that's where it starts to fall apart if they forget to do so. Maybe there can be a feature implemented to allow the content creator to translate / update the localized page in a desired language with DeepL for example.
But now everyone knows that most browsers will try to translate the page for you... except for media content. And it is highly questionable whether localized content in this Project is really a necessary feature, given the current effort required to implement it.
In the context of a university using BookStack, it's a very necessary feature especially for international students.
And we (TU Braunschweig) are very interested in this feature request to get a good working implementation in BookStack.
Personally, I don't mind having only one supported language, it's perfectly fine for the scope of this project.
@jasell commented on GitHub (Apr 18, 2025):
We tried this, but at least google's translation is far from good. We use bookstack as a guide for our software. Our software is highly specialized with a rather unique terminology, hence the need for the guide.
If google would offer a way to suggest corrections to its translation it might solve the problem and also improve the translation capability over time, but google doesn't want to allow this for some reason.
@quirkiest commented on GitHub (Jun 19, 2025):
Multiple instances sounds complex and disconnected, to be honest. Perhaps the result could be achieved with a much more modest UI component change, similar to the existing accordion. If we could include a tab-type control which allowed formatted content inside then you could store each language's content for that section/page etc inside an individual tab. The tab UI feature would possibly be handy for a lot of other things, too.
@Hexodus commented on GitHub (Jun 24, 2025):
I'm a bit late to this party but anyways. My first thought was:
Careful with language features! They can cause complexity to explode and introduce rigid, fragile structures that only a few users actually need – and that end up being a pain in the ass for the rest of us.
IMO, Bookstack is great because of its flexibility, so whatever we do, the solution should be dead simple. Something that opens up new possibilities without requiring deep changes. That means no full-blown localization or translation, AI or not – those are too specific and hard to implement.
Instead, I’d use the content tag system to mark the language of content. This should be inherited down the hierarchy – so a book tag like locale: en would also apply to chapters and pages, but could still be overridden at any level. Then just stick a flag icon next to it for visual indication, add a clean language selection dropdown, and that's it.
That alone would be super useful for me. I wrote an extension that lets me drag & drop citations from Zotero, and I need a way to determine the language so I can adjust the link content accordingly. Right now, there's no good way to do that since tags aren’t inherited.
@Lord-KalEl commented on GitHub (Jun 25, 2025):
I've an other opinion …
Language features are very helpful to bring people together, that have an other language. There are always workarounds and this may be for you a good idea, to use it. But if you want more, than only to supply your "people", than a good implemented feature like "language" can be helpful for many people.
In modern "wikis", this feature is standard … the question is, why should we don't implement this and make this "wiki" to a better version? Not only technically, but also socially …
If you are implementing this in a wrong way, you're right. But if you do ist right, you don't have too much trouble with it.
First thing is, because you mentioned it:
If this ist implemented, than the biggest thing is done (except, when there are some workaround, which are not standard …)
Next thing is to implement dates-, timeformat and so on … but this is second, third … steps …
First step is to save the language tag with every data you store …
@add-n2x commented on GitHub (Jun 25, 2025):
I've successfully implemented BookStack now within two non-profit organizations. One of them, our community radio station, has some big need for multi-language support.
Is there an update on the roadmap for this feature? We offer you to send you a free t-shirt, if this feature could be implemented at some point. 😸
Thanks for all of your great work, Dan!
@aliozgur commented on GitHub (Oct 6, 2025):
Not an ideal solution, but below you can find a script which utilizes Translator and Language Detector APIs
The script;
NOTES:
Code