https://bugzilla.redhat.com/show_bug.cgi?id=985065 --- Comment #5 from Mario Blättermann <mario.blaettermann@xxxxxxxxx> --- (In reply to Kevin Kofler from comment #4) > As for the other 2 points, unfortunately, there are some differences between > what is written in the wiki and what is actually true in practice (and all > experienced packagers know): > > > Moreover, the scriptlet doesn't contain anything about mime types. It's only > > for updating the desktop database. > > Actually, update-desktop-database is only needed if the .desktop file claims > any MIME types, otherwise it does nothing (and just wastes the user's time). > OK, then it has to be changed in the wiki. There must not be a difference between the "law" and the "practice". And in no case we may assume that an "experienced packager" knows about that. Then we could also assume a lot of more things, and we could shrink the guidelines to a minimum. > > Please read the comment. The find_lang macro is useful and applicable when > > gettext (or even the qt translation chain) places the language files in > > /usr/share/locale/language_code/LC_MESSAGES/*. > > Actually, it looks for the files with a "find" in the whole RPM_BUILD_ROOT, > so it doesn't matter where they are. Please try it (but don't forget the > --with-qt --without-mo switches if this is using Qt rather than gettext > translations), it should work. OK, I didn't know about the --without-mo switch. It's the first time I work on non-gettext stuff. I've added the macro with the following line: %find_lang -f solitari.lang --with-qt --without-mo But I get this error: + /usr/lib/rpm/find-lang.sh /home/mariobl/rpmbuild/BUILDROOT/peg-solitaire-2.0-3.fc19.x86_64 -f solitari.lang --with-qt --without-mo No translations found for -f in /home/mariobl/rpmbuild/BUILDROOT/peg-solitaire-2.0-3.fc19.x86_64 The problem is, we don't have files named solitari.qm in separate folders for each supported language. All the qm files are in a single folder with the following naming scheme: $ rpm -ql peg-solitaire ... /usr/share/games/peg-solitaire/locales /usr/share/games/peg-solitaire/locales/solitari.qm /usr/share/games/peg-solitaire/locales/solitari_ca_ES.qm /usr/share/games/peg-solitaire/locales/solitari_de_DE.qm /usr/share/games/peg-solitaire/locales/solitari_en_EN.qm /usr/share/games/peg-solitaire/locales/solitari_en_US.qm /usr/share/games/peg-solitaire/locales/solitari_es_ES.qm /usr/share/games/peg-solitaire/locales/solitari_eu_ES.qm /usr/share/games/peg-solitaire/locales/solitari_fr_FR.qm /usr/share/games/peg-solitaire/locales/solitari_gl_ES.qm /usr/share/games/peg-solitaire/locales/solitari_it_IT.qm /usr/share/games/peg-solitaire/locales/solitari_pl_PL.qm /usr/share/games/peg-solitaire/locales/solitari_pt_BR.qm /usr/share/games/peg-solitaire/locales/solitari_pt_PT.qm As another attempt I tried to use a wildcard (solitari*.lang), but it failed again. The guideline says: "Keep in mind that usage of %find_lang in packages containing locales is a MUST." But is it really worth the effort to patch the package to get this script working? Well, we use find_lang to avoid mistakes such as wrong folder ownerships and writing the translation files in a long list [1]. But peg-solitaire behaves different from the usual way, we should keep this in mind. And if I'm really forced to use it, my knowledge is probably too poor to patch the sources in a way that it works. BTW, some of the translations are made by an automatized tool like Google Translator and are of bad quality, at least the German one. This is another reason to avoid the effort. [1] http://fedoraproject.org/wiki/Packaging:Guidelines#Why_do_we_need_to_use_.25find_lang.3F -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=nJIyeQydA5&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review