On Fri, 1 Jun 2007 02:09:36 +0200 (CEST)
"francesco namuri" <francesco@namuri.it> wrote:
> On Ven, Giugno 1, 2007 00:16, Neil Williams wrote:
> > On Thu, 31 May 2007 22:45:01 +0200 (CEST)
> >
> > 1. The long description can be improved. The use of 'even more!' is not
> ideal and some of the features (like import/export) could do with some
> more detail. The "standard" application in this area is gnucash (I was a
> gnucash developer at one time) and your long description should follow
> that template and tell the user how homebank differs from the "standard"
> app in the field. For one thing, you should make a big deal about how
> quickly homebank starts up compared to gnucash (which
> > probably has a LOT to do with the vastly reduced number of
> > dependencies).
>
> I hope now it's ok...
"better look and feel" is subjective but that's OK. (You also refer to
the speed twice which is, umm, excessive.) ;-)
For the next upload, consider something like:
HomeBank is a fast, simple and easy to use program to manage your
accounts. HomeBank has a simpler look and feel than gnucash and
includes features such as easy analysis with graphical charts
(statistics, budget, overdrawn, car cost), multiple account support,
budget management, reminders, import from OFX/QFX-CSV files and visual
status indicators. It is based on GTK2.
> > 5. Please ask upstream to make it clear in the app that Help|Contents
> requires an internet connection - this action has the F1 shortcut key
> which most users would expect to provide offline documentation, not
> online - especially as the Help menu specifically includes an online
> help menu item which takes you to a different site. This is just a case
> of preempting bug reports. I would encourage you to encourage upstream
> to provide offline documentation - HTML is fine - via doc-base and a
> homebank-doc package.
>
> ok, I'll contact the author...
Something else for upstream too - before you get any bug reports from
debian-i18n, ask upstream about packaging po/homebank.pot in the next
upstream tarball. This makes it much much easier to ask for debian
translations that can also be fed upstream.
I know homebank includes support for translations upstream via
launchpad but there is no harm in also using the Debian translation
teams. Debian tools are intelligent enough to always use the
Last-Translator fields so that work is not duplicated and you can opt
not to send requests to certain upstream people. Each new translation
will need a change to configure.ac so it is best to ensure that new
translations are always fed upstream. Also, ask upstream to enable this
page:
https://launchpad.net/homebank/+translations
" The HomeBank product is not set up for translation in Launchpad.
If you’re Maxime Doyen, log in to begin the setup process. "
There is little point putting that link in the application when the
page has not been activated.
To package the POT file all upstream needs to do is create a suitable
target in the top level Makefile.am:
pot: Makefile
${MAKE} -C po $(PACKAGE).pot
and then add po/$(PACKAGE).pot to EXTRA_DIST
I think an en_GB translation may be useful for this one - "operations"
are probably easier to understand as "transactions" in the UK (and
maybe elsewhere). With a pot file in the .orig.tar.gz, you can use
podebconf-report-po to call for new translations as well as updates to
existing ones. See man podebconf-report-po
(The POT file contains minor typo errors too. I have done an en_GB
translation that highlights some of the typos - sent off list. Feel
free to send that upstream for inclusion in the next upstream release
and ask me for updates when some of the localisation issues are fixed.)
If this was my own package, I'd be tempted to use the easy CDBS patch
system to add the snippet above and document how to generate the POT
file via README.Debian. Depending on how you get on with upstream, that
could be a useful exercise for you as maintainer. You don't want to
include changes to EXTRA_DIST in your patch, just the make target.
A more involved task upstream is to handle plurals correctly:
%d·operation(s)·inserted\n
%d·error(s)·in·the·file
gettext can handle these such that the translator gets these strings:
%d·operation·inserted\n
%d·error·in·the·file
%d·operations·inserted\n
%d·errors·in·the·file
and gettext adds a plural when one is required. Adding (s) is not
a correct plural in many languages.
Also, the GNU licence text should not be marked translatable. Most
translators will realise this and not translate it but the licence text
is part of a legal document and translating it could cause a change in
the meaning of the text in specific locales.
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLTranslations
"It would be useful to have translations of the GPL into languages other
than English. People have even written translations and sent them to
us. But we have not dared to approve them as officially valid. That
carries a risk so great we do not dare accept it."
Other translation/locale issues include the "consumption per 100km"
calculation. I know it's awkward but kilometres are not the universal
measurement of distance, particularly in relation to cars. That may
require more than a slight adjustment upstream, it depends how this
value is calculated and used. Further complications include the
measurement of distances in miles, fuel volumes in litres and fuel
consumption in miles per gallon. (!) Some form of extended calculation
dialogue appears necessary! (en_GB is not the only locale with a mix of
imperial and metric measurements).
> thanks for the interest and for the review Neil, I hope that now the
> package is ready for the upload... :)
It is. There are issues for upstream and things you can do as
maintainer to make translations easier but those are fine for later.
I'll make the upload to NEW later today.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
pgpav7hm2pY9q.pgp
Description: PGP signature