Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=77376 --- shadow/77376 2006-02-28 15:02:40.000000000 -0500 +++ shadow/77376.tmp.19427 2006-10-27 23:22:14.000000000 -0400 @@ -1,12 +1,12 @@ Bug#: 77376 Product: Mono: Class Libraries Version: 1.1 OS: unknown OS Details: Mandriva Cooker i586 -Status: NEW +Status: NEEDINFO Resolution: Severity: Unknown Priority: Wishlist Component: Mono.POSIX AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] @@ -78,6 +78,62 @@ When I pass the string "/usr/share/locale" as second parameter then it works, but this is only a temporary workaround, because this directory is different on some systems. Hope this helps ... Stefan + +------- Additional Comments From [EMAIL PROTECTED] 2006-10-27 23:22 ------- +The reason it broke in 1.1.13.2 (and 1.1.14+) is that +Mono.Unix.Catalog.Init() moved from using +System.Runtime.InteropServices.Marshal.StringToHGlobalAuto() to +Mono.UnixMarshal.StringToHeap(). + +Marshal.StringToHGlobalAuto() returns IntPtr.Zero when given a null +string, while UnixMarshal.StringToHeap() generates a +NullReferenceException (really should throw an ArgumentNullException, +but the result would still be the same -- changed behavior). + +The reason for the change is .NET compatibility, so that +Mono.Unix.Catalog could be used on Win32. libintl.dll (intl.dll?) +needs UTF-8 encoded text, but Marshal.StringToHGlobalAuto() will use +the user's default encoding, which will *never* be UTF-8. + +History out of the way, we get to semantics. Even if a null localedir +were supported, I'm not sure that this would be beneficial. From +testing with a C program, if localedir is NULL, it returns the default +locale directory, e.g. /usr/share/locale. Which doesn't make sense, +as (for translation purposes) gettext(3) will look for translations in +e.g. /usr/share/locale/en_US/LC_MESSAGES/package-name.mo. + +So you're either using a translation for another program (e.g. using a +package name of "zmd"), or you're not getting translations AT ALL. + +For example, when using autotools, the default install prefix is +/usr/local. So translations will be installed to +/usr/local/share/locale. Which isn't the directory used by +bindtextdomain() when a NULL packagedir is passed. So your +translations won't be used. + +Your translations would only be used if you installed with a prefix of +/usr. This is not generally desirable behavior. + +The correct solution is the one that would generate no exceptions in +1.1.13.2+ -- provide a correct locale directory to the Catalog.Init() +call. You can determine this directory by making it a directory +relative to your installation directory. + +See also: http://www.mono-project.com/Guidelines:Application_Deployment + +If you follow the Relocation section, you can programatically +determine the locale directory with: + + string base_directory = System.AppDomain.CurrentDomain.BaseDirectory; + string locale_dir = UnixPath.Combine (base_directory, + "..", "..", "share", "locale"); + Catalog.Init ("app-name", locale_dir); + +(assuming that your app.exe is installed to $prefix/lib/app and +translations are in $prefix/share/locale.) + +Is this a viable solution for you? Or do you really need +Catalog.Init() to support null locale directories? _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
