mikewest / static_gettext

`gettext` wrapper, enabling localization of static documents and websites.
http://staticgettext.mikewest.org/
BSD 3-Clause "New" or "Revised" License
13 stars 6 forks source link

"Make messages" fails when text to be translated contains non-ascii characters #6

Open jasaldivara opened 10 years ago

jasaldivara commented 10 years ago

I have some text that contains non-ascii characters, like: {% blocktrans %}Personalízalo{% endblocktrans %} (note the accented, non-ascii "i")

When I run make messages, it fails with some message like:

Traceback (most recent call last):
  File "../static_gettext.py", line 285, in <module>
    sys.exit(main())
  File "../static_gettext.py", line 282, in main
    src = l10n.gettext( locale )
  File "../static_gettext.py", line 184, in gettext
    self.xgettext_postprocessing( locale )
  File "../static_gettext.py", line 139, in xgettext_postprocessing
    raise LocalizerGettextException( u"`msguniq` errors: %s" % errors )
__main__.LocalizerGettextException: `msguniq` errors: msguniq: input file './locale/en_US/LC_MESSAGES/messages.pot' doesn't contain a header entry with a charset specification

make: *** [messages] Error 1
jasaldivara commented 10 years ago

I think this issue is caused because somehow xgettext is not generating the POT file header.

I temporarily fiexd/hacked this, changing this:

        if os.path.exists( potfile ):
            msgs = '\n'.join( dropwhile( len, msgs.split( '\n' ) ) )
        else:
            msgs = msgs.replace( u'charset=CHARSET', u'charset=UTF-8' )

to this:

        if os.path.exists( potfile ):
            msgs = '\n'.join( dropwhile( len, msgs.split( '\n' ) ) )
        else:
            msgs = msgs + "\nmsgid ""\"\"\n";
            msgs = msgs + "\nmsgstr\"\"\n";
            msgs = msgs + "\n\"Content-Type: text/plain; charset=UTF-8\"\n";

And it worked for me. Is not the most elegant fix or anything, and the real solution would be making xgettext generating the header for the POT file.

Is this a bug on gettext?

I'm on Fedora 20, x86_64. Linux 3.16.3-200.fc20.x86_64

m3nu commented 7 years ago

Seems to happen, when you use special chargs (like German) as base language in the source code. The above mentioned lines fixed it. Generally source code will be in English so the problem doesn't come up too often.