i18n support

[GoogleCodeExporter]

Add i18n (gettext) support for hardcoded string messages.

tip: validators.required(value)

Original issue reported on code.google.com by conrad.a...@gmail.com on 4 Jun 2008 at 6:30

[GoogleCodeExporter]

Here is a patch for this.

Added an i18n module with a get_translator method

This allow to render a form in a specific language: fs.render(lang='fr')

Then you can use the F_ method in your template to get a translated message 
from the
formalchemy domain.

If pylons is available then the get_translator method use 
pylons.i18n.get_lang() to
retrieve the correct language for the request

Also added french translation

Currently tested with pylons on my customer project.

The only problem is to translate renderer contents like the
FileFieldRenderer.remove_label attribute

Original comment by gael.pas...@gmail.com on 27 Aug 2008 at 4:21

Attachments:

• i18n.patch

[GoogleCodeExporter]

After applying the patch I get this doctest failure:

**********************************************************************
File "i18n.py", line 28, in __main__.get_translator
Failed example:
    translator = get_translator('fr')
Exception raised:
    Traceback (most recent call last):
      File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/
doctest.py", line 1228, in __run
        compileflags, 1) in test.globs
      File "<doctest __main__.get_translator[0]>", line 1, in <module>
        translator = get_translator('fr')
      File "i18n.py", line 36, in get_translator
        langs = get_lang() or []
      File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-
packages/Pylons-0.9.7rc1-py2.5.egg/pylons/i18n/translation.py", line 181, in 
get_lang
        return getattr(pylons.translator, 'pylons_lang', None)
      File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-
packages/Paste-1.7.1-py2.5.egg/paste/registry.py", line 137, in __getattr__
        return getattr(self._current_obj(), attr)
      File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-
packages/Paste-1.7.1-py2.5.egg/paste/registry.py", line 194, in _current_obj
        'thread' % self.____name__)
    TypeError: No object (name: Translator) has been registered for this thread
**********************************************************************
File "i18n.py", line 29, in __main__.get_translator
Failed example:
    if isinstance(translator, GNUTranslations):
        # check only if a .mo is found
        assert translator.gettext('Remove') == 'Supprimer'
Exception raised:
    Traceback (most recent call last):
      File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/
doctest.py", line 1228, in __run
        compileflags, 1) in test.globs
      File "<doctest __main__.get_translator[1]>", line 1, in <module>
        if isinstance(translator, GNUTranslations):
    NameError: name 'translator' is not defined
**********************************************************************

Original comment by jbel...@gmail.com on 30 Aug 2008 at 12:05

[GoogleCodeExporter]

This occur when you have pylons in your sys path but you are not in a valid 
thread when calling render(). 
Problem is now fixed and commited at r410.

Original comment by gael.pas...@gmail.com on 1 Sep 2008 at 3:24

[GoogleCodeExporter]

Original comment by jbel...@gmail.com on 22 Sep 2008 at 10:46

[GoogleCodeExporter]

Hi all,

I'm trying to get FormAlchemy working in a Pylons project, but I've almost
immediately hit a problem which appears to be to do with the i18n module. This 
is
occurring on Windows XP/Python 2.5.4/Pylons 0.9.7rc4 with FormAlchemy 1.1.1.

I can create a FieldSet and access the value directly (e.g.
"fs.BriefDescription.value", where BriefDescription is a mapped column, works 
fine)
but when I try to call fs.render() I get the following:

------------------

File 'D:\\Programs\\Apache Software
Foundation\\Apache2.2\\htdocs\\ben\\oracle\\oracle\\controllers\\testview.py', 
line
29 in index2
  html = html + fs.render()
File
'D:\\Programs\\Python254\\lib\\site-packages\\formalchemy-1.1.1-py2.5.egg\\forma
lchemy\\forms.py',
line 302 in render
  kwargs['F_'] = get_translator(kwargs.get('lang', None)).gettext # tempita pukes if
