Translators sometimes find typos or errors in the Source string and they would like to add commments against the Source so that 1. The author / project maintainer gets to see the issue with actual string 2. Translators can share the knowledge of the issue by looking at the comments To be able to do this, we need the following two features: 1. Feature to add comments against Source 2. Notification feature to notify the project maintainer/author/Translators For this RFE, I would say #1 is the scope and I can create additional RFE for notification part. Handing this ticket to Carlos for team assessment. Thanks, Michelle
A few questions before sending off for analysis: 1. Do we want to add this to the new editor or the old one (or both)? 2. If this is not going to provide notifications to the project maintainers, how are they going to know that there is something wrong with the source?
Carlos, my answers are 1. Let's put our effort putting this feature to new editor 2. I believe I requested to send the notifications to the project maintainer as well as translator (maybe the ones who translated the string)?
Michelle: Ok, just keep in mind that this will be the first feature to be implemented solely on our new editor, so it will become the preferred editor for all practical purposes. This means that we might also want to cover all *crucial* missing features before the next release. Assigning to David for evaluation.
Carlos: Just wondering what would be the scope difference if we decided to add this RFE to both current and new editor? Can you help estimating both too to decide if it's worth adding it to current editor, too Thanks, Michelle
To do this feature in the new editor we would need to implement the details panel. This is a recent mockup I have for the part of the details panel that includes source/translation comments. https://www.dropbox.com/s/o9f6qo4yu26jp6u/Screenshot%202015-06-15%2010.27.51.jpg?dl=0
> what would be the scope difference if we decided to add this RFE to both current and new editor? It would be about double the effort. The database changes and data service within the server would provide a basis for both, but the other components would all need to be implemented twice: API endpoints on the server, data handling in the editor, UI design and UI implementation. We already have an initial UI design for source comments in the new editor (see Comment 5).
Thanks Luke for the mock up. It seems the mock up has one comment editor for both source and translation with toggle key between two. So I believe the source / target area will indicate if there is existing comments against the strings. Hi Carlos, Thanks for the raising the concern over covering all *crucial* missing features before the next release. Makes sense to me as well. David, Understood on the scope estimation for both editors. I am more inclined to just develop this feature to the new editor first if we can get all the "crucial" features in place for the new editor soon, so that it becomes more of default workspace. Carlos, David, Shall we create new RFEs to determine what are the remaining features that we need to implement in new editor to make it mature enough to be called "default" editor?
> Shall we create new RFEs to determine what are the remaining features that we need to implement in new editor I suggest we discuss this in-person and create RFEs after, since it will save a lot of typing and get it done more promptly.
> Shall we create new RFEs to determine what are the remaining features that we need to implement in new editor to make it mature enough to be called "default" editor? I have created a bug to discuss and track the remaining features to make the new editor the default. It has an initial list of the features Luke and I think are crucial, some that might not be needed right away, and some we are certain can be added later (but not too much later). https://bugzilla.redhat.com/show_bug.cgi?id=1232090
Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-316