Age | Commit message (Collapse) | Author | Files | Lines |
|
As discussed in 'CH_DISPLAY and gettext' on the samba-technical list:
http://lists.samba.org/archive/samba-technical/2011-June/078190.html
Setting this to a value other than 'unix charset' does not make sense,
as any system where the filesytem charset does not equal the terminal
charset will already have problems with programs as simple as 'ls'.
It also means that our output could not be pasted as our input in
interactive programs or onto our command line, as we never did
translate in the DISPLAY -> UNIX direction.
The d_printf() calls are retained in case we need to revisit this, and
to support display_set_stderr().
Andrew Bartlett
|
|
I'm changed this during the change to use the d_printf() code in
common, but should not have.
However, there is a puzzle: What is the right source charset?
Translated strings in our .mo and .msg files are in UTF8, but strings
such as file names on remote servers are in UNIX (whatever that is).
I can't see how this actually works properly when either CH_DISPLAY or
CH_UNIX are other than UTF8!
Andrew Bartlett
Signed-off-by: Andrew Tridgell <tridge@samba.org>
|
|
The setting of the display charset is now done by
convert_string_talloc() selecting the right charset based on
CH_DISPLAY.
Andrew Bartlett
Signed-off-by: Andrew Tridgell <tridge@samba.org>
|
|
This removes the lang_tdb based varient, the only user of the lang_tdb
code is SWAT, which calls that directly.
'net' and 'pam_winbind' are internationalised using gettext.
Andrew Bartlett
|
|
|
|
Should fix bug #6660.
|
|
|
|
Conflicts:
source4/Makefile
|