Number to Words and licencing

Thomas Troesch ttroesch at
Sat Nov 2 16:37:25 EDT 2013

On Fri, Nov 1, 2013 at 2:40 PM, John Ralls <jralls at>wrote:

> On Nov 1, 2013, at 11:14 AM, Thomas Troesch <ttroesch at> wrote:
> > I have been looking at the list of open bugs for check printing.  Bug
> > 626001 asks for number to words based on locale.
> >
> > One approach would be to provide for locale specific plug-ins or code
> > paths.  For a programmer its a simple way to think about it, but I don't
> > know how well that would work with translators.
> >
> > I found some open source code that has a rule based parser to support
> > NLSnumber translations.  The rules themselves may be too much for the
> > typical
> > translator.
> >
> > Before I dig into it to see if it would work for checks ( looks promising
> > ), I'd like to have an opinion regarding license compatibility.
> >
> > From the web ( ):
> > "The ICU projects since ICU 1.8.1 and ICU4J 1.3.1 are covered by the ICU
> > license <>
> ,
> > a simple, permissive non-copyleft free software license, compatible with
> > the GNU GPL.".  The license is at "
> > icu/trunk/license.html".  The function that I'm interested in is
> described
> > at "RuleBasedNumberFormat" at the bottom of "
> >".  Class documentation is at "
> http://icu-
> >".
> >
> > I have no intuition as to whether bringing in a lump of code like this
> > would make sense.  Opinions and insight welcome.
> The ICU license isn’t on the FSF-approved list [1], but it’s pretty close
> to
> the BOOST license [2], which is, and which is approved. However, it
> includes one
> extra clause that’s somewhat annoying: The requirement to document the
> copyright not only in the code but also in all supporting documentation.
> That
> sort of thing can get a bit onerous: See the FSF discussion about the
> original
> BSD license [3]. Compatibility [4] comes down to whether it’s OK to combine
> the work in question with a work released under the GPL, and if the authors
> say it is, I guess they know best.
> Lifting code out of other projects is asking for trouble: Either we become
> responsible for maintaining that new code or we have to expend significant
> effort to keep in sync with the original tree. Much better to make it a
> dependency and link it.
> That said, while I think we’re trying to reduce dependencies rather than
> add
> them, ICU is easily the best cross-platform FOSS I18N/L10N library
> available.
> It has one problem: Its translation facility is utterly incompatible with
> gettext, and gettext is what almost all FOSS translators are used to. That
> can
> be avoided by continuing to use gettext for translation and using ICU for
> everything else… but that’s perhaps a bit bigger job than what you’re
> willing
> to sign up for. OTOH it seems dumb to use ICU for just number->numeric text
> formatting.
> Regards,
> John Ralls
> [1]
> [2]
> [3]
> [4]


Thank you for your thoughtful response.

I had looked at ICU only for the purpose of number to words translation.  I
just now took the time to review the scope of what it addresses, and I see
how big a task it would be to incorporate ICU in general.  It seems to have
clear advantages, but its much more work than I can, or probably should,
do.  I'm not really familiar with NLS issues.  I took my very first look at
a .po file just to get an idea about how things work now.

I'm focused on NLS for printing checks, and all I know about it is from .  Do you think it would be at all
practical to consider developing plug-ins for number to words based on
locale settings?  Developing translations would be a very different
process, but may be sufficiently interesting for some people.


More information about the gnucash-devel mailing list