Updated mailspring.appdata.xml.in to fix Flatpak version number and 100% checked pt-BR.json translation #2429
Conversation
The mailspring.appdata.xml.in file is used by Flatpak to automatically build the containerized version, available in Flathub, and that file wasn't tracking Mailspring's version, showing then an older version on Flathub (main Flatpak store). Also, the Brazilian Portuguese translation is around 80% checked and corrected (also standardized a lot of different words that were the same thing, improving usability).
All of the pt-BR.json was checked and verified. I've applied the necessary corrections, and tried my best to fully standardize the entire translation, because same things were being translated to different things in Portuguese.
|
The problem with the version number on Flathub is mentioned on flathub/com.getmailspring.Mailspring#10, where the maintainer suggests that fixing the aforementioned file with the correct info should get everything working when a new Mailspring update comes out. |
|
@bengotow If we could automatically update this file with the most recent version, as soon as it is compiled, we could get Flathub to also be up-to-date. |
|
Hey thanks for contributing this @matheusreich! I'll add updating this to our my build workflow and we can look at automating it in the future. |
|
You're welcome @bengotow! It is my small help in getting Mailspring to as many places as possible, and given that Flatpak is widely used in many Linux distros, it is important to keep everything working smoothly! Keep up your great work, Mailspring is awesome! |
The app/build/resources/linux/mailspring.appdata.xml.in file wasn't updated, and it caused issues on Flathub, where it automatically compiles Mailspring, but uses the mentioned file to present the current version and update (https://flathub.org/apps/details/com.getmailspring.Mailspring), as seen below:
Flathub's GitHub repository had an error about this very issue, and I've (hopefully) fixed it now.
The Brazilian Portuguese translation was good, but made use of a lot of different words to translate the same thing, which created a mix of meaning in pt-BR. Now, after fixing those issues, setting on a single standard and creating a more cohesive translation, I'd think that it is really good and standard throughout.