Title: Traceback internationalization
Version: $Revision$
Last-Modified: $Date$
Author: Mariano Reingart <reingart EN gmail PUNTO com>
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 15-May-2010


    The idea is to provide a standard mechanism to translate exception
    and traceback messages to languages other than English.
    To not reinvent the wheel, this proposal is based on i18n (gettext),
    to ease translation and colaboration between language communities,
    use compatible tools that already exists, favor correctness with
    online review, and has proven to be useful in other projects with
    similar goals (like error messages in PostgreSQL).
    Also, a method to control LC_MESSAGES to get back to English must
    be provided, as some code depends on exception messages (i.e.
    doctests), preferably changeable at runtime, so this libraries are
    self-aware of this issues and no manual intervention is required.


    English isn't the first language of some users (developers), so
    they may not be confortable with messages in that language [1]
    (and some don't understand it at all). Ask them to learn a
    second language (mostly foreign) to use Python is, at least,
    not practical.

    This is specially an issue when Python is used as a First
    Programming Language for teaching to non-English speakers in
    almost any educational level, even worse in other areas not
    related directly with computer sciences.

    Although a workaround may be developed (ie. a wiki page with
    translated errors, as we did in Argentina [2]), that users are
    often blocked when they found an English message, losing they
    concentration on their work, having to waste time finding the
    translation (if it exists) or asking to the teacher or mailing

    In the other side, advanced users often prefer original messages
    in English, and they are required in some scenarios like bug
    reporting or doctests, so a method must be provided to change the
    messages language (preferably at runtime).

    Using standards tools for i18n (gettext) will ease translation
    providing a common framework that already is prepared for
    different language rules, with colaborative online applications
    like Pootle[3] to automate translation and review process, tending
    to a high quality result.

    Other projects have chose this way some time ago, citing PostgreSQL
    as an example[4], where, at runtime, you can choose error messages
    language using LC_MESSAGES[5]. Indeed, we are using Pootle and
    other tools to translate PostgreSQL related projects to Spanish in
    a collaborative way [6].

    Finally, this proposal will address current misbehavior with
    locale.LC_MESSAGES category (according the Python Standard Library
    Documentation of locale module) [7]:

        Locale category for message display. Python currently does not
        support application specific locale-aware messages. Messages
        displayed by the operating system, like those returned by
        os.strerror() might be affected by this category.


    Setting the desired locale (ie. 'es_AR') in LC_MESSAGES category
    will enable internationalization of tracebacks and exceptions, and
    setting 'C' locale will get back to untranslated original messages:


    Python 3.4.0a0 (default:8f0d5ecca524+, Oct 28 2012, 00:46:34)
    [GCC 4.6.3] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> 1/0
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ZeroDivisionError: division by zero

    >>> import locale
    >>> locale.setlocale(locale.LC_MESSAGES,'es_AR.utf8')
    >>> 1/0
    Traza de rastreo (llamada más reciente última):
      Archivo "<stdin>", línea 1, en <module>
    ZeroDivisionError: división por cero

    >>> locale.setlocale(locale.LC_MESSAGES,'C')
    >>> 1/0
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ZeroDivisionError: division by zero

    By default, LC_MESSAGES should be 'C' locale, to prevent any

    The user that needs translated messages could easily add a
    line or setting LC_MESSAGES in his desired language:

    import locale; locale.setlocale(locale.LC_MESSAGES,'es_AR.utf8')


    Internationalization uses UTF-8 to be able to handle special
    characters like accents. This should not be a problem in Python 3
    but some functions may be revised like PyUnicode_FromFormatV() [9]

    Special care must be taken with positional placeholders like in:
    "name '%.200s' is not defined". If there is more than one
    placeholder, using printf special format specifiers (ie. %2$s %1$s)
    or an alternate string formatting system should be required
    in order to allow to change their position in the string (this may
    be required by some languages rules in some contexts).

Reference Implementation

    A proof of concept is attached to issue #16344 [10] for Python 3.3+
    Original -obsolete- version (for python 2.x) can be downloaded from
    Python Argentina Wiki [8]

    It defines a Py_GETTEXT macro that is called from PyErr_SetString
    and PyErr_Format (errors.c) and tb_displayline, PyTraceBack_Print

    A new subdirectory called Locale stores localized message files,
    but this could be installed in a standard system directory (i.e.
    /usr/share/locale) as a special domain called "python" is used to
    not interfere with python modules / libraries / packages already
    using gettext.

    Some steps are required to set up internationalization correctly:

    1. locale.bind_textdomain_codeset("python", "utf8") should be
       called in pythonrun.c to initialize encoding (preventing nested
       unicode exceptions if internationalization is not correctly)
    2. locale.bindtextdomain("python", sysconfig._safe_realpath("Locale"))
       should be called in to specify the locale directory
       (not needed if a standard directory is used, this would be
       platform dependent)
    3. locale.setlocale(locale.LC_MESSAGES,'es_AR.utf8') should be
       executed by the end user to finally enable internationalization

    Although it is just a proof of concept, final version shouldn't be
    much different than this, as internationalization points are
    well-known so just 2 C files were modified.

    In order to keep the change small, and in order to not bother other
    developers with new special issues, this approach needs a custom tool
    for messages recollection from source files, similar to,
    but scanning C files for PyErr_Format or PyErr_SetString messages.
    Looking for messages in .py files would be a little more difficult,
    as it would have to look where exceptions are raised.
    None of both tools were developed for this draft.













    This document has been placed in the public domain.

Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8

Attachment moin wiki code: