[jsword-devel] BibleDesktop/JSword translations

DM Smith dmsmith555 at yahoo.com
Sun Feb 10 13:55:06 MST 2008


I have made a few changes regarding the "action" property files as it  
impacts doing translations of the application into other languages.

The action property files are the ones that describe a Name, Small and  
Large Icons, Short and Long descriptions, Initial Enable state,  
Mnemonics and Accelerators.

There are several problems in doing translations. Here are the ones I  
addressed and how I addressed them.
1) There are some entries which should not be internationalized  
(i18n). This means that they either need to be repeated verbatim in  
each translation or deleted. The problem with repeating them is that  
they are hard to keep in synchronization across the set of  
translations, should there need to be a change. Also, it is confusing  
to have values that don't need to be translated.

The JInto plugin that many of us are using to create and maintain the  
translated files requires that the values be repeated. This has caused  
some errors such as buttons and menu items being disabled and icons  
not showing up.

Regarding this, I have split the action file into two parts. One part  
is a control file and the other is a text file. Only the text file  
needs to be translated. For example, we had Desktop.properties and now  
we have added Desktop_control.properties.

The entries in Desktop.properties that have been moved to  
Desktop_control.properties are like the following:
Xxx.Enabled
Xxx.SmallIcon
Xxx.LargeIcon

If there is a need to supply alternate icons, we can do "translations"  
of these files. But it should not be necessary. (We are looking to  
replace the "Book" icons and the ~1 and ~5 icons with ones that don't  
need to be i18ned)

2) Another problem was that there were some unnecessary entries in  
these "action" property files. These are entries in the default file  
that had nothing to the right of the = sign. I think that these made  
translations difficult as it was not clear why they were there. It  
would be far better for every line in a translated file to need to be  
translated.

Another kind of unnecessary entry is one that matches the default. For  
example, Xxx.Enabled=true is pretty much the same as not having the  
entry. For this reason, I deleted them everywhere. (Of course  
Yyy.Enabled=false, was left)

As a solution to this problem, I deleted across all the property files  
any entries that were unnecessary.

3) The field Xxx.Mnemonic=L is problematic. A mnemonic is a letter  
that is underlined. In this case, the first letter 'L' (regardless of  
case) would be underlined in the Xxx.Name field. Nearly every last  
mnemonic in a translation did not match a letter in the name. This is  
a common convention on Windows and many find it useful on menus for  
keyboard navigation. It is also typical on Linux. On Mac, it is  
suppressed as the Mac UI guidelines say they are not to be used.

I deleted every value that did not match and there was no obvious  
value that should be used. That is I left the key followed by an =  
sign and no value to the right. If there was an obvious value, I fixed  
the entry.

Some problems that I have not addressed:
1) There are some strings that are repeated in many actions across  
many files, such as Yes, No, OK, Cancel, Help, .... These should only  
need to be specified once. I will be adding an "alias" mechanism to  
address these. I may get to this later today. An alias will have look  
just like a regular action definition.

The basic idea is as follows:
In o.c.c.util there will be Alias.properties and all its translations.  
This will be used by ActionFactory to do substitutions.

In a property file such as Desktop.properties one would invoke an  
alias with:
Xxx.Name=Alias.OK

For Xxx, any entries in Alias.properties for OK.field=value that are  
appropriate, they can be deleted. If one wishes to override any values  
from the Alias file, they would be retained in Xxx definition.

2) Actions are shared, which is generally a good thing. This means  
that the same action can be on a menu, in the tool bar and in a right- 
click context popup menu without repeating code. But it can also be a  
bad thing in that it forces the proliferation of some actions just so  
that they can avoid sharing. I think the solution to this is to have  
Xxx.Shared=false for actions that can be reused but are not shared.


3) It is hard to know in the Msg.property files what is important to  
translate and which is unimportant. These should be split into  
different Msg files. Until I get around to this, follow the lead of  
the Farsi translation.

4) Finding the properties files to translate is not straightforward or  
obvious. It would be nice to come up with a way to make it easier.

One suggestion would be to co-locate the files in a single folder in  
each of common, common-swing, jsword and bibledesktop. An advantage of  
co-locating them would be that it would be easier to package  
BibleDesktop for just one language. The properties would be in their  
own jars on a per language basis. One would add language packs as they  
found fit. (But unless someone is up for it, that is a ways off)

For those of you doing translations, I'd love to have feedback and  
suggestions.

Working together for His Kingdom,
	DM




More information about the jsword-devel mailing list