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
