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]; [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
