Re: find_lang

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
>