Query for a project of a particular locale
This issue was created automatically by a script.
Bug 1408625
Bug Reporter: Roshan Gautam <[email protected]> CC: @mathjazz, @jotes, [email protected], @stasm Blocker for: Bug 1409704
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20171009192146
Steps to reproduce:
Trying to make api call to query a project of a particular locale.
Actual results:
It's not possible to query it right now.
Expected results:
I was expecting detail of a particular project of a particular locale.
Comment Author: @mathjazz
Thanks for the report, Roosan!
Please note that we're still planning the Roadmap of the Pontoon API roll out: https://wiki.mozilla.org/L10n:Pontoon/API#Roadmap
What data would you like to get from such query? I suspect aggregated stats and a list of Resources to Translate? https://pontoon.mozilla.org/fr/mozillaorg/
We have this covered in the Milestone 2 which is scheduled for 2017 Q4. I'm CCing stas who leads the API effort, and probaby has ideas how he wants to track the next milestone in Bugzilla.
Comment Author: Roshan Gautam <[email protected]>
Hi Matjaz, The data would be same as querying individual project (irrespective of locale which is possible now) but with this query will get a detail of individual project for a particular locale.
Comment Author: @stasm
I asked Roosan to file this bug when he emailed me last week. Thanks again, Roosan!
Right now it's only possible to get all locales for a particular project or all projects for a particular locale. We expose the aggregated statistics for each item on the respective list. We could add a way to query for the same data but for a particular project and a particular locale only.
I see two ways in which this could be accompilshed:
-
Add a new
localization(code, slug)root-level field which allows to query ProjectLocale objects directly:{ localization(code: "ne-NP", slug: "firefox") { missingStrings } }
-
Add a
localization(code)field to the Project shape and alocalization(slug)field to the Locale shape, similar to the currentlocalizationsfield which returns a list:{ locale(code: "ne-NP") { localization(slug: "firefox") { missingStrings } } }
{ project(slug: "firefox") { localization(code: "ne-NP") { missingStrings } } }
My recommendation would be to go with the second approach: extending shapes is more versatile because it allows us to use the feature everywhere where the shape is used. For instance, we could list all locales with data about only some projects:
query mobileLocales {
locales {
name
android: localization(slug: "firefox-for-android") {
missingStrings
}
ios: localization(slug: "firefox-for-ios") {
missingStrings
}
}
}
Comment Author: @mathjazz
Fixed. :)
Comment Author: @jotes
Hi :stas and :mathjazz, I could look at this bug in the meantime if you won't mind.
Comment Author: @mathjazz
Sure, go ahead. Note that stas is on a PTO until the end of the week, so it might take some time before he can respond.
Fixed in https://github.com/mozilla/pontoon/pull/3666