Next Steps

[jsbackus]

This issue is intended for discussion of our next steps.

[jsbackus]

Anyone grab a copy of the profiles repo?

[DarkStarSword]

The most recent fork I can see is: https://github.com/slacknk/antimicro-profiles

Not sure if there's anything more recent than that - Ryochan7's recent history tab only goes back as far as March 8, so if there's anything between Feb 6 and then it would be missing. Looks like the repo doesn't get updated very often, so that might be fine. Otherwise it might be worth checking if any distros have a more recent version.

[DarkStarSword]

We should also look at restoring the wiki pages and release notes - @WAZAAAAA0 managed to grab them from Google's cache and uploaded them here: http://www.mediafire.com/download/hla0doflg49th41/AntimicroPagesBackup.zip

[mdeguzis]

Very happy to see the work being done here. I build this to my repository and use it a lot for SteamOS. Thank you all for your work. I'll try to help if I can with issues/conversation, unless you need an initial maintainer for Debian distros.

[jsbackus]

@DarkStarSword Nice sleuthing! Yes, definitely want to get the wiki restored as well. I'll incorporate them when I get a chance. Thanks!

@ProfessorKaos64 Glad to help and also glad for any help. :smile: Yes, any help you could provide with supporting Debian distros would be greatly appreciated. I'm running Fedora and am not acquainted with building .debs.

[mdeguzis]

Yea I could just make a Deb for the current Debian Jessie, and account for variants in Ubuntu. Those would be the popular targets. I already make one for SteamOS that uses Debian Jessie packages.

On May 25, 2016 6:10:01 PM EDT, Jeff Backus notifications@github.com wrote:

@DarkStarSword Nice sleuthing! Yes, definitely want to get the wiki restored as well. I'll incorporate them when I get a chance. Thanks!

@ProfessorKaos64 Glad to help and also glad for any help. :smile: Yes, any help you could provide with supporting Debian distros would be greatly appreciated. I'm running Fedora and am not acquainted with building .debs.

---

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/AntiMicro/antimicro/issues/3#issuecomment-221723110

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[DarkStarSword]

I can possibly help out with Windows builds. I have a Windows dev environment set up that I use for my work on 3DMigoto, though this uses a different build system and I have not tried actually building it yet.

[jsbackus]

@ProfessorKaos64 Yeah, that would be really helpful, thanks!

@DarkStarSword Yes, that would be helpful if you could, please. I'm going to try to get it up and running in wine. Hopefully, between the two of us we can figure out the quirks of the compile environment. Thanks!

[jsbackus]

Last night I was able to successfully build under wine, except for the installer. Qt and CMake installations were straight forward. WIX, not so much since it requires .NET 3.5.1. (which is ridiculous that an installer is dependent on .NET... /curmudgeon off). I'm going to plug at getting WIX to work under wine for a little bit longer, so that I can keep the one win7 machine I have for testing. Also try to get around to uploading binaries and the wiki this weekend.

[WAZAAAAA0]

I was able to build my installers (antimicro-2.21-win32-fixedSDL.msi & antimicro-2.21-win64-fixedSDL.msi) using msi2xml. I extracted the XML straight from an original antimicro setup file and used it to rebuild them again with updated .DLL files. "-m" to ignore the checksum test.

I'm just saying, it's a possible solution, albeit ugly.

So if I understoond correctly, you're going to make a "2.22" version with the Spanish translation and the "unreleased" commits? In that case, cool stuff

[jsbackus]

@WAZAAAAA0 Thanks! Looks like I was able to get WIX to install under wine. I should probably document what I did.... And yes, the hope is to have a 2.22 release candidate ready by the end of the weekend with the unreleased commits, the SDL 2.0.4 fix, and the Spanish translation. We'll see how far I get. @Ryochan7 was a lot faster than I am. :smiley:

[jsbackus]

Binaries for 2.21 have been uploaded (thanks @WAZAAAAA0!).

[jsbackus]

Quick status update - replacing the wiki is going to be more work than simply uploading files, but I'll get around to it soon. I've finished all other things I intended to take care of for this release, other than to update the changelog, etc. I'll get to that soon.

[WAZAAAAA0]

It would be great if these forks... @DarkStarSword @est31 @zzpxyx @AntiMicroAdvance ...and all the others also linked to this repository. My repo and @7185's one already do. Changing the description should be enough.

[est31]

https://github.com/est31/antimicro should now be a fork of this repo.

[WAZAAAAA0]

Let's say I'm working on the Italian translation of antimicro. Would you implement it @jsbackus?

[7185]

I'm currently working on the French translation myself since it needs serious improvements. Qt Linguist is fun to use.

[WAZAAAAA0]

@7185 Qt Linguist? Dear God I can't believe such amazing software even exists. I love you for mentioning it, it really helps. I'd say it deserves to be added somewhere in the README as a means of helping translators. I mean look at how sexy it looks like: https://i.imgur.com/B6ovTx9.png

@qwerty12 somehow pulled out the .MD files for the wiki. Rename this file to .ZIP: https://github.com/Ryochan7/antimicro-packaging/files/294012/antimicro-wiki.docx Definitely add this guy to the "special thanks" list.

[mdeguzis]

Launchpad could be used to cook up a script for all the Ubuntu releases, or whoever takes care of certain ones can just continue to add them to the releases page. I maintain my own repository for Debian software, but I'd rather reach a consensus when this time comes for a new version. I don't mind building Linux binaries to help out. It's something I feel semi-competent doing :) Debian distros are handled very nice with pbuilder. Other Linux distros, like Fedora, will just have to be manual RPM builds, or OBS could be used.

[jsbackus]

@WAZAAAAA0 Certainly! Thanks for doing the translation! Definitely recommend using Qt Linguist. To get started, I would copy share/antimicro/translations/antimicro.ts to share/antimicro/translations/antimicro_<LANG>.ts, where is language abbreviation (i.e. es = Spanish) and optional Country/Region (i.e. zh_CN is the Chinese translation, I believe). Open the file in Linguist and please set the language and region under Edit->Translation File Settings. Once done, please send me a PR. Agreed - should be updated in the readme. I'll make a note...

@7185 Thanks for taking care of the French translation! And thanks for mentioning Qt Linguist!

Actually, anyone who is working on a translation, please create a new issue so that we can keep track of work in progress. Don't want to miss anybody.

@qwerty12 Nice work! Definitely worth adding to the special thanks list. :) Original wiki is back in business! :dancers:

@ProfessorKaos64 Interesting! Not familiar with pbuilder. I'm happy to point to your repo if you don't mind sharing, or we can put the releases here. I maintain the Fedora package in the official repo. Don't currently support RHEL/CentOS versions, but I don't mind taking those on if someone is using AntiMicro on either of those. With regard to which Ubuntu releases to support, I would stick with whatever is still officially supported. 16.04? We can encourage people to ask if their distro of choice isn't available. But yes, any help you would provide on that front would be greatly appreciated!

[jsbackus]

whoops! Looks like there are some UI text changes that need to be incorporated into the translation files. I should revisit the about dialog, too. I'll take care of that in the next day or so and let everyone know. Sorry.. still new at this translation business... :innocent:

[mdeguzis]

I host packages for SteamOS, and just a few for Jessie at http://packages.libregeek.org. It shouldn't take much to spin up pbuilder chroot's for 16.04, Debian Jessie. The group would have to put for probably the 3 most popular debian distros, or just focus on the latest Ubuntu and Debian release. I don't have a build bot, but maybe someday :)

[zzpxyx]

Note that antimicro doesn't use the normal way of organizing Qt projects. Particularly, there is no .pro file, so the documentation is not that helpful.

Here is what I do for Simplified Chinese translation. Suppose that the current folder is the antimicro project folder.

First, update the .ts file: lupdate src/ -ts share/antimicro/translation/antimicro_zh_CN.ts -no-obsolete

Without the -no-obsolete argument, the old translation will be kept in the .ts file.

Then, use Qt Linguist to open the .ts file and do the translation.

Finally, build and install antimicro, or use the following command to release the translation: sudo lrelease share/antimicro/translations/antimicro_zh_CN.ts -qm /usr/local/share/antimicro/translations/antimicro_zh_CN.qm

Hope that this might be helpful for translators. Maybe I'll put this in the wiki if useful.

[Papermanzero]

