Bug 584866

(In reply to comment #0)
> Description of problem:
> Quoting from
> https://fedoraproject.org/wiki/Packaging:Guidelines#Why_do_we_need_to_use_.25find_lang.3F
> :
>    Keep in mind that usage of %find_lang in packages containing locales is a
> MUST.
> 
> http://cvs.fedoraproject.org/viewvc/rpms/Django/F-12/Django.spec?view=markup
> (~line 62) shows that %find_lang is not used.
> 
> Additional info:
> I've filled the bug at Tom "spot" Callaway's suggestion.    

Is there also some suggestion about how %find_lang can be used here? Afaik it would not pick up the locales, because it only looks in /usr/share/. So maybe it is also a bug in %find_lang.

Django 1.2 is on it's way (about a month) and I will try to get it to work in that package update if that is OK.

Looks like I can not use find_lang as the translations are not in /usr/share (they are in %{python_sitelib}/django/conf/locale/$LOCALE/django.mo. The use of %find_lang causes the package to fail:


   No translations found for django in /home/steve/rpmbuild/BUILDROOT/Django-1.2-1.fc13.i386
   error: Bad exit status from /var/tmp/rpm-tmp.ETQr5V (%install)

However, I can do:

  %{python_sitelib}/django/conf/locale/ar/django.mo
  %{python_sitelib}/django/conf/locale/be/django.mo
  .. etc ..

Or I could try to recreate a find_lang like result with some scripting in the spec. Thoughts?

Just explicitly list each translation file with the appropriate lang code in the spec, e.g.

%lang(ar) %{python_sitelib}/django/conf/locale/ar/django.mo
%lang(be) %{python_sitelib}/django/conf/locale/be/django.mo

Will do, thanks!

Django 1.2 was released (http://www.djangoproject.com/download/). I am making the changes in the spec for this release now.

Django-1.2-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/Django-1.2-1.fc12

Django-1.2-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/Django-1.2-1.fc11

Django-1.2-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/Django-1.2-1.fc13

Django-1.2-1.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update Django'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/Django-1.2-1.fc12

Django-1.2-1.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update Django'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/Django-1.2-1.fc11

Django-1.2-1.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update Django'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/Django-1.2-1.fc13

(In reply to comment #4)
> Just explicitly list each translation file with the appropriate lang code in
> the spec, e.g.
> 
> %lang(ar) %{python_sitelib}/django/conf/locale/ar/django.mo
> %lang(be) %{python_sitelib}/django/conf/locale/be/django.mo    

In this case shouldn't the guide be updated, perhaps by replacing MUST with SHOULD? Also, the guide should mention that if %find_lang can't be used, an explicit list of translation files must be used.

Well, doing it explicitly is not the ideal method, so I would consider it an acceptable alternative only in the situation where %find_lang doesn't work.

But you're right, it should be documented, I'll work on that.

(In reply to comment #14)
> Well, doing it explicitly is not the ideal method, so I would consider it an
> acceptable alternative only in the situation where %find_lang doesn't work.
> 
> But you're right, it should be documented, I'll work on that.    

Wouldn't it be better to patch %find_lang to make it work in all cases?

(In reply to comment #15)
> (In reply to comment #14)
> > Well, doing it explicitly is not the ideal method, so I would consider it an
> > acceptable alternative only in the situation where %find_lang doesn't work.
> > 
> > But you're right, it should be documented, I'll work on that.    
> 
> Wouldn't it be better to patch %find_lang to make it work in all cases?    

Sure. Accepting patches. :)

Created attachment 415111 [details]
%find_lang support all directories called locale/  containing .mo file

(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > Well, doing it explicitly is not the ideal method, so I would consider it an
> > > acceptable alternative only in the situation where %find_lang doesn't work.
> > > 
> > > But you're right, it should be documented, I'll work on that.    
> > 
> > Wouldn't it be better to patch %find_lang to make it work in all cases?    
> 
> Sure. Accepting patches. :)

Here it is. I patched rpm-4.7.2-1.fc12.

Thanks Till. I've opened a ticket at rpm.org for this issue:
http://rpm.org/ticket/159

FWIW, rawhide rpm has the find-lang fix now.

Till, Panu,

Great news, once it makes it's way through the various dists I'll switch over.

Uh -- I agree with Cristian Ciupitu: either the wording needs to be changed or we need to be using find_lang here:

"""
MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.[9]
"""

None of the other review guidelines use the wording strictly forbidden (which might not technically apply to this bug since we aren't using the exact line %{_datadir}/locale/* but it's unclear whether what's being prohibited is that specific line or non-use of %find_lang).

It's also arguably an FHS violation:
http://www.pathname.com/fhs/pub/fhs-2.3.html#SPECIFICOPTIONS15

"""
The following directories, or symbolic links to directories, must be in /usr/share, if the corresponding subsystem is installed:

locale	Locale information (optional)
"""
Debian moves the locale files for various packages into /usr/share/locale to follow this.

Last note before we decide whether to change the guideline or the package: It's usually very easy to create a patch to a python module to look in the package_dir for the locale directory and if not there, look in /usr/share/locale.  That sort of patch is fairly easy to get into upstream (I haven't had one rejected yet).  You have to be careful not to do what Debian often does and simply replace the directory in the patch, though -- that leads to problems when the code is installed on Windows or MacOS which don't follow the FHS at all.

Web frameworks are slightly harder to do this for since they need to handle translations at two levels -  translating errors for the system admin and translating the user interface for people using app from their browser but they aren't impossible.  I'll attach a patch that looks right -- but I don't have any internationalized Django apps to test against offhand.

Created attachment 415815 [details]
Patch to make django internationalization work with /usr/share/locale

There only seems to be two files that touch the locales.  I think I've gotten all the places in those files that touch them but I could be slightly off on that.  The one that extracts messages for javascript is especially tricky and I may not have gotten it right.  If this works, it should be possible for individuals to install as normal and the locale files will be found and also for packagers to move the .mo files from django/conf/locale/*/LC_MESSAGES/ into /usr/share/locale/ in their rpms/debs/etc and they will be found.

I am happy to submit the patch to upstream and explain why we need to use it (if we indeed need to do so) but I have a feeling they will not apply it. Being that Django is cross platform and that not every platform has /usr/share/locale/ I have a feeling they will want to continue using the python site-packages location.

Of course, that does not stop us from applying the patch and at least trying to get it upstream if the need is there. I'm looking to you guys on this -- from my point of view either using python site-packages or /usr/share/locale/ is OK with me :-).

Note that since there is a 1.2.1 release coming very soon to fix issues found after 1.2 was released I can apply said patch in with that if you guys deem it required.

http://www.djangoproject.com/weblog/2010/may/21/121/

Although I haven't tested the patch, if it does what I expect it to it should be acceptable upstream because it merely adds /usr/share/locale (actually the stdlib gettext fallback which is /usr/share/locale in Fedora) as a fallback.  That means that for developers, people installing into their home directories, people using virtualenv, installations on Windows, etc, the django/conf/locale directory will continue to be searched.  But in the Fedora spec file we would move the message catalogs into place below /usr/share/locale.  The code in Django would look in /usr/lib/site-packages/django/conf/locale, not find a message catalog and fallback to looking in /usr/share/locale for it instead.

Django-1.2.1-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/Django-1.2.1-2.fc12

Django-1.2.1-2.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/Django-1.2.1-2.el5

Django-1.2.1-2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/Django-1.2.1-2.fc13

Django-1.2.1-2.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update Django'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/Django-1.2.1-2.fc12

Django-1.2.1-2.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update Django'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/Django-1.2.1-2.fc13

Django-1.2.1-2.el5 has been pushed to the Fedora EPEL 5 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update Django'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/Django-1.2.1-2.el5

Django-1.2.1-5.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Django-1.2.1-5.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.