Bug 831887 - RFE: List available Translation Locales via REST API
Summary: RFE: List available Translation Locales via REST API
Alias: None
Product: Zanata
Classification: Retired
Component: Component-Logic
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Isaac Rooskov
QA Contact: Zanata-QA Mailling List
: 956916 (view as bug list)
Depends On:
Blocks: 759983
TreeView+ depends on / blocked
Reported: 2012-06-14 02:26 UTC by Lee Newson
Modified: 2015-08-06 05:54 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-02-24 01:51:57 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 831894 0 unspecified CLOSED RFE: Get Stats about Translation Documents via REST 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 848988 0 unspecified CLOSED RFE: Clients side support of Translation Documents Statistic via REST 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1156236 0 medium CLOSED RFE: As a project maintainer, I want to be able to use the latest list of languages defined in the server for a project ... 2021-02-22 00:41:40 UTC

Internal Links: 831894 848988 1156236

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.


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:

403 response:

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


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:


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

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