earleh@eleazar.dartmouth.edu (Earle R. Horton) (12/14/89)
In article <9276@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <1989Dec11.172400.25746@agate.berkeley.edu> >silverio@brahms.berkeley.edu.UUCP (C J Silverio) writes: ... >Another point, which should have been made earlier, is that MultiFinder >incompatibility is simply not acceptable for production software. I >took the original message as meaning that a program was in development >and had not yet been made MultiFinder compatible, and the check for >MultiFinder's presence was to be made solely to prevent inadvertant >system crashes among people using development versions. All this stuff >about international usage is beside the point, since no development >version with flaws this serious should be propagated beyond the local >site. International usage is NOT beside the point, and should NEVER be considered to be beside the point. The only reason you can get away with this attitude is that you live in the U.S. People in the U.S. will ALWAYS use a U.S. system because the only language which they can read is English, and the only dialect of English which they can understand is the American dialect. If you are distributing software to beta sites in the U.S., then you are fairly safe in assuming that the software will only be run under a U.S. system. This is, however, a cheat which only works because of the extremely parochial nature of U.S. culture. Besides, international usage is only one example of a rather fundamental aspect of the Macintosh user interface, which you seem to be missing here. Said user interface is not only capable of being customized, it is MEANT to be customized at all levels. ANY software, even software in the developmental stages, should be compatible with the fact that I have modified my "About MultiFinder..." menu item to say "Aboutway UltiFinderMay...," which is NOT one of the official international strings. ... >One could instead search the menu for an item corresponding to the name >of the application, gotten from a PBGetFCBInfo on the application >resource file descriptor. This would work regardless of >internationalization or user reconfiguration. You are not planning to give up on this idea of looking through the Apple menu, are you Tim? I suppose I could say that if you are running the SADE MultiFinder and SuitCase II, and you have "Shorten Apple Menu" checked under your SuitCase II preferences, then the application name might not be in the Apple menu. I won't, however. I will simply reiterate my earlier proposal that it is incorrect to look in the user interface in order to try to find out the system configuration. By the way, that is a rather round- about way of getting the application name, given that GetAppParms can be used to find this information directly. >>But this begs a further question: Did I miss something, or isn't there >>a RIGHT and OFFICIAL way (I presume through the use of SysEnvirons) to >>tell which International System an app is running under? > >There is, but I don't know of an easy one; much of the Script Manager >documentation is opaque to me, and I believe the fault is in the >quality of the documentation, not in my reading abilities. In any >case, the way seems to be to call GetSysFont and compare it numerically >to the fixed international ranges. There is nothing wrong with the Script Manager documentation. It is written as a programmer's guide. If you are not writing programs that use the Script Manager, then of course the documentation is less than clear. I will admit that the Script Manager documentation is somewhat "terse," but you are supposed to fill it out by typing in code as you read it. Similar to the rest of Inside Macintosh, in my opinion. GetSysFont can be used to find the default script, but that will be of absolutely no use if you want to distinguish between e.g. Deutsch and French systems. In any case, no system call will ever tell you which international version of MultiFinder is present. In my experience the various files which make up the System Tools distribution are more or less independent of each other, with some exceptions. Nothing prevents me from running a U.S. system with a Deutsch Finder and a Japanese MultiFinder, as long as the System version numbers are the same. Now why would any user want to do something like that? I contend that as an application developer that that is none of your darn business. > >>Wouldn't this be nice? Then one could ship a really international >>version of the program that automatically (if possible) come up in >>whatever language was appropriate. Too much disk space? Pish and >>poddle! I'll betcha people like it. > >I think this idea should be discussed by the group; it's a good one. Whoa! Before everyone jumps on the international bandwagon, and starts shipping applications which contain error message 'STR#' resources in 30 different languages, wouldn't it be better to first get down to basics and make sure that applications are at least code-compatible with international systems and the Script Manager? The contents of the "File" menu are far less important than whether an application can, ahem, display text properly. If you decide to ship a program with a multi-language user interface (an enlightened idea, in my opinion), then by all means do not attempt to second-guess the user as to which language is appropriate. Put the selection of language in a preferences dialog or file, and avoid writing a bunch of code which will not only be hard to write but which will probably come up with the wrong answer anyway. There is nothing in the runtime environment which you may use to deduce the appropriate language for the user interface. Earle R. Horton
amanda@mermaid.intercon.com (Amanda Walker) (12/14/89)
Yowza! There's some major miscommunication going on here, I think... In article <17893@dartvax.Dartmouth.EDU>, earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > In article <9276@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > >All this stuff > >about international usage is beside the point, since no development > >version with flaws this serious should be propagated beyond the local > >site. > > International usage is NOT beside the point, and should NEVER be > considered to be beside the point. They way I read Tim's posting was that the international considerations were beside the point *precisely* because you should never actually distribute software that would "need" the hack being discussed. For real software, international issues cannot be ignored, but neither can things like MultiFinder compatibility, memory usage, and so on. One of the threads that has been part of this discussion all along is that there is no acceptable way to test whether or not you are running under MultiFinder. Ignoring localizability certainly isn't any worse than ignoring MultiFinder compatibility and awareness... Sounded to me like Tim was saying something on the order of "If you're making mud pies, you might as well not worry about how much sugar to put in," rather than "sugar isn't important for baking pies" :-). Amanda Walker InterCon Systems Corporation --
brecher@well.UUCP (Steve Brecher) (12/18/89)
In article <17893@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > I suppose I could say that if you are running the > SADE MultiFinder and [Suitcase II], and you have "Shorten Apple Menu" > checked under your [Suitcase II] preferences, then the application name > might not be in the Apple menu. I won't, however. This response is really off-topic, since it is a point about Suitcase II which appears merely as an example in the original post. Suitcase II alters the Apple menu dynamically at the time it is pulled down. An application examining the contents of the menu will see it unaltered. (I am not recommending such examination.) -- brecher@well.UUCP (Steve Brecher)