[sword-devel] List of global options

Daniel Glassey dglassey at gmail.com
Mon May 5 15:28:32 MST 2008


2008/5/5 Peter von Kaehne <refdoc at gmx.net>:
> Eeli Kaikkonen wrote:
>  > On Mon, 5 May 2008, Troy A. Griffitts wrote:
>  >> I respectfully disagree.  If a frontend wants to localize these strings,
>  >> they can pass them to their own localization engine, j
>
> > This would work properly if all frontend translators would add the
>  > library specific translations into the library, not into the frontends.
>  >
>
>  As a front end translator without much technical knowldedge - can I
>  barge in?
>
>  Where these strings turning up in raw form in front ends? Aren't they of
>  no relevance whatsoever for users - apart from the mdoule conf file
>  which as a user one would never look at or touch?

Afaiu they are the 'Module Options' such as 'Words of Christ in Red'
or 'Strongs Numbers'

Instead of the library doing the translation it would be good to be
able to generate a translatable gettext .pot file on the server. Then
that could be translated and optionally distributed with the library.
The frontends would then be able to use gettext to get the
translations. For apps that don't use gettext another mechanism could
be made.

I guess we need a small program and script that:
goes through all the modules on the server
and for each output all the module options it has

take this list and do uniq on it to get the unique list of options

do whatever is needed to transform this list into a .pot file

The translated files can be transformed into java .properties files
for use with java
http://www.gnu.org/software/gettext/manual/html_node/Java.html

The point of this is to only do the translation once and be able to share it.
Other terms that are common between frontends could be added to this
file as well so translations can be shared
e.g. Book, Chapter, Verse,

There's a spec, so anyone up for doing that? (Or anyone with a better idea? ;) )

Regards,
Daniel



More information about the sword-devel mailing list