> > Sword removes much of the burden of designing new Bible software. > > Most of the underlying issues, such as search, file access, verse > > reference parsing, markup format interchange, i18n/l10n, etc. have > > already been dealt with, allowing you the opportunity to focus on > > interface design and unique features. > > Well, i18n and l10n are still quite at the beginning. You > should not say > "have been dealt with". The versification scheme is still to > come -- is that > what you mean by l10n? > > > Custom > > translation APIs provide the means for building l10n > support in your > > applications without needing to add or depend on additional > 3rd party > > libraries. > > What are you referring to?
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. :) Versification is a different issue entirely. > > Sword provides a simple to use and easy to learn API. > > =) I really hope it were so. ;) We should work more on > documentation, esp. > making the api-ref more complete and explaining. > > But in general I really agree! 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. --Chris
