Dear Maintainer,

Songwrite will not run. It fails with the error message below:

  Traceback (most recent call last):
    File "/usr/bin/songwrite", line 134, in <module>
      import main
    File "/usr/bin/../share/songwrite/main.py", line 21, in
    <module>
      import globdef, song, player, ui
    File "/usr/bin/../share/songwrite/globdef.py", line 38, in
    <module>
      translator = gettext.translation("songwrite", LOCALEDIR,
      ("en",))
    File "/usr/lib/python2.7/gettext.py", line 469, in translation
      raise IOError(ENOENT, 'No translation file found for
      domain', domain)
  IOError: [Errno 2] No translation file found for domain:
  'songwrite'


Regards,

Morten Bo Johansen

Hi Morten,

thanks for your bug report. Unfortunately, I couldn't reproduce your
problem. So we may need further information. Let's start with this:

Does the file "/usr/share/locale/en/LC_MESSAGES/songwrite.mo" exist in
your system?

Cheers,
Martin

Martin Steghöfer <martin@steghoefer.eu> wrote:

Okay, that was pretty straightforward: The gettext message file
was not there because I use the localepurge program. I
installed it manually and now the program starts fine.

Correct me if I am wrong, but I believe that usually the
English messages are part of the program's source code (and
thus compiled directly into it) whereas only the message files
with translations into other languages are held in separate
gettext message catalogs. It never crossed my mind that this
could be the problem.

If you want to have it the way it is now, maybe you could a
check for the presence of the localepurge program in the debian
"preinst" script and issue a warning to the user that the
program will not run if the English message catalog is deleted?


Thanks,

Morten

Hi Morten!


El 30/08/14 a les 21:05, Morten Bo Johansen ha escrit:

It's true that it is the most common case that the string identifiers
for localization are at the same time the English translation and
therefore can be used as a fall-back without any external files.
However, I've seen other cases. Many programs, especially the ones
written in scripting languages like Python, rely on external resources
in order to work properly.

I personally don't think the "songwrite" package is to blame here, but
rather "localepurge" for being overly eager.

I'm not officially related to this package, so I don't take decisions
(just helping out), but I must say that considering how Debian announces
the "localepurge" package, I don't think there is much of a chance to
get a check like the one you proposed(or even a patch integrating the
English strings into the source code) into Debian:

"Please note, that this tool is a hack which is *not* integrated with
Debian's package management system [...]. This program interferes with
the Debian package management and does provoke strange, but usually
harmless, behaviour [...]."
(https://packages.debian.org/wheezy/localepurge)

IMHO the way to go would be to define exceptions in the "localepurge"
script. However, it seems like the developers are not interested in this
feature right now: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=202214

But maybe you could try to convince the "songwrite" upstream developer
to create a fall-back strategy in case the locale files are not available.

Cheers,
Martin

Martin Steghöfer <martin@steghoefer.eu> wrote:

Hi Martin,

I think I could file a wishlist bug that English locale files
are never deleted. That would IMO be the best solution because
it won't really go against the purpose of the program since the
space taken up by English locale files is so minimal and since
it requires no action on the part of the user.

Thanks,

Morten

Hi Morten!


El 31/08/14 a les 09:48, Morten Bo Johansen ha escrit:

That probably won't work for all packages (it's not necessarily English
which is the fall-back locale), but it sounds like a good trade-off
between complexity and robustness! :-)

Good luck with the request!

Cheers,
Martin