Library-type gettext/libintl usage

Gettext is currently used by libvlc (and plugins) as if libvlc was a program. That works fine with the VLC binary itself... but that's flawed when used as a library, such as in browser's plugin or bound to a scripting language.

added Component::Core Severity::normal Type::bug Version::master git + 1 deleted label

changed milestone to %0.8.5-test3

changed title from Library-type use gettext/libintl to Library-type gettext/libintl usage

LibVLC already knows of dgettext and use it properly... But:

• it calls textdomain() while it should not,
• it calls setlocale() which only program should call,
• it sets LC_NUMERIC to C and assumes it is C afterward, which is broken.

The setlocale() is a bit tricky to solve because we sometime override it according to VLC configuration (if the user asked for a different locale).

As for LC_NUMERIC, it is mainly known to break live555, which is an underlying library.

(In [14647]) Don't call textdomain - it is not only useless but harmful (refs #581 (closed))

changed milestone to %0.8.6

(In [15226]) Do not alter LC_NUMERIC (refs #581 (closed)). *** NOT MEANT FOR BACKPORTING ***

Only the setlocale() issue is left. libvlc should probably not call SetLanguage() except when run from VLC.

(In [15227]) Same as previous commit (refs #581 (closed))

The only remaining issue is the usage of setlocale() when called as an embedded plugin. Maybe we should still do that, so that we don't fallback to ASCII/C/POSIX if the using program does not call setlocale itself (I doubt ActiveX users do that...).

Also, in most case, this won't conflict. On POSIX systems, there is no problem at all, as a side effect of manual language setting being broken.

added Status::fixed label

closed

mentioned in issue #582 (closed)

mentioned in issue #583 (closed)

mentioned in issue #584 (closed)

mentioned in issue #585 (closed)

mentioned in issue #586 (closed)

mentioned in issue #587 (closed)

mentioned in issue #588 (closed)

mentioned in issue #589 (closed)