Add commandline processing to launch.py

[ferdnyc]

This adds standard Python argparse handling for command-line arguments to
launch.py, which now responds to --help with:

$ src/launch.py --help
Loaded modules from current directory: /home/ferd/rpmbuild/REPOS/openshot-qt/src
usage: launch.py [-h] [--list-languages] [-V]

OpenShot version 2.4.2

optional arguments:
  -h, --help        show this help message and exit
  --list-languages  List all language codes supported by OpenShot
  -V, --version

There is also commented out code for another argument, --lang, to set the
interface language on the command line via language code (as listed using
--list-languages). That will require the changes from from PR #1795
before it can be enabled.

[ferdnyc]

The output of --list-lang (long args can be abbreviated as long as they're unique) on my system is:

$ src/launch.py --list-lang
Loaded modules from current directory: /home/ferd/rpmbuild/REPOS/openshot-qt/src
Supported Languages:
         en_US  American English
            mk  Македонски
            hu  Magyar
            is  Íslenska
            bg  Български
            ms  Bahasa Melayu
         pt_BR  Português
            gl  Galego
           ber  
   ca@valencia  Català
            pt  Português
            ko  한국어
            ug  ئۇيغۇرچە
         zh_TW  繁體中文
            my  မြန်မာ
         fr_CA  Français Canadien
           shn  
            si  සිංහල
            lv  Latviešu
            tr  Türkçe
         en_CA  Canadian English
            vi  Tiếng Việt
            et  Eesti
      sr@latin  Српски
            id  Indonesia
            cy  Cymraeg
            ne  नेपाली
            sv  Svenska
            az  Azərbaycan
            nl  Nederlands
            bs  Bosanski
           gaa  
         zh_HK  繁體中文
            la  
            be  Беларуская
            bn  বাংলা
           ady  
            es  Español De España
            ar  العربية
            ky  Кыргызча
            af  Afrikaans
            br  Brezhoneg
         en_AU  Australian English
            te  తెలుగు
           nap  
           kab  Taqbaylit
            ja  日本語
            ia  
           ckb  کوردیی ناوەندی
            jv  
            da  Dansk
            sk  Slovenčina
            tt  
            de  Deutsch
            ku  
            ta  தமிழ்
            fr  Français
            lt  Lietuvių
            am  አማርኛ
            fy  West-Frysk
            el  Ελληνικά
            kn  ಕನ್ನಡ
            eo  
            kk  Қазақ Тілі
            fi  Suomi
            eu  Euskara
            uz  O‘Zbek
            sq  Shqip
            fo  Føroyskt
           ast  Asturianu
            nb  Norsk Bokmål
            hy  Հայերեն
           fil  Filipino
            ml  മലയാളം
            nn  Nynorsk
            mn  Монгол
            uk  Українська
            sl  Slovenščina
            ro  Română
         zh_CN  简体中文
            ru  Русский
            pa  ਪੰਜਾਬੀ
            he  עברית
            cs  Čeština
            se  Davvisámegiella
            oc  
            ca  Català
            th  ไทย
            fa  فارسی
            hr  Hrvatski
         en_GB  British English
            sr  Српски
            ka  ქართული
            it  Italiano
            hi  हिन्दी
            pl  Polski

(But when the new translation-loading code in #1795 gets merged, it'll be sorted English-alphabetically by country code, instead of that random mess you see now.)

[ferdnyc]

...Aaaand, I just realized this text needs to be translatable. (I guess? Not really sure how that works on the command line. Obviously, the flags can't be localized.. can they? Anyway, the descriptive text probably should be.)

[DylanC]

@ferdnyc - Maybe the descriptive text.. not sure really. 😆 Do you think we need to have those translated before merging or can we just merge to solve the majority of translation problems.

[ferdnyc]

@DylanC My general thoughts on that, I left in this comment, which was on N3WWN's closed-and-reopened-against-develop "Save Current Frame" PR:

Honestly, I think at some point new strings have to go into the code, so that they're available to be translated. Translators work off of a list of translatable strings present in the source, so it's sort of a catch-22.

Don't get me wrong, in the run-up to a release I definitely understand the need not to introduce any new translatable elements. But post-release, the earlier new strings go in, the more opportunity there is to get them translated.

Now, that being said, it's probably a very good idea if we have some procedure defined for (a) tracking and (b) announcing the addition of new strings that require translation into the code, since presumably there are translators who could be informed of those events and asked if they'd very kindly help out with the needed translations. I mean, some of this is assumptions on my part, I really don't know how the process of getting OpenShot translated functions, from a practical standpoint. @jonoomph is definitely the expert we need on that front.

But I'd suggest, for starters, creating a tag that gets applied to any PR that adds or modifies translatable strings in the code, since merging those PRs should be treated as a Bigger Deal than merging any other sort of code change.

...However, if we were talking about Qt code for the interface, the requirement would have to be that the strings are translat-able, that is, they're properly wrapped in the _(" ") shortcut that's used to designate strings that should be run through the QTranslator.

The strings in this PR are neither, because at the point launch.py is running QTranslator isn't started yet, as the QtCoreApplication() hasn't launched. So, the normal mechanism isn't available to translate them, and they aren't able to be translatable currently. As a result, there are no new translatable strings in this PR. (So, under my suggested system, it wouldn't even qualify for that tag.)

But because these are purely developer/tester options that aren't intended for enduser use, my feeling is that it's OK for them to go untranslated, the same way the log files OpenShot outputs aren't translated. At least for now. IMHO.

(If we do manage to make the output translatable and get translations at some later point, great.)

[DylanC]

@ferdnyc - No problem. I'm familiar with QTranslator and how it works. If we don't have it available yet I don't see any point in holding back this PR for now. 👍

[ferdnyc]

No problem. I'm familiar with QTranslator how it works.

Sorry, didn't mean to imply otherwise. I have a tendency to be overly detailed. Not because I feel I'm imparting any great insights, or even that I'm under the impression I'm saying anything that isn't already understood by everyone involved. In fact, that's kind of the whole idea: By laying out my own assumptions and understanding, I can confirm that I'm on the same page as everybody else. And if there's anything I've got wrong I can be challenged or corrected on it, hopefully before I proceed down a wrong path based on that misconception. (Which is why I'll often end up correcting or amending my own posts well after the fact, once I've gotten a better grasp of whatever I was previously discussing and realize that there were wild inaccuracies in my earlier statements.)

Heck, you probably know way more about QTranslator than I do, since I still feel like I understand nothing about how and what it really does. I've only just barely managed to grok what I needed in order to break (and hopefully rebuild) the language-selection code in OpenShot.

Which reminds me, I should really finish that up. I have to just put the tutorial code down and focus on something else for now, and it would be good to get the translation-handling streamlined and merge-able (or at least merge-ready, since I still think it needs more testing by more people before anyone should consider merging it.)

[DylanC]

@ferdnyc - Its no problem. I wasn't offended or anything like that. I'm only saying that I do know it or know a certain amount about using it. I've developed my own project in C++ and Qt5. Soon my app will be in Debian (Unstable).

I have an implementation of translations in my project but its extremely simple. It reads the language from the preferences but if that folder doesn't exist it sets the language based on the system locale as the default. Its nothing fancy but it works for users and users have reported it to "work well", which is good enough for me.

My knowledge reaches as far as Qt5 but I don't know Python at all. This is why I feel a bit limited on code contributions to the project. LibOpenShot is also a bit different to using C++ for a frontend, so I'm a bit limited on that aspect too.