Number to Words and licencing
ttroesch at gmail.com
Sat Nov 2 16:37:25 EDT 2013
On Fri, Nov 1, 2013 at 2:40 PM, John Ralls <jralls at ceridwen.fremont.ca.us>wrote:
> On Nov 1, 2013, at 11:14 AM, Thomas Troesch <ttroesch at gmail.com> 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 ( icu-project.org ):
> > "The ICU projects since ICU 1.8.1 and ICU4J 1.3.1 are covered by the ICU
> > license <http://source.icu-project.org/repos/icu/icu/trunk/license.html>
> > 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
> > at "RuleBasedNumberFormat" at the bottom of "http://userguide.icu-
> > project.org/formatparse/numbers". Class documentation is at "
> > project.org/apiref/icu4c/classRuleBasedNumberFormat.html".
> > 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 , but it’s pretty close
> the BOOST license , 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.
> sort of thing can get a bit onerous: See the FSF discussion about the
> BSD license . Compatibility  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
> them, ICU is easily the best cross-platform FOSS I18N/L10N library
> It has one problem: Its translation facility is utterly incompatible with
> gettext, and gettext is what almost all FOSS translators are used to. That
> 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
> to sign up for. OTOH it seems dumb to use ICU for just number->numeric text
> John Ralls
>  http://www.gnu.org/licenses/license-list.html
>  http://directory.fsf.org/wiki/License:Boost1.0
>  http://www.gnu.org/philosophy/bsd.html
>  http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible
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
http://en.wikipedia.org/wiki/Cheque . 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