Can users already enter feature requests? I have some of the old request and I would transfer them in this project. Btw. Thank you so much for the revival of AntiMicro.

[jsbackus]

@ProfessorKaos64 Great! Thanks for doing this! Yes, for now we'll stick with the 16.04 and Jessie. We'll refer to your repo in the Readme and in the wiki.

@zzpxyx Thanks! Yes, very helpful! Yes, please put it in the wiki. Also, there appears to be an updateqm target in the Makefile. I don't think it uses -no-obsolete, because when I ran it, it appeared to clobber old translations. I'll update the build system. Would it be worth my reverting the current .ts files? Not sure what kind of mess I made. :innocent:

@Papermanzero Yes, please! Thanks! and welcome!

[zzpxyx]

Just adding a minor comment in terms of the -no-obsolete argument. Personally I would use lupdate without it in the first round. Sometimes there are minor changes on a very long string and keeping the old one will make it easier to copy and paste the old tranlsation. Then after translating with Qt Linguist, I'll run lupdate again with -no-obsolete so that the .ts file is cleaned.

[jsbackus]

@zzpxyx Ah! I understand now. Sorry, had things backwards. Thanks for the clarification! Yes, it looks like the build system is using -no-obsolete whenever -DUPDATE_TRANSLATIONS=ON is passed to cmake. Luckily, I didn't push my commits after doing that, so I'll back those changes out.

[jsbackus]

I've updated the build system to allow preserving obsolete translations to hopefully mirror @zzpxyx's flow. I've added an additional variable to cmake, TRANS_KEEP_OBSOLETE, which will call lupdate without -no-obsolete. So, hopefully, translators can use the following flow:

1. cmake -DUPDATE_TRANSLATIONS=ON -DTRANS_KEEP_OBSOLETE=ON
2. make updateqm
3. Edit translation
4. make updateqm
5. Run and verify translation, repeating 3-5 as necessary
6. cmake -DUPDATE_TRANSLATIONS=ON
7. make updateqm
8. commit updated translation

@zzpxyx Would you please grab the latest in master and see if the above works correctly? Thanks!

[zzpxyx]

@jsbackus Thanks for updating the build system!

I might have missed something here. Do we assume that those cmake and make commands are executed under the project root folder, or a manually created build folder?

I think that I was just talking about "how" previously, but didn't mention "why". Here is my understanding of the translation process and the "why":

1. In the .cpp source files, there are many strings, especially for the UI part. We want to translate them so that people can understand them easily. According to Qt, we need to use the tr() function to mark the strings out.
2. We have so many source files, so the strings are scattered around. We want to have a central place for them so that we can translate them consistently. To do this, we use the lupdate command to extract the strings marked with tr() out of the source files, and put them into a single .ts file for each language. The -no-obsolete is not used here since we may want to refer to the old translated strings.
3. Now we have a central place for the strings. We can use Qt Linguist to translate them. Qt Linguist has nice features such as suggestions and phrase book to make the translation more consistent. Upon saving the .ts file, Qt Linguist will write the translated strings back to the .ts file, as well as some metadata.
4. Now we have a problem. The translated .ts file is still in the human-readable text form, and antimicro's binary executable does not like it. We need to use the lrelease command to "compile" the translated strings into a format that is recognizable by the application. Now we have a .qm file.
5. We can see that .ts files are closer to the the .cpp source files, while .qm files are more like the binary executable. Thus, I think the generated .ts files should be placed near the source code, like under <antimicro_project_root>/share/antimicro/translations/, and the generated .qm files should be placed near the antimicro binary executable, like in /usr/local/share/antimicro/translations/. The benefit of this strategy is that we will be able to view the translated strings without rebuilding antimicro, as long as we save the .ts file and use lrelease to update the .qm file in that folder.
6. After several rounds of translating in Qt Linguist, saving the .ts file, using lrelease to update the .qm file, and testing, we may be satisfied with the translation. At this time, we can add -no-obsolete to lupdate to generate a clean version of the .ts file for commit.

I'm not an expert on build system, but I might be able to come up with something specifically for translation by the end of this week.

[jsbackus]

@zzpxyx Sorry for taking so long to get back to you. Not nearly enough hours in the day. Thanks for the clarification! Yes, @Ryochan7 had automated parts of it. From what I was able to pick up from the build system and BuildOptions.md, the following flow was supported:

