Thanks very much David for all of the ideas! I will have to re-read this and give it some thought.
I think I'll have to let the user use the voice rotor app for handling the mix I currently have of English dialogs with non-English text sometimes displayed. If I understood you, it is possible to use voice rotor to change to another synthesizer with another language on the fly? Since I have some controls with English, and some with non-English on the same dialog, the only solution if WE cannot determine this from the Unicode of the text would be to allow the programmer to specify the language as a property of each control, not just the dialog. Since we have so many non-English users forced to use English at times, this may not be an unreasonable request for WE to improve this in some way. Next (and really quite separate from the WE issues), yes, I see the need for a temporary language change for the html page generated by Google in my app, so I think I can do that. Thanks again, Chip From: David [mailto:trailerda...@hotmail.com] Sent: Sunday, July 20, 2014 2:30 AM To: gw-a...@gwmicro.com; gw-scripting@gwmicro.com Subject: Linking Synthesizer and Language - A follow-up on the Remind Me Where thread Chip, and the rest. Nope, as you Chip rightly discovered, there is no really easy way to have Window-Eyes change synth upon language changes. I actually spend several hours in developing things, when building the Extended Dictionary app, so that it will automatically switch dialog language, along with the current synthesizer. OK, slightly different task from what you Chip are attempting, but close enough that it still compares. GW has provided one feature for auto-switching voice, on language changes. You will find it as a feature under Browse Mode. But don't get too eager on it. First of all, it depends on the browse mode. Next, it depends on a code in the HTML of the website displayed, which tells the language. This is not a part of the address line or call to the web, but a part of the HTML body itself. And thirdly, the feature only - and solely - works with Eloquence synthesizer. Since Eloquence is no longer being developed, and the amount of supported languages is rather limited (English, Finish, French, German, Italian and Spanish, I think that's all) - you are not going to help all that many international users, should you want to rely on this feature. You ask if it could have relied on the characters in the text displayed. A pretty good idea, except from three small facts. (1) You will have to know exactly which characters are special for that particular language, and hence have a way for your code to know what synth to be used at any given time. (2) You then depend on at least ONE of the special national characters to show up in the text displayed. This could likely be, should I want a local route. But what if I am planning a trip to the USA, and ask your app to manufacture an instruction list. You may - or may not - end up with a text that holds any of the special characters your app depends on, for synth switching. (3) Even if there is a number of special national characters, and just about any non-English language uses some of them, not all would be reliable for a total detection of the language. Norwegian and Danish, for one case, are two different languages with each their synthesizers for the computer. Yet, they both share three national characters, and only those three. OK, you could go by the number of the Unicode Table itself, but even here, several languages may be using one and same table. As you can see, you soon enough would run into a few pitfalls. Google's Translation service does have a "detection" feature, which in many cases is reliable enough. But then again, it will look out for more than just the unicoded national characters, and rather rely on certain words or word-fractions that are special for that language. For instance, the Scandinavian languages are filled with words, that hold the character combination of an S, followed by a K, followed by an R - SKR. This character combination, I don't think you will see much in English. :) On the other hand, English holds the comparable version, an S, followed by the C and R characters - SCR. Like you can see, basing your code on things like words and word-fractions, could take you one step further, but would still not be reliable enough. A more reliable way to link your results with a particular synth, depending on the language used, would be to know what synths support each possible language. Look at Eloquence, and work yourself up on happiness. Job is pretty easy done, since each voice of Eloquence holds a word, indicating what language it supports. The German ones, will be named something with German; just like the US-English voice Reed, is Named "U.S. English, Reed". - Now, how long do you think I am going to leave you in that world of happiness? Smile. - Fact is, that there is no simple way to determine what language a synth supports, due to the lack of a standard naming convention. Some manufacturers let their synth introduce itself to the OS, with its full language information - like Eloquence. Others, only use the two-character code - like UK, US and so forth. And, still others may not necessarily introduce any reliable information. You could make a list of languages and synths that support them, but then you would have to gather quite a lot of information. Besides, what if the user is using a synth that is not in that list? Also, locally here, we have at least three different synths - one pretty OK, and the two others we would have done well without - even for one and same language. Each of the synths, has one or more voices. Exactly which voice is your app going to activate, when the given language is showing up? So what then can you possibly do? Are you totally out of luck, and will you be better off in simply dropping this part of internationalization? Heads up! - I did have to make some decissions when creating my app. and I made a workaround that works for the need I had in that project. True, it took some hundreds of lines of coding, hours and days of figuring and planning, and I am not sure if it can be directly transfered into your app. However, let me here give you a couple of possible workarounds, and you see what you want to go for. Then, if you feel I can be of any further help in detailing a certain approach, don't hesitate to contact me off-list. Sorry, but I cannot just derive a chunk of lines from my code, since it is all linked in with numerous other parts of the project, and like I stated, it may not apply directly with your project. But I am willing to discuss details of given approaches, with those who want more meat on the bones. :) The first workaround - which is the easiest - would be to simply just display the information in the language the user chooses, and then let him choose his synth himself. You already have done a good job here, in that you have provided the facility of linking the result text, with the locale version of the screen reader currently used. For most users, this likely will do perfectly. If I am on a French version of Window-Eyes, chances are high that I want to see the list in French, and even higher chances go that I am currently also using a French synthesizer and voice. So, for maybe ninety percent of the end-user market, you have just about done the job already, Chip. Of course, there could be the chance that I am running a German version of the screen reader, with a corresponding synth voice - but for some reason would need the list in English. Well, for those of us who are used to the strictness of the screen reader, often locking us up with limited automation in voice switching, we are used to have our locale voice do its best, in reading foreign languages. Smile. So, the hazzle may not be too big, should we see a list in another language than our currently active voice. Another thing is, that users now aday have the VoiceRotor app baked in with their updated version of Window-Eyes. So, multi-lingual users, can switch voices and thereby also languages, with only one or a few manual keystrokes. Again, if I am a German user with currently a German voice activated, and I decide to have your list printed in English, it would be only a few keystrokes for me to change to the English voice, read your list, and a few more keystrokes to return to German for further computer activity. To sum this approach up, you are just about there already, with your code Chip. Thanks for taking this extra step out of your way, and attempting to make it more relevant for non-English users. An attempt I wish more developers would do. OK, you want things to happen automatically. All honor for that. I agree, if you can have a workaround that will let the user do his job without extra keystrokes and switching, nothing is better. But how could an automation take place? One approach, which basically is the one I took in my project, is to let the user choose for himself, what synth should be used for a given language. If the user choose to switch language, you would ask him what synth he wants to use for that language. Then your app would not have to bother what synth supports what language, and how to recognize this paring. You could leave that job to the end-user, who will be the best judge in his given situation and environment. When he has made his choice, you then could store that in the ini file, for later usage. For the kind of project you are developing, where the language and synth paring would mainly be pretty static, i am ready to think this is the better approach in your attempt. Far more reliable, and less coding, than you would need to try to figure what synth to use for any language in your app. Well, I want to go back on one point here, and discuss it just a tiny bit more. I stated that you are almost there, in the first approach mentioned above. Yes, your newest version is doing well, in that I can set up a connection between the locale version of my screen reader, and the language used in your resulting list. And this could later on be used for localizing the dialogs as well. The XML feature of the scripting environment in WE, does make that a matter of a breeze. But there is a couple more wantings to be considered here. Firstly, your app currently makes this a static setting, which will apply all up till I change it. Great in the daily usage. But if I happen to use my locale version, and for one simple list of directions need the English version, it is a bit overkill to have to go into the Options menu, and change the main settings. So, in the end dialog, you may want to add on a feature for a one-time change of language. That is, next to the "Get Directions"-button, you could have a "Choose language"-button. Or, you could have added on a menu in that dialog, for choosing the language. If now I made a selection of language, it would only apply for that one retrieval of directions, or maybe only till I close the current dialog, and hence end my session. Then, it would revert back to the setting given in the Options menu. Secondly, if you are not tied to pre-defining synths for each language, you may want to leave me as the end-user the chance of choosing any of the supported languages. Agreed, I here will bring out a rather rare scenario, but it is not all that unrealistic anyway. Imagine, that you are living in Mexico. Your job is an international one, and hence you are performing most of your work in English. Due to the restrictions GW puts on their international users when comes to running WE in different languages (of which I don't want to start a discussion), you then may end up with a Spanish version of your screen reader, but operating the computer with an English voice like Eloquence Reed. Fine. The way your newest version of the app does its job, I can choose to either see the list in English - or, I can link it with my locale (Spanish) version of the screen reader. Now, one day, in the international work, the user needs to give directions for his business contact - coming from Germany. It would have been great, could he have printed or mailed a set of instructions in German, even if neither he nor the computer, speaks German. So as you can see, there could be times, when I need the list printed or displayed, in languages that are not English, neither the locale one for the version of WE installed on my computer. Again, if you had a choice - say in a menu of the "get directions"-dialog - where the user could choose between any of the languages supported by Google. It did not matter, if the language ever is supported in your dialogs, all he needs, is the list given in that language for this one time. maybe you feel this is not what you want for your app, but I through it out on the table, as a tiny wish for improvements. Internationalizing your project is not anything that can be done fully automated, or with only a few lines of coding. Even the more so, thanks to all developers who take the extra time to do so. There is many an user out there, who will only be able to operate and benefit from your projects, when they find the project smoothly internationalized. David On 7/19/2014 11:35 PM, Chip Orange wrote: Ok . I found by experimenting by forcing German for myself (I have a very little German), that the synthesizer does not automatically change languages within a dialog; so when I loaded the listview with German instructions, the synthesizer did not detect there was German being displayed (I would have thought this could have been done with the Unicode characters; GW, is this possible in the future?) However, I did update the version you can download now to 0.7.2, because this version does create an HTML browse dialog (when you click the optional button for this) which contains a language parameter, and WE does then change the synthesizer language to match the page being shown in the browser. So, for non-English users of this app, version 0.7.2 is a small step forward. Enjoy, Chip From: Chip Orange [mailto:lists3...@comcast.net] Sent: Saturday, July 19, 2014 4:03 PM To: gw-scripting@gwmicro.com; gw-a...@gwmicro.com Subject: another beta of Remind Me Where Hi all, Besides the usual set of bug fixes, this beta should finish all of the remaining metric unit issues, so when you choose metric, everything should be in metric. Also, I'm beginning to experiment with non-English responses from Google. In the options dialog there is a language choice which allows you to specify if the Google responses should be in the same language as the app dialog (currently only English), or in the same language as your copy of Window-Eyes. So, if you are using a non-English copy of WE, you can choose the latter choice to see how this works out when Google gives directions in that language. My concern is whether a synthesizer will automatically switch from English to your native language; if not, then this may have to wait until I begin having dialogs translated into other languages. I would appreciate hearing from anyone with a non-English version of WE who tries this arrangement. The download link for this beta (0.7.0) is the same as always: https://dl.dropboxusercontent.com/u/11745142/Remind_Me_Where.wepm Thanks for the help and the suggestions, Chip
