Bug 788421 - python-kitchen 1.1.0 break translation in yumex (partly)
Summary: python-kitchen 1.1.0 break translation in yumex (partly)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: python-kitchen
Version: 16
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Dennis Gilmore
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-08 08:04 UTC by dominique
Modified: 2012-02-15 23:55 UTC (History)
4 users (show)

Fixed In Version: python-kitchen-1.1.1-1.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-15 23:55:13 UTC


Attachments (Terms of Use)
yumex with python-kitchen-1.0.0-1.fc16.noarch (91.16 KB, image/png)
2012-02-14 05:58 UTC, Tim Lauridsen
no flags Details
yumex with python-kitchen-1.1.0-1.fc16.noarch (91.61 KB, image/png)
2012-02-14 06:00 UTC, Tim Lauridsen
no flags Details

Description dominique 2012-02-08 08:04:56 UTC
I use yumex in my locale (french) and since recent versions yumex is not totally translate (I look the fr.po, and all are translate).
Many strings in yumex.glade are not translate (but they are marked "translatable="yes" )
Also strings in /src/yumexbase/constants.py (but they are marked with _(), and would be translate...)

And in other files...

Where'is the problem ? 
With glade, PyGTK or other ?

for test I want edit the yumex.glade with glade, but that crash...

Comment 1 dominique 2012-02-09 15:34:56 UTC
For test I launch yumex with different locale (de and it) and I have this warning 

[dominique@localhost ~]$ LANG=de yumex

(process:17304): Gtk-WARNING **: Locale not supported by C library.
        Using the fallback 'C' locale.


[dominique@localhost ~]$ LANG=it yumex

(process:17389): Gtk-WARNING **: Locale not supported by C library.
        Using the fallback 'C' locale.
 
And with that yumex is in English...

 If that help you...

Comment 2 dominique 2012-02-13 05:16:15 UTC
After many research, I find where is the problem : it's python-kitchen package.

With python-kitchen 1.1.0-1translation don't work properly, but downgrading to python-kitchen 1.0.0-1solve problem.

Can you re-assign this bug to maintainer of python-kitchen, or can I open new bug report ?

Comment 3 Tim Lauridsen 2012-02-14 05:58:32 UTC
Created attachment 561755 [details]
yumex with python-kitchen-1.0.0-1.fc16.noarch

LANG=da_DK.utf8 yumex

the view column headers are translated to danish.

Comment 4 Tim Lauridsen 2012-02-14 06:00:03 UTC
Created attachment 561757 [details]
yumex with python-kitchen-1.1.0-1.fc16.noarch

LANG=da_DK.utf8 yumex

the view headers is not translated to danish

Comment 5 Tim Lauridsen 2012-02-14 06:07:54 UTC
yumex setup the translation wrappers like this

from kitchen.i18n import easy_gettext_setup
_, P_  = easy_gettext_setup('yumex')

Comment 6 Toshio Ernie Kuratomi 2012-02-14 15:24:12 UTC
LANG doesn't work for me at all.  I s4et LC_ALL=da_DK.utf8 yumex and replicated the problem.  Looking into it.

Comment 7 Toshio Ernie Kuratomi 2012-02-14 16:07:46 UTC
Found the issue.  kitchen-1.1.x treats the list of directories to search for locale files slightly differently than kitchen-1.0.x.  The new code was passing the default directory to search as a string instead of as a list.

I'll have a fixed package into the Fedora updates stream today.  It is a critpath package so it'll need some karma upvoting to get into Fedora in a timely manner.

A workaround that can be done in yumex code (should the kitchen update get stuck in updates for an extended period) would be:

_, P_  = easy_gettext_setup('yumex', localedirs=['/usr/share/locale'])

Comment 8 dominique 2012-02-14 17:05:41 UTC
(In reply to comment #7)
> Found the issue.  kitchen-1.1.x treats the list of directories to search for
> locale files slightly differently than kitchen-1.0.x.  The new code was passing
> the default directory to search as a string instead of as a list.
> 
> I'll have a fixed package into the Fedora updates stream today.  It is a
> critpath package so it'll need some karma upvoting to get into Fedora in a
> timely manner.
> 
> A workaround that can be done in yumex code (should the kitchen update get
> stuck in updates for an extended period) would be:
> 
> _, P_  = easy_gettext_setup('yumex', localedirs=['/usr/share/locale'])

I test your workaround, but that's don't solve problem, yumex with python-kitchen 1.1.0-1 is not all translate in french... Where can I get your fixed package, for test ?

Comment 9 Toshio Ernie Kuratomi 2012-02-14 17:22:22 UTC
If you can tell me how to reproduce, I'd be happy to take a look for other issues.

What is your setting for LC_ALL?

What is the string/place in the user interface that isn't being translated?

Comment 10 Tim Lauridsen 2012-02-14 17:50:22 UTC
I have tried to make this change to yumex

_, P_  = easy_gettext_setup('yumex', localedirs=[os.path.join(sys.prefix, 'lib', 'locale')])

LC_ALL=da_DK.utf8 yumex

or

LANG=da_DK.utf8 yumex 

gives the same result as the attached screenshot (kitchen 1.1.0)

The view header title is not translated

Comment 11 Toshio Ernie Kuratomi 2012-02-14 18:13:40 UTC
@dominique

I could not find any English phrases when I did this:

$ LC_ALL=fr_FR.utf8 yumex

with the workaround I posted.  Did you make the change in:
/usr/lib/python2.7/site-packages/yumexbase/__init__.py

- _, P_  = easy_gettext_setup('yumex') 
+ _, P_  = easy_gettext_setup('yumex', localedirs=['/usr/share/locale'])

I'm going to go ahead and make this kitchen release to get it into the fedora
update system asap as it looks to me like there is a separate issue that might
be in yumex or in your setup at home that's causing this to continue failing.

@timlau

s/lib/share/

Like this:

_, P_  = easy_gettext_setup('yumex', localedirs=[os.path.join(sys.prefix,
'share', 'locale')])

Comment 12 dominique 2012-02-14 18:52:30 UTC
Ok...
If I add _, P_  = easy_gettext_setup('yumex', localedirs=['/usr/share/locale']) directly in /usr/lib/python2.7/site-packages/yumexbase/__init__.py, all are translate...

I don't no why, but in the previous attempt I make this change in yumex source (yumex/src/yumexbase/__init__.py) before make an rpm and install it, but this change don't appear in /usr/lib/python2.7/site-packages/yumexbase/__init__.py...

Comment 13 Fedora Update System 2012-02-14 19:26:51 UTC
python-kitchen-1.1.1-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/python-kitchen-1.1.1-1.fc16

Comment 14 Toshio Ernie Kuratomi 2012-02-14 19:30:55 UTC
I've built updates for all non-EOL Fedora and EPEL.  Only filled in the bug field for the F-16 version here so that this bug doesn't get a huge amount of bodhi-postings.

If you're interested in testing on other releases, the list of bodhi update pages is here:

https://admin.fedoraproject.org/updates/search/python-kitchen-1.1.1

Comment 15 Tim Lauridsen 2012-02-15 06:24:55 UTC
Tested the new version of kitchen, without the workaround, it solves the issue for me.

Thanks a lot for fixing it :)

Comment 16 dominique 2012-02-15 06:44:58 UTC
(In reply to comment #15)
> Tested the new version of kitchen, without the workaround, it solves the issue
> for me.
> 
> Thanks a lot for fixing it :)

also tested the new version of python-kitchen, without the workaround. Translation is complete.

Thank for your re-activity...

I think you can close the bug.

Comment 17 Fedora Update System 2012-02-15 11:28:32 UTC
Package python-kitchen-1.1.1-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing python-kitchen-1.1.1-1.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-1667/python-kitchen-1.1.1-1.fc16
then log in and leave karma (feedback).

Comment 18 Fedora Update System 2012-02-15 23:55:13 UTC
python-kitchen-1.1.1-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.