'Re: Using i18n'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: Using i18n
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2013-05-06 15:41:56
Message-ID: 1543367.gk92uZnnQo () xps
[Download RAW message or body]

El Dissabte, 4 de maig de 2013, a les 21:24:37, Philipp A. va escriure:
> > i18n only works on utf8 formatted "ascii strings"
> 
> no, as i said, this works: i18n(' ·'.encode('utf-8'))
> 
> " ·" is unicode, not ascii. when i encode it to utf-8 bytes, and call i18n
> on it, i18n flawlessly returns a unicode string, which means that it
> decodes the bytes it's passed as utf-8, not ascii. only if i pass it a
> unicode string, it inexplicably tries to *encode* it to bytes with the
> ascii codec. no idea why, but it's true.
> 
> so what's the case is that i18n works on either
> 1. *utf-8-encoded* byte strings of the whole unicode range

Yeah, that's what i meant with 'utf8 formatted "ascii strings"', wrong wording 
on my side.

That is of course what the C++ i18n function expects, not sure about the 
expectations from the python counterpart.

Cheers,
  Albert

> 2.  unicode strings which happen to only contain characters from the ascii
> range.
> 
> so it accepts only  objects that survive the following treatment:
> 
> def test(t):
>     u = str if sys.version_info.major == 3 else unicode
>     if isinstance(t, u):
>         return t.encode('ascii')
>     else:
>         assert isinstance(t, bytes)
>         return t
> 
> 2013/5/4 Albert Astals Cid <aacid@kde.org>
> 
> > El Divendres, 3 de maig de 2013, a les 22:17:29, Philipp A. va escriure:
> > > well, it is:
> > > >>> from sys import version_info
> > > >>> version_info[:2]
> > > 
> > > (3, 3)
> > > 
> > > >>> from PyKDE4.kdecore import versionString, i18n
> > > >>> versionString()
> > > 
> > > '4.10.2'
> > > 
> > > >>> i18n(' ·'.encode('utf-8'))
> > > 
> > > ' ·'
> > > 
> > > >>> print(i18n(' ·'))
> > > 
> > > Traceback (most recent call last):
> > >   File "<stdin>", line 1, in <module>
> > > 
> > > UnicodeEncodeError: 'ascii' codec can't encode character '\xb7' in
> > 
> > position
> > 
> > > 0: ordinal not in range(128)
> > > 
> > > note that the result of i18n *is* a unicode string, and i18n *accepts*
> > > unicode strings, but only if those unicode strings happen to only
> > > contain
> > > ascii â€“ just like in the bad old python2 times.
> > > 
> > > so i18n is buggy on KDE 4.10, and we have to work around it.
> > 
> > Why is it buggy? i18n only works on utf8 formatted "ascii strings"
> > 
> > Are you expecting something in the python part to do some magic?
> > 
> > Cheers,
> > 
> >   Albert
> >   
> > > 2013/5/3 Shaheed Haque <srhaque@theiet.org>
> > > 
> > > > Just after I hit "send", I found this:
> > > > 
> > > > http://www.mail-archive.com/pyqt@riverbankcomputing.com/msg14058.html
> > > > 
> > > > which suggests this is not an issue???
> > > > 
> > > > On 3 May 2013 20:42, Shaheed Haque <srhaque@theiet.org> wrote:
> > > >> Hi Philipp,
> > > >> 
> > > >> On 3 May 2013 19:56, Philipp A. <flying-sheep@web.de> wrote:
> > > >>> Hi, i've seen some uses of kdecore.i18n popping up in PatÃ© plugins,
> > 
> > and
> > 
> > > >>> have some recommendations:
> > > >>> 
> > > >>> 2. It takes more than one argument. so for the sake of consistency
> > > >>> instead of doing the ugly
> > > >>> 
> > > >>>     i18n(b'foo %(name)s.') % { 'name': 'bar'}
> > > >>> 
> > > >>> or even the better
> > > >>> 
> > > >>>     i18n(b'foo {name}.').format(name='bar')
> > > >>> 
> > > >>> we should do the Qt-style
> > > >>> 
> > > >>>     i18n(b'foo %1.', 'bar')
> > > >>> 
> > > >>> 1.  i18n takes byte strings. even on python3. this means that every
> > 
> > time
> > 
> > > >>> a developer accustomed to python2 who doesn't know it tries to use
> > 
> > it,
> > 
> > > >>> the
> > > >>> plugin WILL break for python3 users.
> > > >> 
> > > >> I've been using the argument syntax of the third form, but simply
> > > >> specified quoted strings (i.e. without the "b" prefix). Without
> > > >> really
> > > >> thinking about it, I had assumed that i18n would have done something
> > > >> plausible on Python2 (not sure exactly what though!), and on Python3
> > 
> > it
> > 
> > > >> would just be Unicode all the way. I'd certainly prefer not avoid
> > 
> > having
> > 
> > > >> to
> > > >> use "b" all over the place.
> > 
> > https://github.com/Werkov/PyQt4/blob/master/examples/tools/i18n/i18n.py
> > 
> > > >> seems to suggest that something like that is possible, but when I
> > > >> went
> > > >> looking for some docs on this, but could not see an obvious spec. Do
> > 
> > you
> > 
> > > >> have a reference handy?
> > > >> 
> > > >> Thanks, Shaheed
> > > >> 
> > > >>> we have to come up with a solution.
> > > >>> 
> > > >>> there is a possible solution here, but it involves a fairly
> > 
> > convoluted
> > 
> > > >>> i18n replacement:
> > https://projects.kde.org/projects/kde/applications/kate/repository/revis
> > 
> > ions/master/entry/addons/kate/pate/src/plugins/python_console_ipython/py
> > 
> > > >>> thon_console_ipython.py#L36
> > > >>> 
> > > >>> should we add that function to libkatepate and call it a day?
> > > >>> 
> > > >>> _______________________________________________
> > > >>> KWrite-Devel mailing list
> > > >>> KWrite-Devel@kde.org
> > > >>> https://mail.kde.org/mailman/listinfo/kwrite-devel
> > > > 
> > > > _______________________________________________
> > > > KWrite-Devel mailing list
> > > > KWrite-Devel@kde.org
> > > > https://mail.kde.org/mailman/listinfo/kwrite-devel
> > 
> > _______________________________________________
> > KWrite-Devel mailing list
> > KWrite-Devel@kde.org
> > https://mail.kde.org/mailman/listinfo/kwrite-devel
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel

[prev in list] [next in list] [prev in thread] [next in thread] 