[sword-devel] SWLocale / LocaleMgr

[Troy A. Griffitts]

SWLocale and LocaleMgr are for localization (l10n) in general.  We use
them in the library for book references and verse key parsing
information, but that is about all we localize in the library.  It is
meant to handle any l10n issues for anyone-- most importantly the
frontend.  Equivalent tr() macro might be:

#define tr(english) LocaleMgr::systemLocalMgr.translate( \
	LocaleMgr::systemLocalMgr.getDefaultLocaleName (), \
	english);


	Hope this is useful.

	-Troy.



Martin Gruner wrote:
> 
> Hello Chris,
> 
> > To my understanding, based on what Troy has told me, the translation
> > functions we have could be used for any string.  All our
> > library/front-end strings could be put into the locale files with
> > translations to provide l10n across the library.  So, I think the
> > functionality exists in the library, though it hasn't yet been used to
> > its full potential.  Correct me if I'm wrong. I may have misunderstood
> > Troy. :)
> 
> I may too. But AFAIK the Locale mechanism you're referring to does only cover
> the 66 KJV-style booknames and abbreviations. It could probably be extended
> somewhat, say for different versification schemes. But you could not
> translate any string you want. And if a frontend program wanted to do the
> translation of its messages, it would have to change the sword locale files!
> 
> > > =) I really hope it were so. ;) We should work more on
> > > documentation, esp.
> > > making the api-ref more complete and explaining.
> >
> > I agree.  The API primer that we keep directing potential users to could
> > really use some cleanup.  It's confusing, out of date, and doesn't
> > reflect the kinds of things implementers would actually do.
> 
> It would be nice if somebody with in-depth knowledge of sword could go
> through all the header files, and correct/add the JavaDoc style comments. At
> the moment classes have many undocumented members, and some classes are not
> documented (and therefore hidden in the api-docs) or uncorrectly documented
> (esp. some of the recently introduces ones). We should try to make
> documenting the (public api) classes a part of programming itself.
> 
> Martin