I’m the author of a Maven plugin that can be used to synchronize source and translation files between Crowdin and a source tree. While it’s long over-due, I’ve finally decided to try to update it to use version 2 of the API.
I’ve tried to search for documentation, but the API documentation itself is very sparse and doesn’t really explain how things are intended to be used. The “old”/v1 logic for building translations before downloading was (as far as I can remember) that when you requested a build it would either return immediately with status = “skipped” or it would build and return when finished. Skipped could either mean that the previous build was less than 30 minutes ago, or that no changes had been done since the last build.
Except for the “30 minutes rule”, this was straight forward - you called build before downloading, and then you could go ahead and download.
With v2 I haven’t found this “skip” functionality - and I’m not sure where to look for it. From my testing it seems like it will build if I ask it to regardless of if a new build is actually needed or not. I know that it’s asynchronous and that I have to keep polling until the build is done - what is unclear to me is how I’m supposed to know if a build is needed in the first place. When using List Project Builds I can’t see any information that indicates whether a new build is needed or not - and it seems like Build Project Translation will always build.
My question is thus - how should I make sure that the plugin doesn’t trigger unnecessary builds?
The point is that the plugin doesn’t know if there are new translations or not since the last build. Crowdin should know, but the plugin has no idea. It just needs to download the “latest” translations.
That’s why it was handy with API v1 that the build command would just return “skipped” if the previous build was still “up to date”.
With the API v2 it is possible to run the Check Project Build Status and you’ll be able to see the date of the last updates
The API is intended to provide information about the most recent builds, rather than a historical archive of all past builds. This is why you may find that it returns a single build most of the time.
Yes, but it still doesn’t help me avoid triggering an unnecessary build - which was what I was trying to achieve. The point is that only Crowdin can know if there has been made any changes to any translations since the last build was made. Thus, when I want to download updated translations, I have no choice but to trigger a new build as I understand it. I can’t know if another build was made just a couple of minutes (or hours) ago, that is still up-to-date.
While I can list previous builds (at least the last one it seems), and see the creation and finish time - it crucially doesn’t tell me if a translator committed a new or modified translation since then.
It seems like this is first and foremost a lack of documentation problem. While trying to implement this, I have found that requesting to create a new build will often in fact return a previous build. I can see that both from the fact that it’s finished instantly, and that the ID is the same as I’ve gotten previously.
It seems to me like there’s a bug in the logic though, because it will return the same “cached” build regardless of the value of for example setSkipUntranslatedStrings. So, when asking for a build without untranslated strings, if a previous build with untranslated strings exist - you will get that in return. I can find no way to actually trigger a build without the untranslated strings other than to make some change to the translations (on Crowdin) and then trigger a new build. It’s a problem if you expect to not get the untranslated strings, and I don’t know what else to do than to make the plugin throw an error and abort if this is the case. Maybe with a message to contact Crowdin support…?
There also seems to be a cap on the number of builds, undocumented as far as I can tell, but while testing I just managed to get error 429 - Too Many Project Builds. While this is unlikely to be an issue during “real world use”, it’s a bit inconvenient when trying to code the API calls, especially when I have no idea how long I have to wait before I can try again.
There also seems to be a bug in Check Project Build Status with progress always being 0 while status is inProgress (alas it newer shows any progress until it is finished where it reports progress as 100). It makes polling to keep track of the progress kind of pointless.