1. cd antimicro
2. mkdir build; cd build
3. cmake -DUPDATE_TRANSLATIONS=ON ..; make updateqm

This would execute lupdate -no-obsolete on all .cpp files that CMake could find, then executes lrelease on all .ts files in <antimicro_project_root>/share/antimicro/translations. In commit afb62e I added an additional CMake target, TRANS_KEEP_OBSOLETE, that does the same as above, but excludes the -no-obsolete option. So, I envisioned translators could use the above flow to update the .ts and .qm files. Yes, the .qm files get unnecessarily updated on every iteration, but I don't believe there is a noticeable cost. dd

[zzpxyx]

@jsbackus Thanks for the clarification! I tried the workflow but I got an error. Below is what I did.

cd antimicro
mkdir build
cd build
cmake -DUPDATE_TRANSLATIONS=ON -DTRANS_KEEP_OBSOLETE=ON ..
make updateqm

Then I used Qt Linguist to modify the .ts file in antimicro/share/antimicro/translations/antimicro_zh_CN.ts. After saving the file, I continued with this:

make updateqm

Now I need to test the translation, so I have to build and install:

make
sudo make install

After running antimicro, I find that the translation needs improvement, so I use Qt Linguist to modify the same .ts file. Then:

make updateqm

Here comes the problem. The updated .qm file is under antimicro/build/share/antimicro/translations, but the installed antimicro uses the one under /usr/local/share/antimicro/translations. As a result, I cannot see the updated translation.

At this time, I cannot use make or make updateqm. There is an error saying that No rule to make target '../src/Changelog', needed by 'qrc_resources.cpp'. It seems that building or installing antimicro changes something under the build folder, and this prevents a rebuild. Using make clean is not helpful either.

I'm imagining a workflow like this:

1. Create and enter a build folder. Build and install antimicro as usual.
2. make tr_begin, where tr_begin is a new target in the generated makefile. It will execute lupdate without -no-obsolete. The udpated .ts file is under antimicro/share/antimicro/translations.
3. Use Qt Linguist to modify the .ts file.
4. make tr_test, where tr_test is another new target. It will execute lrelease and put the .qm file under /usr/local/share/antimicro/translations.
5. Run antimicro and test translation.
6. Repeat Step 3 to 5 as necessary.
7. When everything seems fine, use make tr_end, which is the third new target. It will execute lupdate with -no-obsolete.
8. Commit translation changes.

I haven't figured out how to implement this using cmake though.

[zzpxyx]

I think I found one workaround for the problem mentioned in my previous comment. The key is not to install antimicro after the build. Just test with the executable antimicro/build/bin/antimicro. Previously, I thought there would be problems regarding profiles and configuration paths if I don't install antimicro, but actually it seems working well. It seems that the error I encountered only happens after sudo-installing antimicro. Not sure what is the best way to install though.

[jsbackus]

@zzpxyx Hmm.. interesting. Yeah, Changelog disappearing has bitten me too. I just figured I was doing something wrong. I suspect that the install target is moving Changelog instead of copying it. Line 739 in the CMakeLists.txt file in the project root looks suspicious. I'll look into it some more. Glad running from the build tree works. I was hoping it would, but had my doubts, too.

:+1: regarding your workflow. CMake seems to be a reasonable replacement for autotools, but I find that it only complicates things when attempting to replace some of Make's functionality. I think that the changes need to be made to antimicro/share/antimicro/translations/CMakeLists.txt. I'm not sure what the details are regarding QT?_CREATE_TRANSLATION() vs. QT?_ADD_TRANSLATION(). I suspect the former is a macro for lupdate and the latter for lrelease. I won't be able to take a stab at it this weekend, though. Feel free to take a whack at it. :smile: I've made notes regarding this in issue #15.

[jsbackus]

Yep, fixed the Changelog issue. See issue #17.

[jsbackus]

@zzpxyx Unfortunately, I don't think we can implement the make targets that you suggested easily. In my previous proposal, your make tr_begin and make tr_test steps were combined into a make updateqm when -DTRANS_KEEP_OBSOLETE=ON. The make tr_end step is accomplished by rerunning cmake without -DTRANS_KEEP_OBSOLETE=ON and then make updateqm. (this is all assuming you've built the binary with make. So to recap:

