[jsword-devel] BD translations

[DM Smith]

Peter,
    I think these are worthy ideas, but they will take a bit of work to 
make it happen.

Peter von Kaehne wrote:
> Looking at the source code of Al-Kitab and while  thinking about
> translating it, I suddenly started to wonder again re BD + whether we
> went wrong with including application language choice.
>   
The language choice is only pertinent for users in one Locale to bring 
up the program in another Locale. People in Iran, who run BD should have 
it automatically come up in Farsi. Likewise, people in Germany should 
have it come up in German. For Chinese, this gives one the ability to 
choose between two different scripts. But, Iranians in Scotland might 
have the program start in English and then need to switch.

I think it is useful for developers and needs to at least be a hidden or 
advanced option.

> I think few if any people will want to mess around with the various
> application language options, most will simply want to run a programme
> in the language they are used to.
I agree. But this is only an issue where auto-detection of a user's 
locale doesn't match the user's expectation.
>  Also most churches etc who might want
> to distribute BD will want to do so in the language they use instead of
> telling their recipients to start an English programme, switch it to
> e.g. Chinese and then restart it.
> Particularly if we keep adding translations this might also add to
> considerable bulk.
>
> So, what do you think about the following two options: -
>
> 1) wholesale removal of the whole language choice code, but adjustment
> of the build scripts so that one can produce a - potentially much
> leaner? - BD executable in any chosen language at build time.
>   
I don't have much problem with multiple builds. But we are running low 
on space on the CrossWire server. So, I don't see doing it for the 
nightly build.
> 2) or distribution of the English executable with loadable translation
> modules as separate items for distribution.
>   
English will always be the fall-back for all translations. That is, if a 
translation of a particular string is missing, then English will be 
provided.

This option is lighter in it's space requirements than the first and 
could be part of a nightly build. Potentially, this would require no 
more space that what we currently take.

With either of these options, it would also be good to have 
desktop.properties and a few property files initialized with language 
appropriate choices, e.g. font specification.

> (1) particularly  could result also in speed improvements - choice of a
> RtoL language at build time could result also in RtoL oriented code
> rather than in code offering both options and requiring again and again
> decisions.
I don't think that there would be much of a performance improvement, as 
I didn't see much of a hit to displaying non-Farsi when I added the 
"expensive" number shaping code. Most of that shaping in done on verse 
numbers and references in the XSL transformation of the OSIS into HTML.

A third option (which doesn't work for Mac, because a Mac is required to 
build a dmg) is to dynamically merge the application and the chosen 
language resources when the user downloads the program. I think we can 
auto-detect the user's locale as the default choice. (Likewise, we could 
automatically detect their OS and default to the appropriate download.)

Later, we plan to re-engineer the program to use RCP/SWT/JFace and we 
will get "language pack" support for cheap. (They have it and we won't 
have to invent it).

In Him,
    DM