we pass this as `_`
File
'd:\\programs\\python254\\lib\\site-packages\\formalchemy-1.1.1-py2.5.egg\\forma
lchemy\\i18n.py',
line 55 in get_translator
  return GNUTranslations(open(os.path.join(i18n_path, lang,
'LC_MESSAGES','formalchemy.mo')))
File 'D:\\Programs\\Python254\\lib\\gettext.py', line 180 in __init__
  self._parse(fp)
File 'D:\\Programs\\Python254\\lib\\gettext.py', line 287 in _parse
  tlen, toff = unpack(ii, buf[transidx:transidx+8])
File 'D:\\Programs\\Python254\\lib\\struct.py', line 87 in unpack
  return o.unpack(s)
error: unpack requires a string argument of length 8

------------------

I think I can see the problem in the interactive debugger; the value of buf in 
_parse
is only 44 characters long:
'\xde\x12\x04\x95\x00\x00\x00\x003\x00\x00\x00\x1c\x00\x00\x00\xb4\x01\x00\x00\x
00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00L\x03\x00\x00\x06\x00\x00\x00M\x03
\x00\x00'
But transidx is 436, so the slice operation is returning an empty string. On the
other hand I really have no idea what this code is doing or how to fix it... 
does
anyone have a suggestion?

Cheers,

-- 
Ben

Original comment by transhum...@gmail.com on 31 Jan 2009 at 5:18

[GoogleCodeExporter]

Aha, found the problem. The following line (#55) in i18n.py is currently not
Windows-friendly;

            return GNUTranslations(open(os.path.join(i18n_path, lang,
'LC_MESSAGES','formalchemy.mo')))

The default mode for open() is 'r', but on Windows this mangles binary data; by
specifying 'rb' the problem is resolved:

            return GNUTranslations(open(os.path.join(i18n_path, lang,
'LC_MESSAGES','formalchemy.mo'), 'rb'))

The Python docs (http://docs.python.org/tutorial/inputoutput.html) imply that 
this
fix shouldn't cause a problem on *nix systems, but I'll leave testing that to 
someone
who has one. :)

Cheers,

-- 
Ben

Original comment by transhum...@gmail.com on 1 Feb 2009 at 12:09

[GoogleCodeExporter]

thanks, fix applied.

sometimes it's problematic that none of the devs runs windows as a primary 
platform. :)

Original comment by jbel...@gmail.com on 1 Feb 2009 at 12:55

[GoogleCodeExporter]

I'm using Pylons+Mako. I got UnicodeDecode error with CJK translation.  The .po 
was written in UTF-8 then compiled to .mo following FA's i18n manual.

The problem is get_translator().gettext returns encoded string (UTF-8) while 
Mako wants Unicode object. Note: A mako template's coding header (-*- coding: 
utf-8 -*-) won't take effect when it receives values outside as explained at 
http://www.makotemplates.org/docs/unicode.html.

This patch forces to use .ugettext.  This may break for other template engines 
that can't handle Unicode.

diff -r 952d3bda3374 formalchemy/i18n.py
--- a/formalchemy/i18n.py       Sat Apr 10 21:16:46 2010 +0200
+++ b/formalchemy/i18n.py       Thu Aug 05 12:20:56 2010 +0900
@@ -53,7 +53,9 @@ def get_translator(lang=None):
         filename = os.path.join(i18n_path, lang, 'LC_MESSAGES','formalchemy.mo')
         if os.path.isfile(filename):
             translations_path = os.path.join(i18n_path, lang, 'LC_MESSAGES','formalchemy.mo')
-            return GNUTranslations(open(translations_path, 'rb'))
+            gt = GNUTranslations(open(translations_path, 'rb'))
+            gt.gettext = gt.ugettext
+            return gt

     # dummy translator
     return _Translator()

Original comment by tokyo...@gmail.com on 5 Aug 2010 at 3:30

[GoogleCodeExporter]

Just a note.  The patch above is apparently a giant hack albeit least 
modifying.  It might be better to create a subclass of GNUTranslations and made 
Unicode/str switchable.

Original comment by tokyo...@gmail.com on 5 Aug 2010 at 3:42

[GoogleCodeExporter]

And here's the Japanese PO to reproduce the error.

Original comment by tokyo...@gmail.com on 5 Aug 2010 at 6:55

Attachments:

• formalchemy.po