Hello, need help to get argos-translate-gui to work again after QT5 update:

Error message: Cannot mix incompatible Qt library (5.15.2) with this library (5.15.3) Aborted (core dumped)

I already tried to fix the issue and made the update of: qt5-styleplugins 5.0.0.20170311-28

But it did not help. Thanks for help, Kind regards, Michael

When using the GUI to fetch a new language pair, the process crashed out of the pure blue without reason. The GUI window disappeared, and the terminal showed a dump of how many bytes were fetched and how many were not. It did not say why it crashed, but after eating up ~80mb of a measured rate service I was stuffed. I switched to the CLI method (argospm) in hopes of getting more verbosity. I got zero verbosity and not only that but it started over from the beginning. It should have already had ~99% of the file.

Apparently the GUI downloader uses different code than argospm (as they are storing the data in different locations). So the GUI and argospm both need a crash recovery mechanism. This bug report is for the GUI downloader.

Mirroring this bug here:

https://github.com/argosopentech/argos-translate/issues/253

It’s actually the GUI side that should address this problem because it’s the GUI that fails to document the storage location.

This command should tell me where the GUI-fetched lang pair data ended up:

find ~ -iname \*argosmodel

But no, it only shows one file:

~/.local/cache/argos-translate/downloads/translate-fr_en.argosmodel

That file was fetched using argospm. There should be another file for a different language pair that was fetched using the GUI. Where did that data go?

(edit) It seems the GUI downloader is storing the data in an unpacked format, so it creates: ~/share/argos-translate/packages/«lang pair»/model/model.bin

In fact, it seems all lang pairs are stored in ~/share/argos-translate/packages/, the GUI and CLI just have a difference in cleanup procedures, assuming the *argosmodel file is temporary and discardable.

Usually the text that will be entered as a query on the left is in the clipboard. But then there is text already in the field saying “text to translate from”. When pasting the clipboard in that box, the msg does not clear, so the “text to translate from” becomes part of the translation. If the text is removed at that point, then it takes a very long time to reprocess the whole translation again. And the new request does not interrupt the backend process that’s still working on the 1st snip of text, so both versions must be fully translated before the user can see the result.

Suppose the user clears the hint text first, and in the fastest way possible (by selecting all the text and hitting delete). The act of selecting the text clobbers the clipboard in many linux desktop managers, so they must recopy the text. But if the text is removed by hitting delete one character at a time, then the backend works to submit a new translation each time a character is removed.

After using this installation procedure (as root):

pip3 install --log-file ~/log/pip3-argostranslategui.err --log ~/log/pip3-argostranslategui.log --cache-dir /usr/local/pkgs argostranslategui

No man page was created. And when running argos-translate-gui -h, the GUI app is launched without giving help output. There should be a help page no matter how trivial it is so that users at least see that there are no options. Some things that should be covered by the help page:

• Since the GUI does take the liberty of connecting to the Internet (to download lang pairs), users would expect to see a --proxy option or absence thereof.

• A “bugs” section to tell users where to report bugs. (Which btw would ideally not force users to interact with MS Github.)

• Information about where lang pair libs are stored, most particularly because this differs from the CLI version.

doc bug 2:

These installation instructions should tell users how to install it systemwide (as root) and how to install it individually for one user:

https://github.com/argosopentech/argos-translate-gui#install

ATM it makes no mention of root, but it should say to run as root if that’s the only way. I know from experimentation that those instructions work for root but I’ve not tested as a user.

Those installation instructions should also disclose 2 sizes: the download size for bandwidth calculations (for those on measured rate connections) and the installation size after everything is unpacked. Normal mainstream package managers (like aptitude) generally give users that info by design, but since pip3 is quite underdeveloped it does not give that info so it should be documented.

pip3 quietly dumps downloaded installation files in /tmp/ without telling users where the files are. This is dicey particularly if the download is interrupted. So I would propose suggesting use of the --cache-dir option to users. It might sound like too much hand-holding, but pip3 is a developer tool -- it was never intended for normal users. And pip3 is very poorly documented. That is, the man page and help page are inconsistent with each other and with what the software does.