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 Reproducible: Steps to Reproduce:
Keywords: (none) => TriagedAssignee: bugsquad => oliver.bgr
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 Abort 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) => cjwAssignee: oliver.bgr => dglent
I have also the same message and quitting I asked here: http://ffdiaporama.tuxfamily.org/Forum/viewtopic.php?id=811 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: http://ffdiaporama.tuxfamily.org/?page_id=3635&lang=en
@dglent This bug is not about modifying translations so I'm not sure what you mean with that comment.
If the translations in the rpm are the translation in upstream why you want to prevent their update ?
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?
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 ?
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.
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.
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: http://ffdiaporama.tuxfamily.org/Forum/viewtopic.php?id=812
> 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.
No activity from upstream, but bug was fixed.
Status: NEW => RESOLVEDResolution: (none) => FIXED