Add preadsheet import/export tool

[Keinart]

Hello. I've been recently checking Nani Novel and I've seen it has greatly improved since it was released. Congratulations for all the great work. I've come from using Utage, but seeing the improvements I will probably move to Nani novel in future projects.

There's only one thing that I'm missing from Utage in Nani novel (unless I missed it, in which case please let me know) and I think would be a great improvement: excel or any other spreadsheet support. Nani scripts are actually amazing and how easy and fast can be edited is no doubt an improvement, but I would love if there was a way to quickly export and import only the text from these scripts into a spreadsheet (including localizations). I'm going to list a few reasons for this.

• First, during the first stages of writing text, writers generally prefer to use their own programs for writing, such as Scrivener or Word. These help mostly with auto-correction and makes text cleaner to work on. Having the text mixed with all the other commands from the visual novel such as the transitions, wait, sfx, etc., doesn't help when it comes to editing or revising dialogues quickly. Meanwhile, in Utage and when using Excel, it's very easy to just hide everything that is not in the Text column or to export/import this text to Scrivener/Word/etc. to work with your favorite program. Avoiding to have to write who's talking at the beginning of each line also helps with editing

• Secondly, during the latest stages of development, visual novels require a lot of revision by editors, proofreaders, translators, etc. This means that text is always changing and there are several people revising them. With Excel is very easy to upload the file to Google or other systems that allow to multiple people to edit and change only text. I prefer if I don't have to give to editors or translators anything that, if they were to edit by mistake, they shouldn't could potentially break the game, and it forces me to check every revision or change very carefully. In Excel, however, is very easy to automatically make it so any cell that gets changed gets a different color or use other resources so everything is cleaner and easier to see while hiding or directly removing anything that is not in the Text column.

• Lastly, I would also add that for translators especially, being able to move the translation to different CAT tools such as Trados makes their work way easier (and a custom script makes this impossible or messy), and also using a spreadsheet helps tons to add comments, questions, revisions, version check, etc. Adding comments to a normal script can easily get bloated and hard to work with, and also it forces the developer to add any comment to translators individually to each new script generated, while in Excel it can just add the comment anywhere and it will be seen and shared by everyone in all languages. In general, with this last point, what I mean is that is easier to keep track of everything with a spreadsheet.

So, while I love how Nani scripts work, it would be great and I think it shouldn't take too much work if there was a way to export all the text, including localization, to a spreadsheet where the first column includes the character talking, second column the source language, third and following columns all localizations if any, and finally one last column reserved for comments or notes of some kind (although users can always add comments in the same cell the text is written on). One last column could be added for lines ID if necessary. And finally, different tabs could be used for different scripts, including one for all the UI text that is outside the normal scripts.

Then, the same tool could be used to import back to the scripts, making sure it only changes the text and implements the proper changes.

Hope this makes sense. Of course, this is just a suggetion to help with the editing/translation workflow, it's not really anything essential. Thanks.

[Elringus]

Hi, Thanks for the suggestions! Allow me to comment on each point:

1. Naninovel scripts were initially designed to solve just that exact case when writers are using separate documents to work on the text and then someone else have to adapt that into scripts. With the .nani, both writers and designers/programmers can work in the same files (optionally shared via a VCS or a file sharing tool, like google drive or dropbox); writers will also be able to define the basic events (eg, which background or character expression to show, music to play, etc). This significantly reduce the amount of time spent on authoring the scenario and prevent errors when moving the text between the files. The .nani are plain-text files, so it's possible to open and edit them in any text editor (eg, Word). However, I'd recommend using VS Code, as it provides a lot of productivity tools (including spell check/auto-correction). That said, I can see how lots of commands could make it uncomfortable for writers to work on the text. I'll look into adding an option to hide everything but generic text lines in the future VS Code extension updates.

2. That was partially covered above (regarding sharing the access and hiding everything, but text in VS Code). As for the translation documents, they're already detached from the scenario files; see the guide for more info: https://naninovel.com/guide/localizatio ... calization

3. The translation documents are simple plain text files and contain just the text to translate (the comments are optional). The content of the generated files is also preserved on each iteration, so it shouldn't be a problem to check them in VCS, add comments, etc.

Overall, I can see how such all-purpose sheet with just the text and translations could be useful, but at the same time I feel that it's more of an individual preference and other teams could have completely different approaches. I'd suggest authoring a custom in-house solution to fit your workflow based on the existing features. If you'll feel something in the engine is not extensible enough to implement that, please let me know.

[Keinart]

Thanks for the quick answer! Yes, I understand that it's probably not a priority for you guys, so if it comes to it I will for sure look for an in-house solution. But I think it was worth it mentioning. I would like to make some clarifications still. I don't want to sound picky or as if I want to force anything or that I'm complaining. Nani system is still probably the best visual novel system in the market at the moment, it's just that I've been working in Localization and QA for videogames for a long time and every company uses some kind of spreadsheet system for a reason, which made me too used to them. I know for a fact that when indie games do not use these spreadsheet systems, they tend to end filled with mistakes and inconsistencies.

