Integrating a Morse Code Translator Workflow with ONLYOFFICE Docs

I run a Morse Code translator website that converts text to Morse code and decodes Morse back into plain text using JavaScript, with features like real-time conversion, audio playback, and easy copying of results. Recently, I’ve been exploring how to integrate this functionality into a document workflow using ONLYOFFICE Docs, such as allowing users to encode or decode text directly inside documents. However, I’ve run into several technical questions about how feasible this is within the ONLYOFFICE ecosystem.

One of the main challenges is implementing Morse code translation inside the document editor itself. Ideally, I’d like users to select text in a document and instantly convert it into Morse code (or vice versa). I understand ONLYOFFICE supports plugins and macros, but I’m unsure how to structure the translation logic within that environment. Since my current translator relies heavily on client-side JavaScript and real-time input handling, I’m not sure how well this approach maps to ONLYOFFICE’s plugin or scripting capabilities.

Another issue is real-time interactivity. My Morse Code tool updates instantly as users type, but document editors like ONLYOFFICE are not typically designed for continuous live transformations of text. I’m wondering whether it’s possible to simulate this behavior using event listeners within a plugin, or if the expected workflow is more batch-based (e.g., select text → click button → transform output). I’d appreciate clarification on what level of real-time processing is realistically achievable.

I’m also exploring how to handle audio playback of Morse code within ONLYOFFICE Docs. On my website, users can play tones representing dots and dashes, which is useful for learning. However, I’m not sure if ONLYOFFICE plugins can reliably trigger browser audio APIs or if there are restrictions when running inside the document editor environment. If audio is not feasible, I may need to rethink how to provide a similar learning experience.

Another concern is document compatibility and data persistence. If Morse code text is inserted into documents, I want to ensure it is saved and displayed consistently across different formats (DOCX, PDF, etc.). I’m unsure if there are any encoding or formatting limitations when working with dot-and-dash sequences, especially when documents are exported or opened in other editors outside ONLYOFFICE.

Finally, I’d appreciate guidance from the ONLYOFFICE community on best practices for integrating custom tools like a Morse Code translator into document workflows. Should this be implemented as a plugin, an external service, or a hybrid approach? If anyone has experience building plugins that extend document functionality with custom logic, I’d love to hear what worked well and what limitations I should be aware of before investing further time into this integration. Sorry for long post!

Is there anyone who can help me?

Hello @joeroot

Firstly, I’d like to mention that this integration sounds really interesting from the editing perspective in a document processing app. I will address some of the key points of your query down below.

Plugins are basically HTML files and various JS files that provide specific capabilities of the plugin. Simple structure you can find in * Getting started* article of plugins API: Getting started | ONLYOFFICE
Basically, if means that you can integrate your JS code directly to the plugin according to the provided scheme and description.

Technically, you can implement it as you like. For instance, if you want some real-time update inside the plugin, then you can rely on onTargetPositionChanged event that simply listens for a cursor movement (typing moves the cursor). If you want to do it by a button, then adding a button to the HTML file of the plugin and assigning a function that covers, for instance, selected part or the whole document via your API and Office API.

Plugins support regular browser JavaScript methods, so you can utilize any approach that suits you.

I’d personally say it depends on the characters that represent dashes and dots. If those are regular typing characters with maybe applied fonts, then there should be no issue with the compatibility (unless used font is not available on the device where document is open). It purely depends on how your API handles the conversion from regular text to morse code.


This is one of the most important questions. You see, if you are running ONLYOFFICE Docs and it is integrated with a DMS (document storage basically), then you may consider either going with external service via Automation API or a simply packaging everything into a plugin and adding it to your Document Server.

If you want to make this service exclusively available in your app, then Automation API maybe a better approach, but installing the plugin to the Document Server will work too. However, if you want to distribute the integration and make it public, then packing everything into a plugin is the only option.

All in all, you can take any market plugin and use it as a reference to make your own. Source code for all market plugins is available here.

I hope it covers the concerns and answers main questions. if you have any other ones, please let me know.