Rick,
No, the tags and such never get localized. They will always remain in
English. If we allowed this it would be a nightmare because the script
would have to match the localized Window-Eyes version. Meaning if I
were running a German Window-Eyes than I wouldn't be able to run an
Italian app. Just as you don't localize VBScript...such as For i=1 to
10 wouldn't be localized you don't localize XML tags. Typically only
strings that would be displayed to the user would be localized.
Doug
On 6/23/2011 10:17 AM, RicksPlace wrote:
Hi Guys:
First: When you build a script in another country and are building the
xml file do you use the element names in your own language?
In other words....
<string is one element name but when you build your xml file in your
country does it still hold the English word <string or would it be the
equivalent in your language?
The same for <language and the various <string id="something">
I was thinking of building a find command over the text box that
displays the contents of the xml file but any comparison between the
search string and the contents of the xml file are going to be a
problem for the reason stated above and...
The element names and id values might be in your language or English
as mentioned but the CDATA sections within each language will be in
diferent languages. If all your element names and id values are in
your culture then I could at least advance to each language section to
shorten searches. That, however, would not work if you are not working
in the culture of the thread you are running the app in, usually the
one you have loaded on your os. So this feature will not work if you
can pick a diferent language than the one loaded on your machine
without some jury rigging.
Anyway, if you have any thoughts on this let me know since I am now
either going to add a find for the xml textbox to find something
faster or add the election not to work in the language you are running
under when you start the WETranslator application the first time.
Rick USA
