The .changes snippet suggested looks fine. 'raw-translations-static' identifier is fine too, although it may cause some confusion with the current 'raw-translations' one, but I don't mind as long as it's clear to you.
Regarding the look-up mechanism I'm not entirely sure. Custom uploads are directly related to build records but in most of the cases they are only generated on the i386 attempts (nominatedarchindep), resulting in source->[builds]->[custom] that can be easily aggregated and exposed via the API as:
Pitti,
The .changes snippet suggested looks fine. 'raw-translatio ns-static' identifier is fine too, although it may cause some confusion with the current 'raw-translations' one, but I don't mind as long as it's clear to you.
Regarding the look-up mechanism I'm not entirely sure. Custom uploads are directly related to build records but in most of the cases they are only generated on the i386 attempts (nominatedarchi ndep), resulting in source- >[builds] ->[custom] that can be easily aggregated and exposed via the API as:
{{{ distributions[ 'ubuntu' ] getSourcePackag e('firefox' ) custom_ files: file.filename, custom_ file.custom_ type 1.0_i386- translations. tar.gz RAW-TRANSLATION 1.0_i386- translations- static. tar.gz RAW-TRANSLATION S-STATIC
>>> ubuntu = launchpad.
>>> firefox = ubuntu.
>>> for custom_file in firefox.
.... print custom_
firefox_
firefox_
...
}}}
Or something similar. Obviously custom file would allow you to get the file contents via the API as well.
On the web UI side, we could simply present 'custom files' everywhere we present the source and binary files, I guess.