Hi Guys,
Eloquence synthesizer has gone to a cell phone company; talked with or sit
in the sauna with one of the company exec's every so often...
Now, David you mentioned what chip is doing, does not Google do a
translation to a given language already?
As you state and Chip has discovered, each person is going to use there
language up front and if English comes in, does not Google switch it upon
request?
Just thought i would add my $0.02 and I think that is what you are saying
below anyway.
Chip look at the code of the header section of a web site and it will
possibly tell you the language, but since you are in an app that wojuld not be
available except for your html help file.
So, let the user change the language at there end since the Eloquence
synthesizer is a cell phone app now.
Bruce
Sent: Sunday, July 20, 2014 2:30 AM
Subject: Linking Synthesizer and Language - A follow-up on the Remind MeWhere
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.
DavidOn 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
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
