This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 810015 - [RFE] Display content of all relevant files while handling numerous topic-based files
[RFE] Display content of all relevant files while handling numerous topic-bas...
Product: Zanata
Classification: Community
Component: Usability (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Isaac Rooskov
Zanata-QA Mailling List
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2012-04-04 18:16 EDT by Yuko Katabami
Modified: 2015-08-06 01:54 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-02-24 22:58:42 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Yuko Katabami 2012-04-04 18:16:43 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:
Actual results:

Expected results:

Additional info:
Comment 1 Runa Bhattacharjee 2012-04-04 22:37:44 EDT
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.
Comment 2 Yuko Katabami 2012-04-04 23:13:21 EDT
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,

Comment 3 Sean Flanigan 2012-05-21 01:44:27 EDT
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.


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.
Comment 4 David Mason 2012-05-21 01:56:21 EDT
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.
Comment 5 Yuko Katabami 2012-05-21 02:20:08 EDT
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,

Comment 6 Yuko Katabami 2012-05-21 02:50:56 EDT
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,

Comment 7 Michelle Kim 2015-02-23 20:34:46 EST
This bug is related to PressGang so we believe this bug is no longer relevant.
Comment 8 Luke Brooker 2015-02-24 00:54:34 EST
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.
Comment 9 Michelle Kim 2015-02-24 22:58:42 EST
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.
Comment 10 Luke Brooker 2015-02-24 23:08:06 EST
This is now covered by Bug 1196006.

Note You need to log in before you can comment on or make changes to this bug.