Bug 14567 - ffdiaporama downloads translations from the Internet
Summary: ffdiaporama downloads translations from the Internet
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Dimitrios Glentadakis
QA Contact:
Keywords: Triaged
Depends on:
Reported: 2014-11-15 22:09 CET by Alex Loginov
Modified: 2014-11-27 21:12 CET (History)
1 user (show)

See Also:
Source RPM: ffdiaporama
Status comment:


Description Alex Loginov 2014-11-15 22:09:07 CET
Description of problem: ffdiaporama should use translations from RPM package, but it does not work.

Version-Release number of selected component (if applicable): ffdiaporama-2.1.9.devel.2014.0701-4.mga5.i586.rpm

How reproducible: always with disabled Internet

Steps to Reproduce:
1. delete configs from $HOME/.ffDiaporama dir
2. disable the Internet
3. run ffDiaporama
4. see logs in console
5. if to enable the Internet, delete configs from $HOME/.ffDiaporama dir, run ffDiaporama, then translations will be downloaded in $HOME/.ffDiaporama dir


Steps to Reproduce:
Alex Loginov 2014-11-15 22:10:25 CET

Keywords: (none) => Triaged
Assignee: bugsquad => oliver.bgr

Comment 1 Christiaan Welvaart 2014-11-16 05:25:23 CET
Does ffdiaporama work for you? Here it crashes at the end (abort), although the output file appears to work anyway. Render settings: "multimedia system", 720p.

[...:ERROR]	LIBAV: Assertion next_dts >= 0 failed at libavformat/movenc.c:652

Also, the preview function(?) doesn't work, it says "using null output device, none available".

Anyway, I think I fixed the locale download problem in  ffdiaporama-2.1.9.devel.2014.0701-5.mga5

CC: (none) => cjw
Assignee: oliver.bgr => dglent

Comment 2 Dimitrios Glentadakis 2014-11-16 08:57:25 CET
I have also the same message and quitting
I asked here:

I have an objection about the translations:
Why having different translations than upstream in the rpm ?
If you update a translation then it has to be sent upstream:
Comment 3 Christiaan Welvaart 2014-11-16 10:48:39 CET
@dglent This bug is not about modifying translations so I'm not sure what you mean with that comment.
Comment 4 Dimitrios Glentadakis 2014-11-16 11:12:11 CET
If the translations in the rpm are the translation in upstream why you want to prevent their update ?
Comment 5 Christiaan Welvaart 2014-11-16 11:21:18 CET
ffdiaporama did not use the translations in the rpm at all, see bug description.

Normal users can't update the translations in /usr/share/ffdiaporama/locale (nor should they, these files belong to the rpm package).

Downloading newer translations in users' homedirs... I'm not sure that's a good idea, isn't it better if you update the translations in the rpm?
Comment 6 Dimitrios Glentadakis 2014-11-16 11:31:24 CET
This is a feature for tha cases where there are updates of translations, so you do not have to wait the next version of the application.

The translations that being downloaded are newer of the translations in the rpm
Why you should use the translations of the rpm instead of the newest?

This is handled by the program at every startup it checks if there are newer translations

How you will manage it if you have to update the rpm after every new translation ?
Comment 7 Christiaan Welvaart 2014-11-16 11:55:38 CET
No, AFAICT it was NOT checking against the rpm package's translations at all. It only checked if any *downloaded* translations in the user's home dir are old => no internet = no translations.

I was only fixing this bug, if you can fix it and keep the translation-download feature, fine.  You might want to report the problem upstream.

ffDiaporama should then do something like:
  - check if bundled translations in $(workingdir) are old
    - if old, check if up-to-date translations are in user home dir
      - if not, try to download translations
  - use the most current translations it found/downloaded.

BTW this is how it works with most applications, translations are updated together with the rest of the application.

Some users may not like such an automatic download function because it's a phone-home feature that can tell the developer(s) who uses their software and when.
Comment 8 Alex Loginov 2014-11-16 12:11:50 CET
ffdiaporama should use translations from RPM with disabled Internet for the first start.
Sometimes we add patches for disable check new version of program, so, we can add patch for disable check new translations also (yes, it's upstream future, but not for RPM). ffdiaporama will start faster. So I'm partially agree with patches from Christiaan.
Translations should be updated by new RPM pkg.
But Dimitrios worries: we goes against upstream. So better to add option for building. In this case we will be together with upstream.

For example, I wanted to use system locales for fet, but author did not want. After discuss with him he added new option for me "USE_SYSTEM_LOCALE" for qmake: http://svnweb.mageia.org/packages/cauldron/fet/current/SPECS/fet.spec?view=markup and all are happy.
Comment 9 Dimitrios Glentadakis 2014-11-16 12:19:05 CET
Finally i agree because i was with the impression that the translations was just in second priority than the qm files in $HOME

The expected behaviour would be if it uses the installed translations and when internet availbe it downloads the updated (as i thought that it was) 

i asked about it here:
Comment 10 Alex Loginov 2014-11-16 12:25:09 CET
> Some users may not like such an automatic download function because it's a
> phone-home feature that can tell the developer(s) who uses their software and
> when.
Yes, our 3G Internet is very slow and expensive, and users don't want to pay for non-controlled automatic downloads.
So, Christiaan works in the right way, but better to work together with upstream and to discuss new option. Anyway his patch is short, so if upstream will ignore, then no big problem.
Comment 11 Alex Loginov 2014-11-27 21:12:09 CET
No activity from upstream, but bug was fixed.

Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.