[jawsscripts] Re: Localization
- From: Soronel Haetir <soronel.haetir@xxxxxxxxx>
- To: jawsscripts@xxxxxxxxxxxxx, Doug Lee <doug.lee@xxxxxxxxxxxxxxxx>
- Date: Wed, 31 Dec 2014 11:12:10 -0900
XML parsers are supposed to preserve whitespace in elements, it's only
in attribute values that normalization is applied.
On 12/31/14, Doug Lee <doug.lee@xxxxxxxxxxxxxxxx> wrote:
> This is a response to several things in this thread at once and is
> thus a bit lengthy.
>
> The standard way to support localization in JAWS is to have different
> language-specific versions of jsm files for each language. For an
> installer, this means distributing different files depending on the
> language wanted. The files also go into a different JAWS folder based
> on the language.
>
> There are several places where a language is selected: There's the
> Windows language, the application language, the JAWS language, and the
> synthesizer language. Out of these, it's the JAWS language that
> determines which folder is used to run scripts. So for example, if you
> use JAWS in Spanish, scripts come from settings\esn folders instead of
> settings\enu folders.
>
> There is of course some considerable appeal to the idea of using a
> runtime method of selecting language. Ini files are an obvious choice
> for this, but they fail at one crucial thing: A jsm file's
> "messages"/"endMessages" construct allows for multiline messages. This
> is particularly handy for crafting help text. An ini file does not
> conveniently allow this. There are workarounds, such as keys with
> numeric suffixes; but these end up being very messy to maintain when a
> long block of text changes.
>
> Another candidate might be xml. Xml would of course allow unlimited
> text block size, but I'm not sure how easily one could keep the actual
> structure of a text block unchanged. Specifically, I suspect newline
> characters could get translated automatically into spaces, which could
> destroy the intended appearance of help text.
>
> I've actually considered trying to adapt the GetText system used by
> other open-source projects for JAWS, but I haven't found the time or
> managed to assess completely enough the feasibility of this endeavor.
>
> Finally, there's the option of designing a format specifically for
> JAWS for this. This can be done using the Scripting.FileSystem object
> to read file contents. Again I have not tackled this project for lack
> of time/energy, but it is certainly possible.
>
> My final item to address here is a return to the issue of how to
> select a language. This is actually the most compelling reason, in my
> opinion, for considering a change in how to handle localization in
> JAWS:
>
> As I said, the single criterion currently for selecting a language for
> a script is the JAWS language. In practice though, there are times
> when more than one language applies to a situation: People may run
> Windows itself in English, then run Skype in Spanish or English at
> different times while running JAWS in Spanish or English but not
> necessarily in sync with the Skype language. This may sound unlikely,
> but though I have no proof that it happens, I suspect it does because
> of the difference in complexity (not to mention expense in some cases)
> of switching the JAWS or Windows language versus switching the Skype
> language.
>
> In short, I think it would be cool to let a script choose its language
> for output based on the JAWS or synthesizer language while choosing
> the language for its "input" based on the Windows or application
> language. (The application language might be hard to determine from a
> script though.) I put "input" in quotes because I really mean the
> language of constants that are sought from within the application,
> such as MSAA and window name strings and actual screen text. I don't
> know how much effort this change is worth because I don't know how
> frequently people try to run an application in a different language
> than JAWS itself. Comments welcome on that question.
>
> On Mon, Dec 29, 2014 at 02:42:32PM -0600, Jim Snowbarger wrote:
> I am curious how people do this. You create a JSM file which contains
> messages written in a particular language. But, as far as I know, there is
> no way to qualify the message based on the currently selected language.
> The
> only way I know to do it is to substitute a new JSM file with the correct
> language, and recompile the script.
> I'm sure that isn't the right way to do that. Can somebody set me straight
> on the preferred technique?
>
> Thanks much.
>
>
>
>
>
> __________???
>
> View the list's information and change your settings at
> //www.freelists.org/list/jawsscripts
>
> --
> Doug Lee, Senior Accessibility Programmer
> SSB BART Group - Accessibility-on-Demand
> mailto:doug.lee@xxxxxxxxxxxxxxxx http://www.ssbbartgroup.com
> "While they were saying among themselves it cannot be done,
> it was done." --Helen Keller
> __________�
>
> View the list's information and change your settings at
> //www.freelists.org/list/jawsscripts
>
>
--
Soronel Haetir
soronel.haetir@xxxxxxxxx
__________�
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
Other related posts:
