Globalization, perhaps more often called "internationalization," which is then frequently abbreviated to "i18n," has always seemed to me to be a messy process, no matter how you tackle it. I like the GetText project's philosophy of separating translation from coding and allowing different forces to govern the timeliness of translation updates versus program updates. I think the WE xml-based model is really nice when the scripter also manages translations, or at least, collects them all for central distribution. By contrast, JAWS' jsm model makes it easier to distribute the responsibility of creating translations but complicates centralized management of them a bit. Arguably, one could handle distributed translation in WE by letting people create replacement xml files with their own distribution points. I haven't thought through this or many other possibilities very thoroughly yet though.
On Tue, May 24, 2011 at 06:12:45AM -0400, RicksPlace wrote: Hi Aaron, I agree and try not to ReInvent the wheel whenever possible. I'll take a look at that option as soon as I can get back to scripting. My LanguageConversion VB.net Program is working but, grin, I am getting more gray hairs trying to globalize it! I don't like the entire process and think it should be something where a end-user can perform translation when they first install a script and not something the Scriptor does before hand. That said, what a pain! I like the way you handle the Language Elements rather than having to handle a bunch of Resource Files as used in Visual Studio - it's cleaner and easier to maintain. I am almost leaning twoard a complete ReWrite in VBScript just to use the Language Elements rather than using the Visual Studio Resource Files or hand rolling my own Globalization Handler.The only thing keeping me from doing either is whether I want to create something where the end user can select a language without the original scriptor having to have had set up the script before hand. I am thinking on how that might work. There are many languages and it would be easier and cleaner to allow a end user to pick one rather than having a bunch of pre-defined languages built into a App. The same goes for my stand-alone LanguageConverter VB.net project. But, I don't like to ReInvent the wheel and you and Microsoft seem to have setteled in on the existing method of handling Globalization and Localization likely for pretty good reasons, so... Later and thanks: Rick USA ----- Original Message ----- From: [1]Aaron Smith To: [2][email protected] Sent: Monday, May 23, 2011 9:25 AM Subject: Re: User Help Dialogs On 5/22/2011 11:30 AM, RicksPlace wrote: Hi: I want to have help dialogs for each page, form, a user might encounter. I also think it cool to allow users to modify the Help File if they have any personal notes or insights. Rather than reinventing the wheel, this would be a time to take advantage of the Window-Eyes context sensitive help feature, which allows you to take notes and save them for any window (even a specific control). Aaron -- Aaron Smith Web Development * App Development * Product Support Specialist GW Micro, Inc. * 725 Airport North Office Park, Fort Wayne, IN 46825 260-489-3671 * gwmicro.com To insure that you receive proper support, please include all past correspondence (where applicable), and any relevant information pertinent to your situation when submitting a problem report to the GW Micro Technical Support Team. References 1. mailto:[email protected] 2. mailto:[email protected] -- Doug Lee, Senior Accessibility Programmer SSB BART Group - Accessibility-on-Demand mailto:[email protected] http://www.ssbbartgroup.com "While they were saying among themselves it cannot be done, it was done." --Helen Keller