About VS Code and adding ways to it to remove the commands, it is great and all, but there are little number of editors or translators out there who know how to use it, and their spelling or correcting tools are pretty lacking when getting into it (especially for non-English languages). And this still doesn't compensate for many of the functionalities of spreadsheets: changing colors for cells (for example, greatly used when new lines are added or some lines need to be updated due to changes), adding comments inside cells, have long lines visible in one view without having to scroll right or left, adding rich text features like bold, cursive, colors, etc. (generally used to indicate things to other members of the team such as certain words are referenced to other sections or context about the tone or section where it is used), using macros for big general changes or increasing the workflow speed, have versions comparisons that allow to easily identify what cells were changed in what version and revert individual localized changes, use CAT tools to identify repeating sentences or sections to keep consistency of how characters talk, and well, tons of things that I'm probably missing. Have a way to remove the commands in VS Code is great indeed, but it's just not the same that having a very organized spreadsheet with all the tools that come with it.
I see how working while seeing the commands inside Unity can be greatly useful, but during the first stages where there are no assets yet and the writers are only working with plain text, and once these commands and assets are set in stone and the game goes through different editing and proofreading passes, the best is to have a single file with only text that allows for all the stuff I already mentioned.

About the translation files, sorry I expressed myself badly. Precisely, what is best is to have all languages files in one single text file. Generally, the standard in the industry is to have one large text file that only one person can modify, but everyone can see and comment, then have the translators work in their own text files (that it's basically the same file, but just a copy hiding all the other languages). Then, all the changes and translations go through a revision, and once they have been approved, a macro is used to move all the changes to the main text file, that is then imported into the game.

For translators, this single shared file helps because they can compare and see how different sentences are handled in different languages as well as to cooperate with each other. They generally also need a way to add a lot of comments to ask about context. For example, Japanese translators need context about the different tone, relationships and respect different characters should have with each other since that will determine which version of words or honorifics they will use. For romance languages, they need to ask all the time about the gender involved in sentences that lack context. Adding these comments in a plain file leads to bloating the file, while in a spreadsheet they can be added in a new column or in-cell, and it can be shared with all languages so all the context information can be added easily with notes instead of having to add comments to every individual file for each language.

In my experience with Renpy, for example, editors and translators would all the time include extra space or line breaks where it shouldn't; remove a commented line by mistake or don't add the commented line properly, which would then appear in game; make wrong changes that ignore the context that then the main scenario writer would miss because there are no proper tools to indicate what was changed, make mistakes with commands that are in line (such as the goto for Nani) that lead to bugs in game, etc. I know most indie visual novel developers come from Renpy so they are used to this format, and they generally don't translate their games to many languages, but in my case having 30 individual files per language at least, in a 200k words game, in maybe 3 or 4 languages, is just an editing hell that leads to mistakes and problems that greatly affects quality.

Again, sorry if I'm sounding patronizing or picky, it's not my intention. I understand how much work and thought went into this project and how someone coming with this may sound like complaining. I know adding such a tool would add a lot to your already filled workload, and your audience target are generally indies that don't require so much for their work. Still, for more complex games than visual novels and bigger teams, I think adding something like what I mentioned could bring huge improvements. In-house solutions always have the issue or not working when the engine updates or compatibility issues for certain unexpected sections, and since you already have a great system implemented for localization that even automatically updates lines when changes are done in the source language, I think it's probably not that hard to use the same system to export to xls or even just a plain csv that takes care of removing anything that isn't part of the game text and puts all scripts and languages in one single large file for easier visualization.

Thanks for your time, sorry it was such a long message!

[Elringus]

Thank you for the detailed opinion and sharing the experience! I really appreciate that and understand the points.

I've looked into various ways to implement such spreadsheet import/export system, but found an issue, that could be quite limiting.

The naninovel script content added to the spreadsheet should be associated with the script lines in order to transfer it between the sources. I can think of two ways to perform such association: content hash or line numbers. Both solutions, however, will restrict editing the naninovel scripts. In the first case all the localizable lines (eg, generic text lines, choice and print command lines, etc) shouldn't be modified and in second, no lines shouldn't be added or removed (to preserve the line count). Basically, that means, that once the spreadsheet is generated and is being worked on, the naninovel scripts shouldn't be modified.

I don't think such limitation is acceptable and will try to figure other ways to solve this, though not sure if it's at all possible. At least, without some intermediate system, that would manage the changes between the naninovel scripts and the spreadsheet.

Alternatively, it could be possible to abandon .nani files and use a spreadsheet to author all the scenario (including commands); this will discard all the IDE benefits when working on the commands, though.

[Elringus]

I've created an extension for exporting and importing scenario, managed text and all the associated localization data to an .xlsx spreadsheet. Hopefully, it'll be useful for the cases you've described. Find more info here: https://github.com/Naninovel/Documentat ... adsheet.md

Thanks again for the suggestion!

[Keinart]

I just saw this update on twitter (sorry, I've been busy) and had to come. Absolutely AMAZING work! This looks incredible and the fact that you made it so fast after my proposal makes me really honored!
I've been checking it a bit and FOR SURE I will use it in my next project. You guys are no doubt the best engine out there. In know it can feel annoying when someone comes asking for stuff just like that, especially when it's never all that easy, but the speed and quality here is incredible. Thank you very much.