2023-01-15 21:56:49 +00:00
|
|
|
Source: numerus
|
|
|
|
|
Section: web
|
|
|
|
|
Priority: optional
|
|
|
|
|
Maintainer: jordi fita mas <jordi@tandem.blog>
|
|
|
|
|
Build-Depends:
|
|
|
|
|
debhelper-compat (= 13),
|
|
|
|
|
dh-golang,
|
Add Catalan and Spanish translation with gotext[3]
I had to choose between [1], [2], and [3].
As far as i could find, [1] is not easy to work with templates[4] and at
the moment is not maintained[5].
Both [2] and [3] use the same approach to be used from within templates:
you have to define a FuncMap with template functions that call the
message catalog. Also, both libraries seems to be reasonably
maintained, and have packages in Debian’s repository.
However, [2] repeats the same mistakes that POSIX did with its
catalogs—using identifiers that are not the strings in the source
language—, however this time the catalogs are written in JSON or YAML!
This, somehow, makes things worse….
[3], the one i settled with, is fine and decently maintained. There are
some surprising things, such as to be able to use directly the PO file,
and that it has higher priority over the corresponding MO, or that the
order of parameters is reversed in respect to gettext. However, it uses
a saner format, and is a lot easier to work with than [3].
The problem, of course, is that xgettext does not know how to find
translatable strings inside the template. [3] includes a CLI tool
similar to xgettext, but is not a drop-in replacement[6] and does not
process templates.
The proper way to handle this would be to add a parser to xgettext, but
for now i found out that if i surround the call to the translation
functions from within the template with parentheses, i can trick
xgettext into believing it is parsing Scheme code, and extracts the
strings successfully—at least, for what i have tried. Had to add the
keyword for pgettext, because Schemed does not have it, but at least i
can do that with command line parameters.
For now i left only Spanish and Catalan as the two available languages,
even though the source text is written in English, because that way i
can make sure i do not leave strings untranslated.
[1]: https://golang.org/x/text
[2]: https://github.com/nicksnyder/go-i18n
[3]: https://github.com/leonelquinteros/gotext
[4]: https://github.com/golang/go/issues/39954
[5]: https://github.com/golang/go/issues/12750
[6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
|
|
|
gettext,
|
2023-01-15 21:56:49 +00:00
|
|
|
golang-any,
|
|
|
|
|
golang-github-jackc-pgx-v4-dev,
|
2023-02-03 11:30:56 +00:00
|
|
|
golang-github-julienschmidt-httprouter-dev,
|
Add Catalan and Spanish translation with gotext[3]
I had to choose between [1], [2], and [3].
As far as i could find, [1] is not easy to work with templates[4] and at
the moment is not maintained[5].
Both [2] and [3] use the same approach to be used from within templates:
you have to define a FuncMap with template functions that call the
message catalog. Also, both libraries seems to be reasonably
maintained, and have packages in Debian’s repository.
However, [2] repeats the same mistakes that POSIX did with its
catalogs—using identifiers that are not the strings in the source
language—, however this time the catalogs are written in JSON or YAML!
This, somehow, makes things worse….
[3], the one i settled with, is fine and decently maintained. There are
some surprising things, such as to be able to use directly the PO file,
and that it has higher priority over the corresponding MO, or that the
order of parameters is reversed in respect to gettext. However, it uses
a saner format, and is a lot easier to work with than [3].
The problem, of course, is that xgettext does not know how to find
translatable strings inside the template. [3] includes a CLI tool
similar to xgettext, but is not a drop-in replacement[6] and does not
process templates.
The proper way to handle this would be to add a parser to xgettext, but
for now i found out that if i surround the call to the translation
functions from within the template with parentheses, i can trick
xgettext into believing it is parsing Scheme code, and extracts the
strings successfully—at least, for what i have tried. Had to add the
keyword for pgettext, because Schemed does not have it, but at least i
can do that with command line parameters.
For now i left only Spanish and Catalan as the two available languages,
even though the source text is written in English, because that way i
can make sure i do not leave strings untranslated.
[1]: https://golang.org/x/text
[2]: https://github.com/nicksnyder/go-i18n
[3]: https://github.com/leonelquinteros/gotext
[4]: https://github.com/golang/go/issues/39954
[5]: https://github.com/golang/go/issues/12750
[6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
|
|
|
golang-github-leonelquinteros-gotext-dev,
|
|
|
|
|
golang-golang-x-text-dev,
|
2023-01-22 03:32:03 +00:00
|
|
|
postgresql-all (>= 217~),
|
|
|
|
|
sqitch,
|
|
|
|
|
pgtap,
|
2023-06-15 10:19:08 +00:00
|
|
|
postgresql-15-pg-libphonenumber,
|
|
|
|
|
postgresql-15-pgtap,
|
|
|
|
|
postgresql-15-pguri,
|
Add IBAN and BIC fields to contacts
These two fields are just for information purposes, as Numerus does not
have any way to wire transfer using these, but people might want to keep
these in the contact’s info as a convenience.
Since not every contact should have an IBAN, e.g., customers, and inside
SEPA (European Union and some more countries) the BIC is not required,
they are in two different relations in order to be optional without
using NULL.
For the IBAN i found an already made PostgreSQL module, but for BIC i
had to write a regular expression based on the information i gathered
from Wikipedia, because the ISO standard is not free.
These two parameters for the add_contact and edit_contact functions are
TEXT because i realized that these functions are intended to be used
from the web application, that only deals with texts, so the
ValueOrNil() function was unnecessarily complex and PostreSQL’s
functions were better suited to “convert” from TEXT to IBAN or BIC.
The same is true for EMAIL and URI domains, so i changed their parameter
types to TEXT too.
Closes #54.
2023-07-02 00:08:45 +00:00
|
|
|
postgresql-15-vat,
|
|
|
|
|
postgresql-15-iban
|
2023-01-15 21:56:49 +00:00
|
|
|
Standards-Version: 4.6.0
|
|
|
|
|
XS-Go-Import-Path: dev.tandem.ws/tandem/numerus
|
|
|
|
|
Vcs-Browser: https://dev.tandem.ws/tandem/numerus
|
|
|
|
|
Vcs-Git: https://dev.tandem.ws/tandem/numerus.git
|
|
|
|
|
Homepage: https://dev.tandem.ws/tandem/numerus
|
|
|
|
|
Rules-Requires-Root: no
|
|
|
|
|
|
2023-01-16 12:22:16 +00:00
|
|
|
Package: golang-tandem-numerus-dev
|
|
|
|
|
Architecture: all
|
|
|
|
|
Pre-Depends: ${misc:Pre-Depends}
|
|
|
|
|
Depends:
|
|
|
|
|
${misc:Depends},
|
|
|
|
|
golang-github-jackc-pgx-v4-dev
|
|
|
|
|
Description: Simple invoicing and accounting web application
|
2023-02-26 16:10:26 +00:00
|
|
|
A simple web application to keep invoice and accounting records, intended for
|
2023-01-19 00:41:27 +00:00
|
|
|
freelancers working in Spain.
|
2023-01-16 12:22:16 +00:00
|
|
|
.
|
|
|
|
|
This is the dev package.
|
|
|
|
|
|
2023-01-15 21:56:49 +00:00
|
|
|
Package: numerus
|
|
|
|
|
Architecture: any
|
|
|
|
|
Depends:
|
2023-01-16 12:22:16 +00:00
|
|
|
${shlibs:Depends},
|
Convert invoices to PDF with WeasyPrint
Although it is possible to just print the invoice from the browser, many
people will not even try an assume that they can not create a PDF for
the invoice.
I thought of using Groff or TeX to create the PDF, but it would mean
maintaining two templates in two different systems (HTML and whatever i
would use), and would probably look very different, because i do not
know Groff or TeX that well.
I wish there was a way to tell the browser to print to PDF, and it can
be done, but only with the Chrome Protocol to a server-side running
Chrome instance. This works, but i would need a Chrome running as a
daemon.
I also wrote a Qt application that uses QWebEngine to print the PDF,
much like wkhtmltopdf, but with support for more recent HTML and CSS
standards. Unfortunately, Qt 6.4’s embedded Chromium does not follow
break-page-inside as well as WeasyPrint does.
To use WeasyPrint, at first i wanted to reach the same URL as the user,
passing the cookie to WeasyPrint so that i can access the same invoice
as the user, something that can be done with wkhtmltopdf, but WeasyPrint
does not have such option. I did it with a custom Python script, but
then i need to package and install that script, that is not that much
work, but using the Debian-provided script is even less work, and less
likely to drift when WeasyPrint changes API.
Also, it is unnecessary to do a network round-trip from Go to Python
back to Go, because i can already write the invoice HTML as is to
WeasyPrint’s stdin.
2023-02-26 16:26:09 +00:00
|
|
|
${misc:Depends},
|
|
|
|
|
weasyprint
|
2023-01-16 12:22:16 +00:00
|
|
|
Built-Using: ${misc:Built-Using}
|
|
|
|
|
Description: Simple invoicing and accounting web application
|
|
|
|
|
A simple web application to keep invoice and accouting records, intended for
|
2023-01-19 00:41:27 +00:00
|
|
|
freelancers working in Spain.
|
2023-01-16 12:22:16 +00:00
|
|
|
|
|
|
|
|
Package: numerus-sqitch
|
|
|
|
|
Architecture: all
|
|
|
|
|
Depends:
|
|
|
|
|
${misc:Depends},
|
2023-06-15 10:19:08 +00:00
|
|
|
postgresql-15-pg-libphonenumber,
|
|
|
|
|
postgresql-15-pguri,
|
|
|
|
|
postgresql-15-vat,
|
Add IBAN and BIC fields to contacts
These two fields are just for information purposes, as Numerus does not
have any way to wire transfer using these, but people might want to keep
these in the contact’s info as a convenience.
Since not every contact should have an IBAN, e.g., customers, and inside
SEPA (European Union and some more countries) the BIC is not required,
they are in two different relations in order to be optional without
using NULL.
For the IBAN i found an already made PostgreSQL module, but for BIC i
had to write a regular expression based on the information i gathered
from Wikipedia, because the ISO standard is not free.
These two parameters for the add_contact and edit_contact functions are
TEXT because i realized that these functions are intended to be used
from the web application, that only deals with texts, so the
ValueOrNil() function was unnecessarily complex and PostreSQL’s
functions were better suited to “convert” from TEXT to IBAN or BIC.
The same is true for EMAIL and URI domains, so i changed their parameter
types to TEXT too.
Closes #54.
2023-07-02 00:08:45 +00:00
|
|
|
postgresql-15-iban,
|
2023-01-16 12:22:16 +00:00
|
|
|
sqitch
|
2023-01-15 21:56:49 +00:00
|
|
|
Description: Simple invoicing and accounting web application
|
|
|
|
|
A simple web application to keep invoice and accouting records, intended for
|
2023-01-19 00:41:27 +00:00
|
|
|
freelancers working in Spain.
|
2023-01-16 12:22:16 +00:00
|
|
|
.
|
|
|
|
|
This is the Sqitch migration package.
|
2023-01-17 21:30:01 +00:00
|
|
|
|
|
|
|
|
Package: numerus-demo
|
|
|
|
|
Architecture: all
|
|
|
|
|
Depends:
|
|
|
|
|
${misc:Depends},
|
|
|
|
|
sqitch
|
|
|
|
|
Description: Simple invoicing and accounting web application
|
|
|
|
|
A simple web application to keep invoice and accouting records, intended for
|
2023-01-19 00:41:27 +00:00
|
|
|
freelancers working in Spain.
|
2023-01-17 21:30:01 +00:00
|
|
|
.
|
Add Catalan and Spanish translation with gotext[3]
I had to choose between [1], [2], and [3].
As far as i could find, [1] is not easy to work with templates[4] and at
the moment is not maintained[5].
Both [2] and [3] use the same approach to be used from within templates:
you have to define a FuncMap with template functions that call the
message catalog. Also, both libraries seems to be reasonably
maintained, and have packages in Debian’s repository.
However, [2] repeats the same mistakes that POSIX did with its
catalogs—using identifiers that are not the strings in the source
language—, however this time the catalogs are written in JSON or YAML!
This, somehow, makes things worse….
[3], the one i settled with, is fine and decently maintained. There are
some surprising things, such as to be able to use directly the PO file,
and that it has higher priority over the corresponding MO, or that the
order of parameters is reversed in respect to gettext. However, it uses
a saner format, and is a lot easier to work with than [3].
The problem, of course, is that xgettext does not know how to find
translatable strings inside the template. [3] includes a CLI tool
similar to xgettext, but is not a drop-in replacement[6] and does not
process templates.
The proper way to handle this would be to add a parser to xgettext, but
for now i found out that if i surround the call to the translation
functions from within the template with parentheses, i can trick
xgettext into believing it is parsing Scheme code, and extracts the
strings successfully—at least, for what i have tried. Had to add the
keyword for pgettext, because Schemed does not have it, but at least i
can do that with command line parameters.
For now i left only Spanish and Catalan as the two available languages,
even though the source text is written in English, because that way i
can make sure i do not leave strings untranslated.
[1]: https://golang.org/x/text
[2]: https://github.com/nicksnyder/go-i18n
[3]: https://github.com/leonelquinteros/gotext
[4]: https://github.com/golang/go/issues/39954
[5]: https://github.com/golang/go/issues/12750
[6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
|
|
|
This is the demo package.
|