Re: find_lang

2012/1/24 Alexander Khryukin <[email protected]>

>
>
> 2012/1/23 Jeffrey Johnson <[email protected]>
>
>>
>> On Jan 23, 2012, at 7:43 AM, Dmitry Mikhirev wrote:
>>
>> > On Mon, 23 Jan 2012 13:24:41 +0100
>> > Per Øyvind Karlsen <[email protected]> wrote:
>> >
>> >> Den 11:46 23. januar 2012 skrev Dmitry Mikhirev
>> >> <[email protected]> følgende:
>> >>> On Mon, 23 Jan 2012 11:14:04 +0100
>> >>> Per Øyvind Karlsen <[email protected]> wrote:
>> >>>
>> >>>> Den 10:55 23. januar 2012 skrev Dmitry Mikhirev
>> >>>> <[email protected]> følgende:
>> >>>>> On Mon, 28 Nov 2011 20:59:24 +0100
>> >>>>> Per Øyvind Karlsen <[email protected]> wrote:
>> >>>>>
>> >>>>>> Den 20:23 28. november 2011 skrev Tomasz Paweł Gajc
>> >>>>>> <[email protected]> følgende:
>> >>>>>>>
>> >>>>>>> Does this macro still work ?
>> >>>>>> Yes, but /usr/lib/rpm/mandriva/find-lang.pl has been replaced by
>> >>>>>> rpm's own /usr/lib/rpm/find-lang.sh.
>> >>>>>>
>> >>>>>> It has two important behaviour changes:
>> >>>>>> * If specifying multiple names, they need to be specified first,
>> >>>>>> while the last argument needs to
>> >>>>>> be the output filename, ie. the following:
>> >>>>>>
>> >>>>>> %find_lang foo foo bar
>> >>>>>>
>> >>>>>> Needs to be changed to:
>> >>>>>> %find_lang foo bar foo.lang
>> >>>>>>
>> >>>>>> * If no files are found, the script will exit with an error
>> >>>>>> status rather than creating an empty .lang file
>> >>>>>> This will break build of packages which incorrectly uses
>> >>>>>> %find_lang where there are no language files
>> >>>>>> to find since the 'foo.lang' file used with '%files -f foo.lang'
>> >>>>>> won't be created.
>> >>>>>> find-lang.sh will report there being no language files found
>> >>>>>> when exiting with error, so should be easy to
>> >>>>>> understand and fix. :)
>> >>>>>>
>> >>>>>> --
>> >>>>>> Regards,
>> >>>>>> Per Øyvind
>> >>>>>>
>> >>>>>
>> >>>>> I have a problem with finding localization files in qupzilla
>> >>>>> package. They are located in %{_datadir}/%{name}/locale/*.qm, but
>> >>>>> macro
>> >>>> Locale files probably not found in the expected location, should
>> >>>> likely be %{_datadir}/locale rather than
>> >>>> %{_datadir}/%{name}/locale..?
>> >>>
>> >>> It is common for Qt apps to keep locale files in
>> >>> %{_datadir}/%{name}/locale or %{_datadir}/%{name}/translations. You
>> >>> can check
>> >>> urpmq -l arora | grep '\.qm$'
>> >>> or
>> >>> urpmq -l smplayer | grep '\.qm$'
>> >>> to ensure.
>> >>>
>> >>>>>
>> >>>>> %find_lang %{name} --with-qt
>> >>>>>
>> >>>>> fails... Is it my mistake or find_lang error?
>> >>>> Your! :p
>> >>>>
>> >>> I'm still not sure. :-)
>> >> Yupp, seems like I was a bit too quick on this one, was looking at
>> >> the wrong lines of find-lang.sh.. :p
>> >>
>> >> The reason for the breakage is that it looks for translation files
>> >> with '%{name}'
>> >> in it, and it also seems as there's some inconsistencies in the
>> >> naming of these translation files as well.. :|
>> >> One can workaround this by passing --all-name so that it'll pick up
>> >> all translations.
>> >>
>> >> I've commited fixes for qupzilla to svn resolving this. :)
>> >>
>> >
>> > Thank you! But wouldn't it be better not to search %{name} in filename
>> > if --with-qt specified? AFAIK it is very common not to include program
>> > name to *.qm file names.
>> >
>>
>> What is needed is regularity in how various applications handle i18n.
>>
>> Without regularity, the find_lang script breaks repeatedly.
>>
>> The find_lang script has broken at least 3 times this fall with
>> various discussions about how to best fix.
>>
>> But the realities are essentially this:
>>        Applications have many ad hoc techniques for handling i18n.
>>        The expectation with %find_lang usage in *.spec recipes is Just
>> Works.
>> The conclusion (and prediction) is that %find_lang will break again
>> within weeks.
>>
>> Note that the >300 locales being carried around in linux distros
>> who have no market which needs most of the locales is a pleasantly
>> inclusive "community" lie.
>>
>> How many people -- besides Alan Cox -- can read Welsh?
>>
>> hth
>>
>> 73 de Jeff
>>
>> hth
>>
>> 73 de Jeff
>> > --
>> > Best regards,
>> >            Dmitry Mikhirev
>> >
>> > http://gnu.linuxcenter.ru
>> >
>>
>>
>>
>
> thread bump.
>
> I have same error.
>
> Package: wesnoth
> In output i have a lot of *.mo files
> but macro
>
> %find_lang %{name} --all-name
>
> %files -f %{name}.lang
>
> not working.
> How to fix it?
>
> ........
-- Installing:
/home/user/wesnoth/BUILDROOT/wesnoth-1.10-1-mdv2012.0.x86_64-buildroot/usr/share/games/wesnoth/translations/zh_TW/LC_MESSAGES/wesnoth-utbs.mo
-- Installing:
/home/user/wesnoth/BUILDROOT/wesnoth-1.10-1-mdv2012.0.x86_64-buildroot/usr/share/games/wesnoth/translations/zh_TW/LC_MESSAGES/wesnoth-manpages.mo
-- Installing:
/home/user/wesnoth/BUILDROOT/wesnoth-1.10-1-mdv2012.0.x86_64-buildroot/usr/share/games/wesnoth/translations/zh_TW/LC_MESSAGES/wesnoth-manual.mo
-- Installing:
/home/user/wesnoth/BUILDROOT/wesnoth-1.10-1-mdv2012.0.x86_64-buildroot/usr/games/wesnoth
-- Installing:
/home/user/wesnoth/BUILDROOT/wesnoth-1.10-1-mdv2012.0.x86_64-buildroot/usr/games/wesnothd
make: Leaving directory `/home/user/wesnoth/BUILD/wesnoth-1.10/build'
+ /usr/lib/rpm/find-lang.sh
/home/user/wesnoth/BUILDROOT/wesnoth-1.10-1-mdv2012.0.x86_64-buildroot
wesnoth --all-name
No translations found for wesnoth in
/home/user/wesnoth/BUILDROOT/wesnoth-1.10-1-mdv2012.0.x86_64-buildroot
error: Bad exit status from /home/user/wesnoth/BUILDROOT/rpm-tmp.13804
(%install)