On Fri, Nov 1, 2013 at 2:40 PM, John Ralls <[email protected]>wrote:
> > On Nov 1, 2013, at 11:14 AM, Thomas Troesch <[email protected]> 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 " > http://source.icu-project.org/repos/icu/ > > icu/trunk/license.html". The function that I'm interested in is > described > > at "RuleBasedNumberFormat" at the bottom of "http://userguide.icu- > > project.org/formatparse/numbers". Class documentation is at " > http://icu- > > 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 [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] http://www.gnu.org/licenses/license-list.html > [2] http://directory.fsf.org/wiki/License:Boost1.0 > [3] http://www.gnu.org/philosophy/bsd.html > [4] http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible John: 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. Thomas _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
