Red Hat Bugzilla – Bug 810015
[RFE] Display content of all relevant files while handling numerous topic-based files
Last modified: 2015-08-06 01:54:26 EDT
Description of problem: I am currently working on RHEL Installation Guide. This book is divided into 1036 files, each one contains small amount of text. I believe this is a part of the new method "Topic Based Authoring" (which divide a book into small sections according to topic, so that they can be reused in other books). This is giving us a hard time when working on zanata. We have to click each file to open and work, then move on to anther file, and so on. It is particularly hard when we have to change a terminology or an expression throughout entire document. We also cannot see how text flows in a chapter and unable to understand the context. I know that the next version of zanata will have inter-file find/replace and it will help to some degree, but I am wondering if it is possible for you to create an option to view all strings from all files in one working windows, so we do not go in and out of 1000+ files. This option should be very important if the Content Service move towards topic based authoring and a project like this would become a norm in the near future. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Hi Yuko, I am marking this as an RFE for the team to evaluate. Also I have changed the subject. Just to confirm, are you looking at displaying strings of all the files together or a smaller content segment like a chapter? In either case there has to be some metadata originating from the topics, linking them together to make the final chunk look sensible.
Hi Runa, Thank you for responding to my report. I realised that it would be better to display all strings of a chapter (instead of the entire book, which would be too large). Hope it works out. Kind regards, Yuko
We can look at adding a feature to show a view of multiple files in the translation editor. This might be handy for Java software translation too, since they often have lots of little .properties files. However: 1. The topics in a Skynet search result (and in a filtered Zanata view of Skynet topics) have no particular order. (I think document order comes from a content spec, so I suspect it's non-trivial to change this.) This would need to change before you could see the flow of text. NB: if this ever does change, we will *also* need to make sure that the Zanata view follows the Skynet order. 2. As for restricting the view to be a chapter rather than an entire book, the best way to do this would probably be to have Skynet request a filtered view in Zanata which only shows the desired chapter. Otherwise Skynet would need to send some extra metadata to tell Zanata where the chapters start and end within the book.
I'll make sure the project-wide search and replace feature works properly with filtered sets of documents from Skynet - this should be working in 1.6-GA. Would simple "next document" and "previous document" buttons be of any use in this case, so that a translator can move between documents without having to return to the doclist? The advantage is that it would probably be quick to implement.
Hi Sean, Thank you very much for your action. I don't know anything about technical side, but the way I visualized is a list of different chapters on one page and then when click on a chapter, it shows all strings of the chapter in order. This way, we can work from one chapter to next, rather than one file to next. Kind regards, Yuko
Hi David, Thank you for asking me about the project-wide search and replace feature. Just to clarify, what you are asking is moving from one filtered set of skynet documents (i.e. chapter) to another, without going back to the list? If so, I think it will be useful. However if it is about moving from a single skynet document to next, it may not be as usefu, considering the number of documents one project can contains (e.g. RHEL IG has 1023 files) and some files only contain one string. (I may prefer to use "replace next" through entire project). Kind regards, Yuko
This bug is related to PressGang so we believe this bug is no longer relevant.
I think this is still relevant as there are other projects that have many documents with low amounts of translation in each. It is something that we have discussed adding to the new editor and something that would bring a lot of value.
I am closing the bug as work is no longer required for Topic based projects. Luke will create a new RFE for translating the multiple files in one editor.
This is now covered by Bug 1196006.