Add property to specify filters for all languages

[nokite]

PR's key points

• Add an optional property that allows you to send POEditor filters when fetching terms
• Supported filters are determined by the POEditor API v2. In my testing, sending an unsupported filter does not raise an error, but the filter gets ignored. (not documented on POEditor)
• The property applies to all languages (also to the default language. Note that in a simple Android project you'll get an error at build time if a used string is missing from the base language, so it's safe at runtime)
• Logging the filters when running the task, if set
• Filtering the terms server-side via this property results in faster fetching
• Edited the Readme and the Changelog, but they are not final

Potential use case: Fetch only translated terms. This way we don't have to clean up the xml from empty terms afterwards.

Future improvements:

• allow to also specify filters per language (optionally)

Related issues

#32

How to review this PR?

https://poeditor.com/docs/api#projects_export

Definition of Done

• Tests added (if new code is added) - decided against adding tests, as it's simply using a documented API property
• There is no outcommented or debug code left

[adriangl]

Hi @nokite! Thanks a lot for all of the contributions you submitted!

While I see what you mean with only downloading translated strings (and it would make sense for most projects), I've also faced some cases where having untranslated strings could happen: for example, I had the case where we had to pick some string resources checking if they had their value set or not to switch some values. You can also face some issues in multi-flavored projects where you may expose strings from the main sourceset in specific flavors when you don't want to.

Another thing that comes to my mind would be: what would happen if the untranslated string was in the project's default language (it may be an odd case, but still)? The application would crash if you use said language.

All in all, I'd rather be flexible with the customization options rather than opinionated. With this said, it would be great if you expand the plugin to add filters to the plugin's options, it would sure come in handy for this use case! And if you need any help with it, don't hesitate to ask!

EDIT: oh, and in case you'd like to implement the filters as a configuration parameter, please wait a bit until #40 is merged so you can work with the v2 API, I already added the filters field in the API calls so you would just need to create the parameter and hook it up there 😁

[nokite]

Hey @adriangl can you have a look? Thanks for your comment! I converted it to a simple configurable property.

[adriangl]

The code looks good to me! I've got to test it to see how it works in action, I'll let you know as soon as I do it ;)

[adriangl]

Code tested, works great so far! I'll merge the PR! Thanks a lot for the contributions @nokite!

[nokite]

Code tested, works great so far! I'll merge the PR! Thanks a lot for the contributions @nokite!

@adriangl thanks for reacting quickly and keeping the project alive!