chore: add crowdin entries automagically [WPB-8645]

[vitorhugods]

WPB-8645 [Android] Infrastructure code and developer experience

---

PR Submission Checklist for internal contributors

• The PR Title

  • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
  • contains a reference JIRA issue number like SQPIT-764
  • answers the question: If merged, this PR will: ... ³

• The PR Description

  • is free of optional paragraphs and you have filled the relevant parts to the best of your ability

---

What's new in this PR?

Issues

Some Crowdin entries are missing from configuration.

Causes

We need to remember to add it manually when we create new modules.

Solutions

Add new entries automatically when building each module.

1. Create a new Gradle tasks that will check if _moduleName_/src/main/res/values/string.xml exists.
2. If it exists, it will check the content of /crowdin.yml.
3. If the entry is not in the Crowdin file: add it.

The task is added to all package*Resources tasks. So if the module is built at any point, it will trigger the task.

Note

This is NOT 100% failproof, but it's super good enough:
Someone could create a new module, and still raise a PR and merge it without building the app, or running the addEntryToCrowdinFile Gradle task.
However, anyone else building the app later would notice changes to crowdin configuration, and they could be committed in the future without issues.

Testing

Ran locally, missing entries are added by the new task, not by me.

How to Test

0. Remove entries from crowdin.yml.
1. Run ./gradlew addEntryToCrowdinFile; OR build the app / build one library module.
2. Check crowdin.yml.

---

PR Post Merge Checklist for internal contributors

• If any soft of configuration variable was introduced by this PR, it has been added to the relevant documents and the CI jobs have been updated.

---

References

1. https://sparkbox.com/foundry/semantic_commit_messages
2. https://github.com/wireapp/.github#usage
3. E.g. feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 48.69%. Comparing base (7876789) to head (d1c7f41).
⚠️ Report is 1 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #4518      +/-   ##
===========================================
- Coverage    48.98%   48.69%   -0.29%     
===========================================
  Files          565      571       +6     
  Lines        19561    19677     +116     
  Branches      3258     3276      +18     
===========================================
  Hits          9582     9582              
- Misses        8980     9096     +116     
  Partials       999      999              

see 6 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7876789...d1c7f41. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[yamilmedina]

Looks good to me; codewise, it's clear and nice usage of conventions plugin 🙌

My only concern is, is it perhaps a solution for a problem we don't have? since there is no guaranteed or 100% failproof and configuring a module is more or less tasks we don't do everyday.

[vitorhugods]

It's guaranteed to catch at some point. When the app is built, for example.

There is currently no automation to detect misconfiguration / missing entries in crowdin.yml.

Being pragmatic, I think the alternatives are:

1. Keep the way it is, and rely solely on people remembering to do one extra step when creating modules
2. Have this as a reminder / assistant that adds the entry.
3. Work on some other test/verification to warn when a new values*/strings.xml is added

I think this one doesn't hurt and can be easily customisable or disabled if needed in the future, without breaking anything.

I don't like the idea of keeping project-specific extra steps if they can be avoided. Adding Gradle modules should be easy and hassle free.
With this, Crowdin would be almost invisible:

1. Create your *ModuleName*/build.gradle.kts
2. Test your implementation locally, build it, etc.
3. Done. Crowdin was set automatically in step 2.

It could be more aggressive as well, and do it at configuration phase. Not sure if better or worse.
It also could be way more overkill and wait until :app is configured, to check all module dependencies and check if they have src/res/ string files and then build the crowdin.yml file.