The GW-Scripting list is a discussion list for information regarding the development and use of Window-Eyes scripts. Any subscriber of the GW-Scripting list has the ability to post on-topic messages.
From:
DavidSubject:
Re: WETranslator Design And LocalizationDate:
Thu, Jun 16, 2011 12:38:20 pmcharset="iso-8859-1"
Oh, Rick,
How you have misunderstood my whole point in here. I never - and again, NEVER - have meant to bring your project down. If you forgive me for being rough-edged for one moment, then I don't care how much or how little time, resources, money or whatever you throw into translating your app. Again, this might sound more rough-edged, than what I intended.
Let's for a moment have a quick glance at the history here. You have several times lately, told us about your great app, and its progress in development. As far as I get it, your app is meant to ease the translation process for the end user. That is, if I get it correct, that he (the end user) can send a number of words and phrases through your app - in one turn. Your app then will have Microsoft translator do the translation of ALL these words and phrases, and return the results to the user. Great idea, and I am fully convinced your app will handle this perfectly well.
Then, one of the others on this list, asked you a polite question, if you were sure this would really be of much help for the end user. I then popped in, not to discourage or down-grade your app, but simply to show some of the limitations of electronic translators. Again, no limitation of your app, no call for you to change anything whatsoever in your app, simply to let people get a feeling of what electronic services can do for you. It be Microsoft or Google translator. It be Yahoo, Babelfish, Webster or any other web-based service. Or, be it any of the many existing paid-for services of more local character - like software packages you install directly on your computer, and which intends to do electronic translation. I have tried some of them, and in general find them doing approximately 70 percent reliable translations.
So, Rick, again, again, and again: Nothing has to be changed or messed with in your app. If you so desire, release your app in English ONLY, and keep it there. I meant to let the end-users know, what kind of reality they will have, in using your app; not anything about the app itself. Your app doesn't change the reliability of the Microsoft translator, does it? So why would I ever criticize your app for not being reliable? The real bottleneck here, is not your app, rather the electronic translators in general. Nothing you can do anything about, let alone change.
Once again, to stress what I am trying to communicate, and hopefully will manage this time. If now, you Rick, decide to release your app tomorrow (or whenever). Then say that Mrs Sunrise, and Mr Rainfall decide to buy your app. They in turn, are developing their own apps. Mr Rainfall, for instance, is developing an app that makes the standard keyboard turn into a Braille keyboard. This Braille-keyboard app, does have some checkboxes and help menus in its XML file. Well, mr Rainfall reasons, that since he now has paid a sum for your translation app, he can simply run the XML file of his Braille-keyboard app through the translation app, and then - Woopsy - have it translated all into twenty complete languages. And, RICK, here is my point. That is not the case! Mr Rainfall, not you, will have to have human translators - or at least, proofreaders - look over his translated XML tags. Not because of you Rick. Nor because of your app. But, because of the reliability of Microsoft translator.
If anyone in here, please, could tell me if I could have let my point shine more clearly through; then thanks alot. But, Rick, again, sorry that you think I am down-grading your app in itself, or asking you to throw thousands of dollars in the project. I am not. I am not even going to bother, how much money you throw into the project. That is, solely, your business. And I do see your wanting money for the end product. That is fine, and your decision; I am not going to bother. But, I do hold it was on its place, to let the end-users know, what they could expect from such a product. I am not sure, if you ever have learned any other language but English. If not, you would have little background for knowing to which extend an Electronic Translation Service is fully reliable. That is why, I popped in, giving my experiences some air.
Honestly, Rick, if people pay you money, thinking that now your app is going to solve the whole task of translating everything into the whole universe of languages, and then later learn that the product only did 70 percent of what they expected... Don't you think it would be better business to let them know, from the beginning, what to expect? I guess, since you started out the project, and have put down all that much work in the project, that you already know that people want this product. That is called market research, and as the professional guy you seem to be, I am sure you must have done some of that. But, believe me, there is tons of people who think that computers can do almost anything. Don't we see that all the time, on the GW's mailing lists? Can I have an app for this? Is there an app for that? - People think that apps can solve anything. When you introduce them to an idea of an Auto-Translate app... Well, how many would start to think, that now they could quickly and easily have their products fully translated, in a numerous number of languages, in a matter of a breeze. Reality, though, is a bit different. That is my point. That was my point. And, that is going to stand as my point. NOTHING WRONG WITH YOUR APP, Rick; YOU HAVE TO CHANGE NOTHING IN YOUR APP. Release it as it stands. Leave it in English. Noone will blame you for that. But be honest and well-informed to your customers, and let them know what they realistically will get from your app's services. I only came in from the outside, being a multi-lingual person, facing the challenges of translating and operating on more than one language every single day. I only meant to be helpful to the community. My deepest apologize, excuse, beg your pardon Sir, hands up, and whatever. I never asked you to spend thousand of dollars or anything on translating your project. Only aimed my input at the end-users, to let them have a glance at realities of the everyday.
Are you able to have a good night's sleep now, Rick? I am really not ready for more follow-up on the matter. Just wanted to clarify my intensions. Hopefully this message finally managed to make it clear - to you, and everyone else - what I really wanted to commmunicate.
Again, sorry!
----- Original Message -----
From: RicksPlace
To: gw-scripting@gwmicro.com
Sent: Wednesday, June 15, 2011 1:41 PM
Subject: WETranslator Design And Localization
Hi David et al: I guess it is time to "Put Up or Shut Up".Well, last night I spent time researching the use of Resource Files.
Here are my findings:
Research files are actually text files containing xml elements for every item in an application.
In Visual Studio there are 2 methods of creating them.
The first is to just set the Form Property to Localizable.
This automatically will generate a xml Resource file for each form in the project.
Each xml file is then translated, by machine or by a living breathing person, into some Culture Language and they get compiled with the program before distribution.
The second method is to build the same Resource File contents for the entire project, compile them seperatly and include them as individual DLLs with the project.
We also have to hand build any UserMessages xml and text Help files to be included in the project.
The files are then included as DLLs during compilation and distributed as part of, or along with, the main assembly.
Now for a "Professional Analysis" of best technicals to use for this Audience...
Our app is designed for Scriptors.
That means they are experienced and comfortable with some programming language and xml files.
They also do allot of open source and free development of projects to help other Blind Folks make applications more accessible.
OK, so what do we know about designing our project?
We will try and keep time and development costs to a minimum.
We will use free or very low cost tools when possible without sacrificing quality wherever possible.
We can depend on our end-users having a basic understanding of how things are done on a computer, what a xml file is and how it might be used to store and retrieve data in an application like WindowEyes for example.
Now we are ready to look at some design requirements and related technicals:
I will skip everything except the translation and Localization process.
Wwe have a general design for our application and have decided to use VB.net as the implementation tool for several good reasons related to our original audience premise.
Actually it was a toss up between VB.net and VBScript but vB.net won out in the end for it's support of the .net framework objects.
Next:
We have to choose how to handle Localization.
We can just check a property in a form and have the resource files generated automatically.
Then contact perhaps 20 or so translators to have them translated into various Cultures and sent back to us.
When the translations are all done we can compile and start beta testing.
During beta testing, for any change, we will have to make modifications to our application. Then we need to gather the source code for all the language DLLs, send them back to all the translators who will have to promptly do the new translations and send them back to us ASAP since testing can not continue until we get all the translations back, ReCompile the application, ReDistribute the application to the testors who will need to ReInstall all or parts of the application including the new DLL Versions.
We will also have to do that for all folks who use our product if any new language support is added downline or users will have diferent versions of the DLLs which will likely end up causing problems for them if they don't keep up with changes that would, in fact, have nothing to do with them.
This is not a viable approach for the target audience we want to sell to.
It would add unnecessary Project Time and Costs overhead that the target audience does not need to bear to use the product successfully.
I can see the process of developing a small app like ours taking over six months to get into production and costing several thousand dollars related directly to the this methodology of Localization.
That would kill the project for our target audience and we just do not build the project in the first place.
So that is choice one: Do not build the project do to localization time and cost overhead using manual translation and static DLLs.
Is there another choice?
Automatic Translation...
OK, so we use the same process as above except we translate our Resource Files using the Microsoft Translator.
Here we eliminate the overhead of time and costs related to manual translation reducing the cost to our target audience significantly.
We still have the problem of DLLs and having to ReCompile and ReDistribute the new compiled code every time there is a minor change to our program.
this would not only be time consuming for us but be a major headache for our users.
I can see a Spanish user not being a happy camper paying for a upgrade to support French just to keep their DLL Versioning in sync with a French user's DLLs.
They would likely also not like the hassle of having to download and ReInstall everything if it does not relate to their situation.
Another potential problem is that the translation may not be very good at best.
Since we want to have high, professional, quality is there a way around these problems?
Yes, we allow the users, familiar with xml files and key-value string pairs as used in WindowEyes xml files, to either have their own translation performed or use the auto-generated translation.
We also supply the Resource files as native xml or text files so they can be modified by the end user either directly or as a feature of our application.
This gets around both of the identified problems quite nicely.
It will require some additional work on our part and a little more complexity in Programming Analysis and Coding but it will make the project viable to our target audience while maintaining a high level of quality.
In fact, it will improve on the quality since the end-user can customize the translations and help files to their own requirements - including having a living breathing person perform the translation for them and even changing the content of the xml or help files if desired!
Now the project is back in reach of our target audience.
The project is still a go!
Finally we need to ask...
Is there any other method available that will provide a better solution to the localization process for our audience?
No, not that I am aware of. It is either a manual translation with compiled, static resources which is not viable, as we have seen, or the use of machine language translation and dynamic files that users can modify, or have modified, if they want.
As it now stands our project should use the second method. This means more Programming work and complexity in the design and coding of the project but will keep costs and time requirements to project completion down significantly.
We have the technical staff and resources to implement it so, as it now stands, that should be the method of choice.
David, You said in your post that I said I wanted this to be a Professional Project instead of a hobby project...
OK, so tell me where my analysis is anything short of Top Level Professional and I will consider your comments as a help in developing my Professional Analytic skill set.
In fact, please give me a better option for developing this project so I can consider it before I get more gray hair working with the rather complex technicals to implement localization in the manner described above.
If there were a better way I would think WindowEyes would have used it. My approach is almost identical to their approach which I believe is better than using static DLL based resource files.
That is my "Professional" opinion and I am awating your "Professional" analysis - don't dissapoint me.
You should have a better solution since you work with companies with deep pockets doing this very thing.
Otherwise, you need to tell me if my analysis is "Professional" enough to have been done by any of the deep pockedt companies you deal with.
Just keep your analysis "Professional" and geared twoard our target audience and I will give it serious "Professional" consideration before continuing with this project.
We don't want a hobby horse approach nor one that will cause the project not to be viable for our target audience so I am awaiting your "Professional" analysis when it comes to translation procedures and technicals - perhaps your friends at the various companies you deal with will have something better.
If not, hay, my analysis must be Top Notch "Professional" indeed!
Rick USA
Oh, Rick,
How you have misunderstood my whole point in here. I never - and again, NEVER - have meant to bring your project down. If you forgive me for being rough-edged for one moment, then I don't care how much or how little time, resources, money or whatever you throw into translating your app. Again, this might sound more rough-edged, than what I intended.
Let's for a moment have a quick glance at the history here. You have several times lately, told us about your great app, and its progress in development. As far as I get it, your app is meant to ease the translation process for the end user. That is, if I get it correct, that he (the end user) can send a number of words and phrases through your app - in one turn. Your app then will have Microsoft translator do the translation of ALL these words and phrases, and return the results to the user. Great idea, and I am fully convinced your app will handle this perfectly well.
Then, one of the others on this list, asked you a polite question, if you were sure this would really be of much help for the end user. I then popped in, not to discourage or down-grade your app, but simply to show some of the limitations of electronic translators. Again, no limitation of your app, no call for you to change anything whatsoever in your app, simply to let people get a feeling of what electronic services can do for you. It be Microsoft or Google translator. It be Yahoo, Babelfish, Webster or any other web-based service. Or, be it any of the many existing paid-for services of more local character - like software packages you install directly on your computer, and which intends to do electronic translation. I have tried some of them, and in general find them doing approximately 70 percent reliable translations.
So, Rick, again, again, and again: Nothing has to be changed or messed with in your app. If you so desire, release your app in English ONLY, and keep it there. I meant to let the end-users know, what kind of reality they will have, in using your app; not anything about the app itself. Your app doesn't change the reliability of the Microsoft translator, does it? So why would I ever criticize your app for not being reliable? The real bottleneck here, is not your app, rather the electronic translators in general. Nothing you can do anything about, let alone change.
Once again, to stress what I am trying to communicate, and hopefully will manage this time. If now, you Rick, decide to release your app tomorrow (or whenever). Then say that Mrs Sunrise, and Mr Rainfall decide to buy your app. They in turn, are developing their own apps. Mr Rainfall, for instance, is developing an app that makes the standard keyboard turn into a Braille keyboard. This Braille-keyboard app, does have some checkboxes and help menus in its XML file. Well, mr Rainfall reasons, that since he now has paid a sum for your translation app, he can simply run the XML file of his Braille-keyboard app through the translation app, and then - Woopsy - have it translated all into twenty complete languages. And, RICK, here is my point. That is not the case! Mr Rainfall, not you, will have to have human translators - or at least, proofreaders - look over his translated XML tags. Not because of you Rick. Nor because of your app. But, because of the reliability of Microsoft translator.
If anyone in here, please, could tell me if I could have let my point shine more clearly through; then thanks alot. But, Rick, again, sorry that you think I am down-grading your app in itself, or asking you to throw thousands of dollars in the project. I am not. I am not even going to bother, how much money you throw into the project. That is, solely, your business. And I do see your wanting money for the end product. That is fine, and your decision; I am not going to bother. But, I do hold it was on its place, to let the end-users know, what they could expect from such a product. I am not sure, if you ever have learned any other language but English. If not, you would have little background for knowing to which extend an Electronic Translation Service is fully reliable. That is why, I popped in, giving my experiences some air.
Honestly, Rick, if people pay you money, thinking that now your app is going to solve the whole task of translating everything into the whole universe of languages, and then later learn that the product only did 70 percent of what they expected... Don't you think it would be better business to let them know, from the beginning, what to expect? I guess, since you started out the project, and have put down all that much work in the project, that you already know that people want this product. That is called market research, and as the professional guy you seem to be, I am sure you must have done some of that. But, believe me, there is tons of people who think that computers can do almost anything. Don't we see that all the time, on the GW's mailing lists? Can I have an app for this? Is there an app for that? - People think that apps can solve anything. When you introduce them to an idea of an Auto-Translate app... Well, how many would start to think, that now they could quickly and easily have their products fully translated, in a numerous number of languages, in a matter of a breeze. Reality, though, is a bit different. That is my point. That was my point. And, that is going to stand as my point. NOTHING WRONG WITH YOUR APP, Rick; YOU HAVE TO CHANGE NOTHING IN YOUR APP. Release it as it stands. Leave it in English. Noone will blame you for that. But be honest and well-informed to your customers, and let them know what they realistically will get from your app's services. I only came in from the outside, being a multi-lingual person, facing the challenges of translating and operating on more than one language every single day. I only meant to be helpful to the community. My deepest apologize, excuse, beg your pardon Sir, hands up, and whatever. I never asked you to spend thousand of dollars or anything on translating your project. Only aimed my input at the end-users, to let them have a glance at realities of the everyday.
Are you able to have a good night's sleep now, Rick? I am really not ready for more follow-up on the matter. Just wanted to clarify my intensions. Hopefully this message finally managed to make it clear - to you, and everyone else - what I really wanted to commmunicate.
Again, sorry!
----- Original Message -----
From: RicksPlace
To: gw-scripting@gwmicro.com
Sent: Wednesday, June 15, 2011 1:41 PM
Subject: WETranslator Design And Localization
Hi David et al: I guess it is time to "Put Up or Shut Up".Well, last night I spent time researching the use of Resource Files.
Here are my findings:
Research files are actually text files containing xml elements for every item in an application.
In Visual Studio there are 2 methods of creating them.
The first is to just set the Form Property to Localizable.
This automatically will generate a xml Resource file for each form in the project.
Each xml file is then translated, by machine or by a living breathing person, into some Culture Language and they get compiled with the program before distribution.
The second method is to build the same Resource File contents for the entire project, compile them seperatly and include them as individual DLLs with the project.
We also have to hand build any UserMessages xml and text Help files to be included in the project.
The files are then included as DLLs during compilation and distributed as part of, or along with, the main assembly.
Now for a "Professional Analysis" of best technicals to use for this Audience...
Our app is designed for Scriptors.
That means they are experienced and comfortable with some programming language and xml files.
They also do allot of open source and free development of projects to help other Blind Folks make applications more accessible.
OK, so what do we know about designing our project?
We will try and keep time and development costs to a minimum.
We will use free or very low cost tools when possible without sacrificing quality wherever possible.
We can depend on our end-users having a basic understanding of how things are done on a computer, what a xml file is and how it might be used to store and retrieve data in an application like WindowEyes for example.
Now we are ready to look at some design requirements and related technicals:
I will skip everything except the translation and Localization process.
Wwe have a general design for our application and have decided to use VB.net as the implementation tool for several good reasons related to our original audience premise.
Actually it was a toss up between VB.net and VBScript but vB.net won out in the end for it's support of the .net framework objects.
Next:
We have to choose how to handle Localization.
We can just check a property in a form and have the resource files generated automatically.
Then contact perhaps 20 or so translators to have them translated into various Cultures and sent back to us.
When the translations are all done we can compile and start beta testing.
During beta testing, for any change, we will have to make modifications to our application. Then we need to gather the source code for all the language DLLs, send them back to all the translators who will have to promptly do the new translations and send them back to us ASAP since testing can not continue until we get all the translations back, ReCompile the application, ReDistribute the application to the testors who will need to ReInstall all or parts of the application including the new DLL Versions.
We will also have to do that for all folks who use our product if any new language support is added downline or users will have diferent versions of the DLLs which will likely end up causing problems for them if they don't keep up with changes that would, in fact, have nothing to do with them.
This is not a viable approach for the target audience we want to sell to.
It would add unnecessary Project Time and Costs overhead that the target audience does not need to bear to use the product successfully.
I can see the process of developing a small app like ours taking over six months to get into production and costing several thousand dollars related directly to the this methodology of Localization.
That would kill the project for our target audience and we just do not build the project in the first place.
So that is choice one: Do not build the project do to localization time and cost overhead using manual translation and static DLLs.
Is there another choice?
Automatic Translation...
OK, so we use the same process as above except we translate our Resource Files using the Microsoft Translator.
Here we eliminate the overhead of time and costs related to manual translation reducing the cost to our target audience significantly.
We still have the problem of DLLs and having to ReCompile and ReDistribute the new compiled code every time there is a minor change to our program.
this would not only be time consuming for us but be a major headache for our users.
I can see a Spanish user not being a happy camper paying for a upgrade to support French just to keep their DLL Versioning in sync with a French user's DLLs.
They would likely also not like the hassle of having to download and ReInstall everything if it does not relate to their situation.
Another potential problem is that the translation may not be very good at best.
Since we want to have high, professional, quality is there a way around these problems?
Yes, we allow the users, familiar with xml files and key-value string pairs as used in WindowEyes xml files, to either have their own translation performed or use the auto-generated translation.
We also supply the Resource files as native xml or text files so they can be modified by the end user either directly or as a feature of our application.
This gets around both of the identified problems quite nicely.
It will require some additional work on our part and a little more complexity in Programming Analysis and Coding but it will make the project viable to our target audience while maintaining a high level of quality.
In fact, it will improve on the quality since the end-user can customize the translations and help files to their own requirements - including having a living breathing person perform the translation for them and even changing the content of the xml or help files if desired!
Now the project is back in reach of our target audience.
The project is still a go!
Finally we need to ask...
Is there any other method available that will provide a better solution to the localization process for our audience?
No, not that I am aware of. It is either a manual translation with compiled, static resources which is not viable, as we have seen, or the use of machine language translation and dynamic files that users can modify, or have modified, if they want.
As it now stands our project should use the second method. This means more Programming work and complexity in the design and coding of the project but will keep costs and time requirements to project completion down significantly.
We have the technical staff and resources to implement it so, as it now stands, that should be the method of choice.
David, You said in your post that I said I wanted this to be a Professional Project instead of a hobby project...
OK, so tell me where my analysis is anything short of Top Level Professional and I will consider your comments as a help in developing my Professional Analytic skill set.
In fact, please give me a better option for developing this project so I can consider it before I get more gray hair working with the rather complex technicals to implement localization in the manner described above.
If there were a better way I would think WindowEyes would have used it. My approach is almost identical to their approach which I believe is better than using static DLL based resource files.
That is my "Professional" opinion and I am awating your "Professional" analysis - don't dissapoint me.
You should have a better solution since you work with companies with deep pockets doing this very thing.
Otherwise, you need to tell me if my analysis is "Professional" enough to have been done by any of the deep pockedt companies you deal with.
Just keep your analysis "Professional" and geared twoard our target audience and I will give it serious "Professional" consideration before continuing with this project.
We don't want a hobby horse approach nor one that will cause the project not to be viable for our target audience so I am awaiting your "Professional" analysis when it comes to translation procedures and technicals - perhaps your friends at the various companies you deal with will have something better.
If not, hay, my analysis must be Top Notch "Professional" indeed!
Rick USA
