Collaborative web version and multiple language of a book

[julichan]

Hello,

First I would like to thank you for this marvelous tool. I can't get away from markdown since i discovered it over 15 years ago and it is much better to write with novelWriter than simple markdown editors.

I was wondering if a web version of the editor was possible or if it would be possible to derive novelWriter to make a collaborative web version. Also it would be nice to have multiple language of a book handled in a single project. We would put two language side by side to easily translate.

I can see two needs here:

• having multiple writters on the project and eventually reviewers.
• working on multiple languages of the same book. I currently do that using multiple instances of novelWritter but I would be better if novelwritter could directly handle multiple languages of the same document.

I am aware of the technological difficulties those ideas would bring and that such features wouldn't come in version 2 of novelWritter or perhaps would warrant an extention project integrating novelWriter.

Thanks,

[vkbo]

Thanks, I'm glad you find novelWriter useful 😃

Making a web version would basically require a complete rewrite more or less from scratch, since the current app is written using a widget-based framework that is not web-compatible. Considering how much time it takes running this project, there is no way I have the capacity to do this. So that would be for someone else to do in a parallel project.

As for collaborative, sync, cloud, etc features, this too is covered in #815 "Frequently Requested Features".

The multi-language part of your request is a different option that could be implemented, although it is technically difficult to handle in terms of multiple spell-checkers. But if you could create a separate feature request for this, I'm happy to keep it in the backlog. I have some ideas how to implement this.

I will close this issue as the collaborative web part will not be implemented in this project, although I'd be happy to assist on a parallel project that uses the same project structure. A bunch of the core classes could likely be ported over.

[julichan]

Thanks for your meaningful insight. I also read the Frequently Requested Features note and i'm sorry for not reading it first hand.
I wholeheartly understand that you are working on novelWritter alone and that is complicated as I tried to make my own web app but found out it was taking me too much time before i explored novelWritter so I understand the limitations you are imposing on your novelWritter developments.

I actually started a a web application which concentrate on book making after trying various and not finding one that have the whole set of features I'd wanted and quickly noticed the amount of work it was.
I take note of your proposal of assistance on a parallel project so I would like to know what you think of this idea: Were I to make a web application using the same project structure as novelwritter and propose an api for it, would you be ready to propose an optional integration of this api in novelWritter ? That way the website i would make would allow for extra features such as reviews, collaborative work, notes and more while the actual book would be written specifically with novel writter ?

PS: I ll create an additional issue for the multi language feature

[vkbo]

I take note of your proposal of assistance on a parallel project so I would like to know what you think of this idea: Were I to make a web application using the same project structure as novelwritter and propose an api for it, would you be ready to propose an optional integration of this api in novelWritter ? That way the website i would make would allow for extra features such as reviews, collaborative work, notes and more while the actual book would be written specifically with novel writter ?

Depends what level of integration we're talking about. I would not want to make the current app a front end for some cloud-like service as I've mentioned. However, being able to transfer the project in an interchangeable format would be an option. I've adapted most of the data file formats to JSON that are capable of being merged into one file. The project file is still XML, but is internally mostly JSON-serialisable.

What I meant, in any case, is that I've been working towards separating the GUI part from the core/data code internally in the app. This means that it is possible, at least in principle, to slap a new frontend on the core functionality of novelWriter. Most of the core code is in the novelwriter/core folder. Non-GUI code will also be added to the novelwriter/text folder for text processing. The core code includes all project structure handling (storage, project wrapper, project data, tree structure, project items, document wrapper) various tools (document merge/split, new project creation) and text processing (tokenizer, and html, odt, markdown writers). Pretty much all that involves the project content.

[julichan]

I would not want to make the current app a front end for some cloud-like service as I've mentioned.

Which is why i was mentioning "optional", i meant eventually configurable on the project. but I understand your point.

However, being able to transfer the project in an interchangeable format would be an option

I'm not sure this would fit with my idea as I want to leverage a versioning system to collaborators who won't understand them. I wanted to provide a load/save api that would leverage git and fix the conflicts as automatically as possible since the api would be fully aware of the format but I have yet to try how that goes.

I may have to do some research before i can propose something that suits both our needs or just try to fully integrate the non-ui part of novel writter into a new app but that remains a lot of work.

As a side note, is there a plan for plugins on novelwritter ?

[vkbo]

I may have to do some research before i can propose something that suits both our needs or just try to fully integrate the non-ui part of novel writter into a new app but that remains a lot of work.

My point is that of the functionality and syntax of novelWriter is what you'd like to use, and the GUI is anyway non-transferable to web, then I'd be willing to collaborate on tailoring the core code to work in that context. Possibly even packaging it into a library. The web service could be running on Python and Flask and serve the data through an API for instance.

I'm not a (web) fornt end dev, so I can't help much on that front. But I do a lot of Python back end work.

As a side note, is there a plan for plugins on novelwritter ?

Yes and no. I'm considering a framework for writing text analysis tools so that it is easier to contribute them for specific languages and methods, but it would be more of a module framework rather than a third party plugin/extension framework. Also, text analysis just needs to be passed a lump of text to analyse, so the internal API is relatively simple.

A more integrated plugin framework would be harder to develop and maintain. I suppose the lowest hanging fruit is a framework to replace the storage class with an API wrapper, which could work for your case. I wrote the storage class as a passthrough of all I/O so I can implement #977.

[julichan]

I'm not a (web) fornt end dev, so I can't help much on that front. But I do a lot of Python back end work.

I'm have absolutely zero experience in python and i would never make anything secure without many years of experience if i worked my backend in python. Plus i would postpone my other projects if I went that way. haha. Those tools are for our primary projects (for me a book and a visual novel) so going too far is out of the question for either of us. Either way, a web front end has many limitations and is only written in html/javascript/css. I could never import a python package in the front end and that a front end code would be necessary for performance reasons (MD to HTML parsing in the backend for exemple would be out of the question). So I'll save you the trouble of making a python package at least for my ideas. Just for the info, i work my backend in C# aspnet core and my front in vuejs.

I suppose the lowest hanging fruit is a framework to replace the storage class with an API wrapper, which could work for your case. I wrote the storage class as a passthrough of all I/O so I can implement #977.

I took a look and also found #383. This lead me to two ideas based on what your said:

• Version Control #383 might already do what i need if you intend to work on it. I could just expose a git api and our applications could just work together without the trouble of compatibility: the requirement of knowledge of git would be leveraged but that would depends on how far you intend to push git integration.
• After reading Version Control #383 and Single file format (again) #977 combined with an API wrapper replacing the storage class, i could completely get rid of git conflicts by making an api that editing file live on the backend while keeping the format novelwritter currently use. However for collaborative work on novelwritter, i would need the following:
  • the modification of a node would require either one of these two features:
    • to ensure that the api wrapper would regularly try to detect a remote change and aquires it before performing a file update but that could lead to performance issues if the constraints are not well defined.
    • to ensure the locally opened file we want to update is remotely write-locked to the current user and recognize that it can't modify it until it has been released.
  • The add/move/remove actions can be managed by the api when the project file is sent and compared with the old version so all it needs is that those modification are saved on the spot.

The last solution would also be a way to partially implement #383 (I could provide an api for the diffs and history if going through the api wrapper is enough for you) and add collaborative work directly to novelwritter while solving my problems.

Well, I'm waiting to see what you think of this. what do you intend to make your api wrapper able to do ? and how configurable ?

[julichan]

Just forget what i mentioned. I realised that my idea wouldn't work when working offline. Replacing the storage with an api wrapper wouldn't be a solution for me. I need to think of something else. ^^