[Mono-bugs] [Bug 77376][Wis] Changed - SportsTracker does not run with mono 1.1.13.2

[bugzilla-daemon at bugzilla.ximian.com]

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 jonpryor at vt.edu.

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: mono-bugs at ximian.com                            
 ReportedBy: goetz.waschk at gmail.com               
@@ -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 jonpryor at vt.edu  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?