Re: [Gramps-devel] to bind or not to bind textdomain

[Benny M. <ben...@gm...>]

2013/3/2 Josip <jo...@pi...>

> On 02.03.2013 04:10, John Ralls wrote:
>
> Sometimes this is slower than snailmail :-O
>
> >
> > On Mar 1, 2013, at 12:16 PM, Josip <jo...@pi...> wrote:
> >
> >> Hi all,
> >> in gramps40 r21513 in grampslocale.py i see:
> >>
> >> if not win():
> >>      locale.bindtextdomain(self.localedomain, self.localedir)
> >>
> >> despite recent claim that this is no needed anymore (without providing
> >> example or pointing to changed source code which support this)
> >> So if it is really needed (i think it is!) please fix-it for Windows as
> >> it was working fine in previous versions.
> >>
> >> I also notice few other thing that will never works in Windows like
> >> locale.setlocale() can't be used with locale.getlocale() as second one
> >> returns their "normalized" name and first one use only win names.
> >>
> >> In Windows things are unicode or mbcs, utf-8 is dummy is not realy
> supported
> >>
> >> What is necessary to protect win32 code from removing or replacing in
> >> future? Guard it with "if win():", comment any try-except code with "FOR
> >> WIN32 ONLY" ...?
> >>
> >
> > Yes, I put it back after someone (Jérôme?) reported a failure to
> translate some Glade/GtkBuilder strings, though
> > everything worked for me when I tested on OSX and Debian Wheezy.
>
> I would still like to see some example code or point to changed source
> to be assured.
>
> > It's disabled for Win32 because Helge reported that his python doesn't
> provide it. Is "if not win():" insufficient protection?
>
> It was already commented in gramps code that python don't provide it, it
> relay on libc and works only on system which libc have gettext support.
> It was guarded by "if win()" previously but still removed by someone who
> don't even use Windows.
>
> > Are the GtkBuilder strings getting properly translated on Win32?
> >
> > As for locale.[gs]etlocale(), the best way to not encounter those is to
> make sure that PyICU is installed. We're not there yet,
> > but the goal is to have the python locale module used only as a fallback
> when ICU isn't present.
> >
>
> Yes python locale module is awful and not portable, still if they are
> used it should be used correctly (it was uptil now)
>
> > Data files are what ever we write into them, and that should all always
> be UTF-8 for portability. Win32 *paths and filenames*
> > are UTF-16 or MBCS depending on the Windows version, and we have to
> trust sys.getfilesystemencoding() to give the right
> > answer. Again, paths and filenames, not file contents.
> >
>
> i still dislike comment in grampslocale.getfilesystemencoding
>
> > Regards,
> > John Ralls
> >
>
> Your recent responses on list about what Windows or Python for Windows
> should or have support or not just get me worried for gramps win32
> future, thats all ;-)
>
>
Ok, when we approved backport of trunk locale changes to gramps40, we hoped
it would allow to remove the locale hacks on windows too.
So, to know that for sure:

1/ is it possible to have PyICU on windows? If that is the way forward,
then doing tests with that from the start would not have us fixing locale
things not needed later

2/ if PyICU not possible, I assume the locale win stuff needs to go back
in.? Other options?

About protecting windows code, I think win() should be enough. For this
case, John is redoing the locale stuff, so this is the ideal moment to try
on windows if that is possible there also. If not, the old ways are needed
again.

I remember well the long road to have windows working for sorting
correctly, so personally my hope of the new things 'just' working, was not
that high. On the other hand, John knows GTK and C internals very well, so
if somebody on the Gramps team can manage that, he might.

Benny


> --
> Josip
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Gramps-devel mailing list
> Gra...@li...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>