SourceForge has been redesigned. Learn more.

#9 Support for internationalisation


As a support tool, I would like to see the "Panic
Button" to also support various languages - the user
is already irritated by the error he's trying to
report, obviously he now wants clear instructions in
a language he understands on what to do next, that
is: after he hits the "Panic Button".

A config file entry would be nice to specify the
language, plus some "lang-en.cfg" file containing the
current English prompts, I would then offer myself to
create an initial "lang-de.cfg" for a German
translation, I'm sure others will help with their
respective native language too.


  • Russell Phillips

    Logged In: YES

    I've been looking into i18n. I'll probably use the gettext
    [1] framework, and possibly using Rosetta [2] to facilitate
    co-ordinating translators.

    My thinking was that Panic Button would use the default
    locale defined in Windows (so if Windows is in German, Panic
    Button will be in German). However, I could probably add a
    config option to override that if necessary.

    When it's ready to be localised, I'll need volunteers to
    provide translations - I only know English.



  • Russell Phillips

    • labels: 717746 -->
    • milestone: 475371 -->
    • assigned_to: nobody --> avantman42
  • Erik Vĺrdal Itland

    Logged In: YES

    This is a suggestion. I'm just wondering: gettext looks like
    a lot of work to me.

    Panicbutton is a really small project where we just need to
    translate about 10 strings (and leave the admin strings and
    email in english.) Would it be better to just make a small
    fix like this:

    Now: label='Please enter a descriptive title summarizing the
    problem you are reporting'

    My suggestion: label=string_Please_enter_title

    The string_Ple... variable could be read from a file which
    just contains "translation variables."

    And then we could include a .py file to read those variables

    This means we could do the code needed in one hour, and just
    have one .py file for each language we want to translate to.

    The only problem I can think about is that it would force us
    to compile one executable for each language... But someone
    here is probably smart enough to come up with a solution to
    this. (Or smart enough to use gettext :)

  • From a2b Consulting

    Logged In: YES

    I too would think that gettext and rosetta (while still a
    nice coding exercise of course) shoot *far* beyond the
    simple need to just translate a few strings (although I'd
    include the admin page lables as well as the text sent in
    emails - personal preference of course...).

    Shouldn't a normal dictionary in Python do the trick? Kind
    of like a file with some

    label = {"labelname1": 'Labeltext1',
    "labelname2": 'Labeltext2' ...

    kind of stuff. Instead of printing "hard coded" strings
    you'd then just refer to label["labelname1"] instead. I'm
    not at all sure how this scales when you want to use
    various languages in an "exe-fied" Python program though -
    lack of knowledge regarding Python on my side, I guess ;-)

    So obviously I couldn't answer the question if this
    necessitates a specific "version" for each language.

    Actually, just reading in a simple CSV containing the
    label names and respective translated text into such a
    dictionary shouldn't be too much of a problem either. Or
    is it?

  • Russell Phillips

    Logged In: YES

    I'm still inclined to use gettext. Here are some reasons:

    - If it's to be internationalised, then I want it to be
    done properly - I don't intend to leave half of it in English
    - A quick scan of the code revealed about 30-odd strings to
    be translated. This will increase, especially when logging
    is improved (RFE 1522938)
    - gettext includes useful things like the ability to detect
    the user's locale and load the appropriate translations.
    - Why reinvent the wheel? The gettext maintainers have
    already found all the problems associated with i18n and
    dealt with them
    - Using gettext gives access to other tools, such as Rosetta
    - I believe using Rosetta would make organising translators
    much simpler. All the translators use Rosetta, and I just
    need to pick up a tarball from Rosetta when I'm ready to do
    a release
    - Using gettext doesn't obfuscate the code too much. By
    contrast, having lots of function calls or label
    ["labelname"] entries would make the code harder to read.
    This would be less of an issue with strings named things
    like "string_Please_enter_title", though
    - I'm not convinced that gettext has any major
    disadvantages for the translators
    - Since gettext is a common way of providing i18n services,
    and there is a Python gettext module, it seems reasonable to
    expect that any future contributors will be familiar with
    gettext. Thus, using gettext makes it easier for people to
    contribute patches in future


  • Russell Phillips

    Logged In: YES

    If you are interested in translating Panic Button, please
    see the following blog post, which has full instructions:


  • Russell Phillips

    • status: open --> closed
  • Russell Phillips

    Logged In: YES

    i18n support has now been added, and a beta is available
    featuring this support.


Log in to post a comment.