Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 831887

Summary: RFE: List available Translation Locales via REST API
Product: [Retired] Zanata Reporter: Lee Newson <lnewson>
Component: Component-LogicAssignee: Isaac Rooskov <irooskov>
Status: CLOSED NEXTRELEASE QA Contact: Zanata-QA Mailling List <zanata-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: cbredesen, dchen, mkim, sflaniga, yshao, zanata-bugs
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-24 01:51:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 759983    

Comment 2 Ding-Yi Chen 2012-10-29 04:39:17 UTC
Hi Lee,

Since all document in same project-verision share the same locale setting, is it sufficient to get the supported locales at version level instead of individual document level?

Comment 3 Ding-Yi Chen 2012-10-29 04:46:25 UTC
Bug 848988 is quite close to the needed functionality, however, using the statistics to get the supported locales is quite consuming, thus we still need the lighter-weight method to achieve this.

I would also like to extend the scope of this bug to following levels:

1) Version level
2) Project level
3) Server level (i.e. Similar to what we get from language list).

Comment 4 Lee Newson 2012-10-30 00:29:16 UTC
Hey Ding-Yi,

I talked it over with Matt and that would work fine, plus the added benefit of less calls. Also with the change Sean mentioned in comment #1 about no longer returning 404 for Translated Documents that haven't had translations done, that does seem like the better option.

Comment 5 Lee Newson 2012-10-30 00:30:20 UTC
I also made the first two comments private since the links were internal.

Comment 6 Isaac Rooskov 2013-02-19 01:49:53 UTC
Add support through stats or REST service

Comment 7 Ding-Yi Chen 2013-06-27 07:41:02 UTC
*** Bug 956916 has been marked as a duplicate of this bug. ***

Comment 9 Ding-Yi Chen 2013-06-28 03:40:31 UTC
Original description is private, which cannot be view by outside stakeholder.
Thus, I repost it here with sensitive data removed.

Currently via the REST API there is no way to find what translations exist for a Source Document. As such you need to send a request for each translation to see if it exists. eg.

http://<zanataServer>/rest/projects/p/<proj>/iterations/i/<ver>/r/4767-48873/translations/pt-BR

Sean mentioned he believed the ITranslationResources.getResource() function would do this but it only makes a call to the URL above. So if you don't know what translations exist for each document then you are just sending requests that are going to return a 404 response or a 403 response if the locale isn't setup. eg.

404 response:
http://<zanataServer>/rest/projects/p/<proj>/iterations/i/<ver>/r/8816-134374/translations/pt-BR

403 response:
http://<zanataServer>/rest/projects/p/<proj>/iterations/i/<ver>/r/8816-134374/translations/ar

Currently using the ITranslationResources service and the Source Document all you can do is get the Translation Strings for that Document. eg.

http://<zanataServer>/rest/projects/p/<proj>/iterations/i/<ver>/r/8816-134374/

As such it would be handy and something that would save a number of requests, is if you could do a rest query to find out information about each Source Document or Translated Document. eg. What translations exist for the document, when it was last modified, etc..

An example query to list the available translations maybe something like:

http://<zanataServer>/rest/projects/p/<proj>/iterations/i/<ver>/r/8816-134374/translations

Comment 10 Michelle Kim 2015-02-24 01:51:57 UTC
I believe this feature is implemented in the bug 1156236