1. Setup: cd antimicro mkdir build cd build cmake -DUPDATE_TRANSLATIONS=ON -DTRANS_KEEP_OBSOLETE=ON .. make make updateqm
2. Work on translation: (edit in Linguist) make updateqm bin/antimicro & (repeat until happy)
3. Complete work: cmake -DUPDATE_TRANSLATIONS=ON .. make updateqm git add ../share/antimicro/translations/<FILE> git commit -m "Updated translation"

Not quite as intuitive as your proposal, but very straightforward from a CMake point of view. Is this sufficient? Too confusing? Thoughts?

[zzpxyx]

@jsbackus I think it's fine not to implement it. I tried the above workflow but I found an issue. I think CMake has a cache or something, so the TRANS_KEEP_OBSOLETE parameter is still set to ON when doing the second part (complete work) steps. As a result, obsolete strings are not purged.

I tried CMake with turning TRANS_KEEP_OBSOLETE off, but surprisingly it wiped out all translated strings and gave me a fresh start. I did a bit investigation, but I couldn't understand what happened.

[jsbackus]

@zzpxyx :confounded: The more I use CMake, the less I like it... Argh. Sounds like the last step may involve removing the build directory before rerunning cmake. hmmm...

[zzpxyx]

@jsbackus Sure. Maybe it's better to use lupdate and lrelease directly as before. They never let me down.

[jsbackus]

@zzpxyx Sounds like a good idea. I've removed the ability to use -no-obsolete from the build system to prevent accidents. I've also created an empty wiki page for us to incorporate information on adding translations. Please feel free to edit as you like. I'll try to add what little I know to the page, too.

[jsbackus]

I've finished updating the Changelog. So we are just waiting on any updated translations before releasing. I have the following list:

• @zzpxyx Chinese
• @7185 French
• @WAZAAAAA0 Italian

Have I missed anyone?

[zzpxyx]

@jsbackus Thanks! I've populated the wiki page with things that I can think of. I also added a link for it on the home page. Feel free to edit them!

[WAZAAAAA0]

@jsbackus Just opened an issue about it https://github.com/AntiMicro/antimicro/issues/20

[jsbackus]

@zzpxyx Very nice work! Thanks!

@WAZAAAAA0 Thanks! Very helpful to me to keep track of things. :smile:

[WAZAAAAA0]

@jsbackus is right now the sole "AntiMicro member" of the organization. What happens to the repository should he suddenly disappear for some reason... I guess it would become impossible to edit? I believe we need more members with write/admin rights just to be safe.

[jsbackus]

@WAZAAAAA0 Agreed. I don't have any interest in being the sole person with the keys, though @zzpxyx does have commit rights. Just waiting on people to e-mail me and ask. :smile: I don't mind giving access to anyone who is active and participating.

Which brings up another point: hopefully others are keeping local copies of the main repo and the wiki. Don't know how to manage the issues with git, but we can have back ups of the other two.

[jsbackus]

We finally did it! Version 2.22 released this morning. Windows binaries are available now. An update for Fedora is in the works and should be available through the official repository soon. @ProfessorKaos64 , @slacknk, would you please generate Debian and Slack updates? Thanks!

Thanks to everyone for their hard work in rebuilding the repo and wiki and getting us to release!

[mdeguzis]

WIll do.

[slacknk]

@jsbackus https://github.com/AntiMicro/antimicro/issues/26#issuecomment-236382204 (about slackware)

[7185]

Congratulations on the release! Sadly I don't have the time to work on the French translation improvements, but it's still on my todo list if nobody else submits a PR before me :smile:
I just updated the package template for Void Linux, so this new version is already available there. Thank you everyone! :tada:

[jsbackus]

@ProfessorKaos64 Thanks! My preference is to point to your package pool, if that is ok. I added a comment in the README. Please let me know if that needs to be corrected.

@slacknk Thanks! I've updated the README and left additional comments in #26.

@7185 Thanks! No worries, I can completely relate. :smile: Please submit a PR when you do have time. Thanks for updating the template for Void! If there is a link, I'll add it to the README.