Just to clarify.
Yes, indeed you can use the VoiceRotor to change to any synth, in any
languages.Doing it here all the time, and was one of the main reasonss I
ever installed it, right when it was released several years ago. The
VoiceRotor simply just switches to a given synth and voice, regardless
of its language. For instance, right now, I have the first voice in the
rotor set to Eloquence Reed (the US-English voice). Secondly, and
thirdly, comes two locale voices, and then a few more English voices I
only use every so often.
This way, I quickly and effortlessly can switch between one voice and
the other, depending on the task I am performing at any given time. Am I
working in English - I will stick mainly with Eloquence Reed. Should I
happen to open a document in a locale language, I will press the
switching hotkey once or twice, to activate the locale voices. And when
done with my locale job, I quickly hit the hotkey for backward rotoring,
and there I am, back with Eloquence Reed and can continue my English
operation.
So definitely, you can switch between any voices, in any language, with
no more effort than the extra keysrokes. Of course, it takes a bit of
setup, since you have to put the individual voices into the rotor, but
it really is a nice tool once it is set up. Well, just wanted to clear
that one up, that there might be no misunderstandings. :) It is not as
automated as if your app could do the voice-changing directly, but it
should be fully workable for most users. Think one of the biggest
problems is to teach people what the VoiceRotor is and does - but that
would not be the job of your app. Smiles.
David
On 7/20/2014 7:11 PM, Chip Orange wrote:
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:[email protected]]
*Sent:* Sunday, July 20, 2014 2:30 AM
*To:* [email protected]; [email protected]
*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:[email protected]]
*Sent:* Saturday, July 19, 2014 4:03 PM
*To:* [email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>
*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
