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
|
|
|
|
# Catalan translations for numerus package
|
|
|
|
|
# Traduccions al català del paquet «numerus».
|
|
|
|
|
# Copyright (C) 2023 jordi fita mas
|
|
|
|
|
# This file is distributed under the same license as the numerus package.
|
|
|
|
|
# jordi fita mas <jordi@tandem.blog>, 2023.
|
|
|
|
|
#
|
|
|
|
|
msgid ""
|
|
|
|
|
msgstr ""
|
|
|
|
|
"Project-Id-Version: numerus\n"
|
|
|
|
|
"Report-Msgid-Bugs-To: jordi@tandem.blog\n"
|
2024-08-11 22:08:18 +00:00
|
|
|
|
"POT-Creation-Date: 2024-08-12 00:06+0200\n"
|
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
|
|
|
|
"PO-Revision-Date: 2023-01-18 17:08+0100\n"
|
|
|
|
|
"Last-Translator: jordi fita mas <jordi@tandem.blog>\n"
|
|
|
|
|
"Language-Team: Catalan <ca@dodds.net>\n"
|
|
|
|
|
"Language: ca\n"
|
|
|
|
|
"MIME-Version: 1.0\n"
|
|
|
|
|
"Content-Type: text/plain; charset=UTF-8\n"
|
|
|
|
|
"Content-Transfer-Encoding: 8bit\n"
|
|
|
|
|
|
2023-02-12 20:06:48 +00:00
|
|
|
|
#: web/template/invoices/products.gohtml:2
|
2023-03-21 10:58:54 +00:00
|
|
|
|
#: web/template/invoices/products.gohtml:23
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Add Products to Invoice"
|
|
|
|
|
msgstr "Afegeix productes a la factura"
|
|
|
|
|
|
|
|
|
|
#: web/template/invoices/products.gohtml:9 web/template/invoices/new.gohtml:9
|
2023-03-21 10:58:54 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:9 web/template/invoices/view.gohtml:9
|
2023-06-11 20:24:25 +00:00
|
|
|
|
#: web/template/invoices/edit.gohtml:9 web/template/home.gohtml:2
|
2023-11-06 12:52:34 +00:00
|
|
|
|
#: web/template/switch-company.gohtml:9 web/template/quotes/products.gohtml:9
|
|
|
|
|
#: web/template/quotes/new.gohtml:9 web/template/quotes/index.gohtml:9
|
|
|
|
|
#: web/template/quotes/view.gohtml:9 web/template/quotes/edit.gohtml:9
|
|
|
|
|
#: web/template/contacts/new.gohtml:9 web/template/contacts/index.gohtml:9
|
|
|
|
|
#: web/template/contacts/edit.gohtml:10 web/template/contacts/import.gohtml:8
|
|
|
|
|
#: web/template/profile.gohtml:9 web/template/expenses/new.gohtml:10
|
|
|
|
|
#: web/template/expenses/index.gohtml:10 web/template/expenses/edit.gohtml:10
|
|
|
|
|
#: web/template/tax-details.gohtml:9 web/template/products/new.gohtml:9
|
|
|
|
|
#: web/template/products/index.gohtml:9 web/template/products/edit.gohtml:10
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: web/template/payments/new.gohtml:10 web/template/payments/index.gohtml:10
|
|
|
|
|
#: web/template/payments/edit.gohtml:10
|
|
|
|
|
#: web/template/payments/accounts/new.gohtml:10
|
|
|
|
|
#: web/template/payments/accounts/index.gohtml:10
|
|
|
|
|
#: web/template/payments/accounts/edit.gohtml:10
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Home"
|
|
|
|
|
msgstr "Inici"
|
|
|
|
|
|
|
|
|
|
#: web/template/invoices/products.gohtml:10 web/template/invoices/new.gohtml:10
|
2023-03-21 10:58:54 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:2 web/template/invoices/index.gohtml:10
|
2023-03-13 14:00:35 +00:00
|
|
|
|
#: web/template/invoices/view.gohtml:10 web/template/invoices/edit.gohtml:10
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Invoices"
|
|
|
|
|
msgstr "Factures"
|
|
|
|
|
|
2023-03-13 14:00:35 +00:00
|
|
|
|
#: web/template/invoices/products.gohtml:12 web/template/invoices/new.gohtml:2
|
2023-03-21 10:58:54 +00:00
|
|
|
|
#: web/template/invoices/new.gohtml:11 web/template/invoices/new.gohtml:19
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "New Invoice"
|
|
|
|
|
msgstr "Nova factura"
|
|
|
|
|
|
2023-04-27 22:06:48 +00:00
|
|
|
|
#: web/template/invoices/products.gohtml:48
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/quotes/products.gohtml:48
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "product"
|
|
|
|
|
msgid "All"
|
|
|
|
|
msgstr "Tots"
|
|
|
|
|
|
2023-04-27 22:06:48 +00:00
|
|
|
|
#: web/template/invoices/products.gohtml:49
|
2023-11-06 12:52:34 +00:00
|
|
|
|
#: web/template/switch-company.gohtml:22 web/template/quotes/products.gohtml:49
|
|
|
|
|
#: web/template/products/index.gohtml:45
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: web/template/payments/accounts/index.gohtml:25
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Name"
|
|
|
|
|
msgstr "Nom"
|
|
|
|
|
|
2023-04-27 22:06:48 +00:00
|
|
|
|
#: web/template/invoices/products.gohtml:50
|
2023-07-12 18:06:53 +00:00
|
|
|
|
#: web/template/invoices/view.gohtml:66 web/template/quotes/products.gohtml:50
|
2023-07-16 18:56:11 +00:00
|
|
|
|
#: web/template/quotes/view.gohtml:73 web/template/products/index.gohtml:47
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Price"
|
|
|
|
|
msgstr "Preu"
|
|
|
|
|
|
2023-04-27 22:06:48 +00:00
|
|
|
|
#: web/template/invoices/products.gohtml:64
|
2023-07-16 18:56:11 +00:00
|
|
|
|
#: web/template/quotes/products.gohtml:64 web/template/products/index.gohtml:88
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgid "No products added yet."
|
|
|
|
|
msgstr "No hi ha cap producte."
|
|
|
|
|
|
2023-07-12 18:06:53 +00:00
|
|
|
|
#: web/template/invoices/products.gohtml:72 web/template/invoices/new.gohtml:88
|
|
|
|
|
#: web/template/invoices/edit.gohtml:89 web/template/quotes/products.gohtml:72
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/quotes/new.gohtml:88 web/template/quotes/edit.gohtml:89
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Add products"
|
|
|
|
|
msgstr "Afegeix productes"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/invoices/new.gohtml:30 web/template/invoices/edit.gohtml:30
|
|
|
|
|
#: web/template/quotes/new.gohtml:30 web/template/quotes/edit.gohtml:30
|
2023-05-28 22:02:55 +00:00
|
|
|
|
msgid "Product “%s” removed"
|
|
|
|
|
msgstr "S’ha esborrat el producte «%s»"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/invoices/new.gohtml:34 web/template/invoices/edit.gohtml:34
|
|
|
|
|
#: web/template/quotes/new.gohtml:34 web/template/quotes/edit.gohtml:34
|
2023-05-28 22:02:55 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Undo"
|
|
|
|
|
msgstr "Desfes"
|
|
|
|
|
|
2023-07-12 18:06:53 +00:00
|
|
|
|
#: web/template/invoices/new.gohtml:64 web/template/invoices/view.gohtml:71
|
|
|
|
|
#: web/template/invoices/edit.gohtml:65 web/template/quotes/new.gohtml:64
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/quotes/view.gohtml:78 web/template/quotes/edit.gohtml:65
|
2023-02-24 11:22:15 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Subtotal"
|
|
|
|
|
msgstr "Subtotal"
|
|
|
|
|
|
2023-07-12 18:06:53 +00:00
|
|
|
|
#: web/template/invoices/new.gohtml:74 web/template/invoices/view.gohtml:75
|
|
|
|
|
#: web/template/invoices/view.gohtml:115 web/template/invoices/edit.gohtml:75
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/quotes/new.gohtml:74 web/template/quotes/view.gohtml:82
|
|
|
|
|
#: web/template/quotes/view.gohtml:122 web/template/quotes/edit.gohtml:75
|
2023-10-02 10:16:50 +00:00
|
|
|
|
#: web/template/expenses/new.gohtml:47 web/template/expenses/index.gohtml:74
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: web/template/expenses/edit.gohtml:49 web/template/payments/index.gohtml:29
|
2023-02-24 11:22:15 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Total"
|
|
|
|
|
msgstr "Total"
|
|
|
|
|
|
2023-07-12 18:06:53 +00:00
|
|
|
|
#: web/template/invoices/new.gohtml:92 web/template/invoices/edit.gohtml:93
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/quotes/new.gohtml:92 web/template/quotes/edit.gohtml:93
|
2023-07-16 18:56:11 +00:00
|
|
|
|
#: web/template/expenses/new.gohtml:57 web/template/expenses/edit.gohtml:59
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: web/template/payments/edit.gohtml:37
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: web/template/payments/accounts/edit.gohtml:38
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Update"
|
|
|
|
|
msgstr "Actualitza"
|
|
|
|
|
|
2023-07-12 18:06:53 +00:00
|
|
|
|
#: web/template/invoices/new.gohtml:95 web/template/invoices/edit.gohtml:96
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/quotes/new.gohtml:95 web/template/quotes/edit.gohtml:96
|
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
|
|
|
|
#: web/template/contacts/new.gohtml:49 web/template/contacts/edit.gohtml:53
|
2023-07-16 18:56:11 +00:00
|
|
|
|
#: web/template/expenses/new.gohtml:60 web/template/expenses/edit.gohtml:62
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/products/new.gohtml:30 web/template/products/edit.gohtml:36
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: web/template/payments/new.gohtml:35
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: web/template/payments/accounts/new.gohtml:41
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "action"
|
2023-05-26 11:38:04 +00:00
|
|
|
|
msgid "Save"
|
|
|
|
|
msgstr "Desa"
|
2023-02-12 20:06:48 +00:00
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:28
|
2023-03-09 11:11:53 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Download invoices"
|
|
|
|
|
msgstr "Descarrega factures"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:31 web/template/quotes/index.gohtml:31
|
|
|
|
|
#: web/template/expenses/index.gohtml:29
|
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Export list"
|
|
|
|
|
msgstr "Exporta llistat"
|
|
|
|
|
|
|
|
|
|
#: web/template/invoices/index.gohtml:33
|
2023-05-26 11:38:04 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "New invoice"
|
|
|
|
|
msgstr "Nova factura"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:57 web/template/dashboard.gohtml:23
|
|
|
|
|
#: web/template/quotes/index.gohtml:57 web/template/contacts/index.gohtml:38
|
|
|
|
|
#: web/template/expenses/index.gohtml:56 web/template/products/index.gohtml:36
|
Add filters form for invoices
Instead of using links in the invoice tags, that we will replace with a
“click-to-edit field”, with Oriol agreed to add a form with filters that
includes not only the tags but also dates, customer, status, and the
invoice number.
This means i now need dynamic SQL, and i do not think this belongs to
the database (i.e., no PL/pgSQL function for that). I have looked at
query builder libraries for Golang, and did not find anything that
suited me: either they wanted to manage not only the SQL query but also
all structs, or they managed to confuse Goland’s SQL analyzer.
For now, at least, i am using a very simple approach with arrays, that
still confuses Goland’s analyzer, but just in a very specific part,
which i find tolerable—not that their analyzer is that great to begin
with, but that’s a story for another day.
2023-03-29 14:16:31 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Filter"
|
|
|
|
|
msgstr "Filtra"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:60 web/template/quotes/index.gohtml:60
|
|
|
|
|
#: web/template/contacts/index.gohtml:41 web/template/expenses/index.gohtml:59
|
2023-07-16 18:56:11 +00:00
|
|
|
|
#: web/template/products/index.gohtml:39
|
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Reset"
|
|
|
|
|
msgstr "Restableix"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:66
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "invoice"
|
|
|
|
|
msgid "All"
|
|
|
|
|
msgstr "Totes"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:67 web/template/invoices/view.gohtml:38
|
|
|
|
|
#: web/template/quotes/index.gohtml:67 web/template/quotes/view.gohtml:37
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Date"
|
|
|
|
|
msgstr "Data"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:68
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Invoice Num."
|
|
|
|
|
msgstr "Núm. factura"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:69 web/template/quotes/index.gohtml:69
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
2023-06-20 09:33:28 +00:00
|
|
|
|
msgid "Customer"
|
|
|
|
|
msgstr "Client"
|
2023-02-12 20:06:48 +00:00
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:70 web/template/quotes/index.gohtml:70
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: web/template/expenses/index.gohtml:68 web/template/payments/index.gohtml:27
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Status"
|
|
|
|
|
msgstr "Estat"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:71 web/template/quotes/index.gohtml:71
|
|
|
|
|
#: web/template/contacts/index.gohtml:50 web/template/expenses/index.gohtml:69
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: web/template/products/index.gohtml:46 web/template/payments/index.gohtml:28
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
2023-03-10 13:02:55 +00:00
|
|
|
|
msgid "Tags"
|
|
|
|
|
msgstr "Etiquetes"
|
2023-02-12 20:06:48 +00:00
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:72 web/template/quotes/index.gohtml:72
|
|
|
|
|
#: web/template/expenses/index.gohtml:70
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
2023-02-22 13:39:38 +00:00
|
|
|
|
msgid "Amount"
|
|
|
|
|
msgstr "Import"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:73 web/template/quotes/index.gohtml:73
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: web/template/expenses/index.gohtml:75 web/template/payments/index.gohtml:30
|
2023-02-22 13:39:38 +00:00
|
|
|
|
msgctxt "title"
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgid "Download"
|
|
|
|
|
msgstr "Descàrrega"
|
|
|
|
|
|
2023-11-06 12:52:34 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:74 web/template/switch-company.gohtml:23
|
|
|
|
|
#: web/template/quotes/index.gohtml:74 web/template/contacts/index.gohtml:51
|
|
|
|
|
#: web/template/expenses/index.gohtml:76 web/template/products/index.gohtml:48
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: web/template/payments/index.gohtml:31
|
2023-03-08 10:54:06 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Actions"
|
|
|
|
|
msgstr "Accions"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:81
|
2023-03-09 11:11:53 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Select invoice %v"
|
|
|
|
|
msgstr "Selecciona factura %v"
|
|
|
|
|
|
2023-11-06 12:52:34 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:123
|
2023-07-06 09:49:36 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Download invoice %s"
|
|
|
|
|
msgstr "Descarrega factura %s"
|
|
|
|
|
|
2023-11-06 12:52:34 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:131
|
2023-07-06 09:49:36 +00:00
|
|
|
|
msgid "Actions for invoice %s"
|
|
|
|
|
msgstr "Accions per la factura %s"
|
|
|
|
|
|
2023-11-06 12:52:34 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:139 web/template/invoices/view.gohtml:19
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/quotes/index.gohtml:137 web/template/quotes/view.gohtml:22
|
2023-10-02 10:16:50 +00:00
|
|
|
|
#: web/template/contacts/index.gohtml:82 web/template/expenses/index.gohtml:143
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: web/template/products/index.gohtml:78 web/template/payments/index.gohtml:71
|
2023-03-13 14:00:35 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Edit"
|
|
|
|
|
msgstr "Edita"
|
|
|
|
|
|
2023-11-06 12:52:34 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:147 web/template/invoices/view.gohtml:16
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/quotes/index.gohtml:145 web/template/quotes/view.gohtml:19
|
2023-03-08 10:54:06 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Duplicate"
|
|
|
|
|
msgstr "Duplica"
|
|
|
|
|
|
2023-11-06 12:52:34 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:157
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgid "No invoices added yet."
|
|
|
|
|
msgstr "No hi ha cap factura."
|
|
|
|
|
|
2023-11-06 12:52:34 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:164 web/template/quotes/index.gohtml:170
|
2023-10-02 10:16:50 +00:00
|
|
|
|
#: web/template/expenses/index.gohtml:160
|
2023-06-20 09:33:28 +00:00
|
|
|
|
msgid "Total"
|
|
|
|
|
msgstr "Total"
|
|
|
|
|
|
2023-07-12 18:06:53 +00:00
|
|
|
|
#: web/template/invoices/view.gohtml:2 web/template/invoices/view.gohtml:37
|
2023-02-24 11:22:15 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Invoice %s"
|
|
|
|
|
msgstr "Factura %s"
|
|
|
|
|
|
2023-04-15 02:05:59 +00:00
|
|
|
|
#: web/template/invoices/view.gohtml:22
|
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
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Download invoice"
|
|
|
|
|
msgstr "Descarrega factura"
|
|
|
|
|
|
2023-07-12 18:06:53 +00:00
|
|
|
|
#: web/template/invoices/view.gohtml:25
|
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Download invoice attachment"
|
|
|
|
|
msgstr "Descarrega l’adjunt de la factura"
|
|
|
|
|
|
|
|
|
|
#: web/template/invoices/view.gohtml:65 web/template/quotes/view.gohtml:72
|
2023-02-24 11:22:15 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Concept"
|
|
|
|
|
msgstr "Concepte"
|
|
|
|
|
|
2023-07-12 18:06:53 +00:00
|
|
|
|
#: web/template/invoices/view.gohtml:68 web/template/quotes/view.gohtml:75
|
2023-03-01 13:08:12 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Discount"
|
|
|
|
|
msgstr "Descompte"
|
|
|
|
|
|
2023-07-12 18:06:53 +00:00
|
|
|
|
#: web/template/invoices/view.gohtml:70 web/template/quotes/view.gohtml:77
|
2023-02-24 11:22:15 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Units"
|
|
|
|
|
msgstr "Unitats"
|
|
|
|
|
|
2023-07-12 18:06:53 +00:00
|
|
|
|
#: web/template/invoices/view.gohtml:105 web/template/quotes/view.gohtml:112
|
2023-03-01 13:08:12 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Tax Base"
|
|
|
|
|
msgstr "Base imposable"
|
|
|
|
|
|
2023-03-21 10:58:54 +00:00
|
|
|
|
#: web/template/invoices/edit.gohtml:2 web/template/invoices/edit.gohtml:19
|
2023-03-13 14:00:35 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Edit Invoice “%s”"
|
|
|
|
|
msgstr "Edició de la factura «%s»"
|
|
|
|
|
|
2024-01-26 01:29:51 +00:00
|
|
|
|
#: web/template/web.gohtml:15
|
2024-01-19 22:05:01 +00:00
|
|
|
|
msgctxt "link"
|
|
|
|
|
msgid "Login"
|
|
|
|
|
msgstr "Entrada"
|
|
|
|
|
|
2024-01-26 01:29:51 +00:00
|
|
|
|
#: web/template/web.gohtml:16
|
2024-01-19 22:05:01 +00:00
|
|
|
|
msgctxt "link"
|
|
|
|
|
msgid "Demo"
|
|
|
|
|
msgstr "Demo"
|
|
|
|
|
|
2024-01-26 01:29:51 +00:00
|
|
|
|
#: web/template/web.gohtml:17
|
2024-01-19 22:05:01 +00:00
|
|
|
|
msgctxt "link"
|
|
|
|
|
msgid "Code"
|
|
|
|
|
msgstr "Codi"
|
|
|
|
|
|
2024-01-26 01:29:51 +00:00
|
|
|
|
#: web/template/web.gohtml:28 web/template/legal.gohtml:2
|
2024-01-19 22:05:01 +00:00
|
|
|
|
#: web/template/legal.gohtml:7
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Legal Disclaimer"
|
|
|
|
|
msgstr "Avís legal"
|
|
|
|
|
|
2024-01-26 01:29:51 +00:00
|
|
|
|
#: web/template/web.gohtml:29 web/template/privacy.gohtml:2
|
2024-01-19 22:05:01 +00:00
|
|
|
|
#: web/template/privacy.gohtml:7
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Privacy Policy"
|
|
|
|
|
msgstr "Política de privacitat"
|
|
|
|
|
|
2024-01-26 01:29:51 +00:00
|
|
|
|
#: web/template/web.gohtml:30 web/template/cookies.gohtml:2
|
2024-01-19 22:05:01 +00:00
|
|
|
|
#: web/template/cookies.gohtml:7
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Cookies Policy"
|
|
|
|
|
msgstr "Política de cookies"
|
|
|
|
|
|
2023-05-16 12:56:49 +00:00
|
|
|
|
#: web/template/form.gohtml:36
|
2023-05-17 10:05:30 +00:00
|
|
|
|
msgctxt "input"
|
2023-05-16 12:56:49 +00:00
|
|
|
|
msgid "(Max. %s)"
|
|
|
|
|
msgstr "(Màx. %s)"
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: web/template/form.gohtml:202
|
2023-05-26 11:38:04 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Filters"
|
|
|
|
|
msgstr "Filtra"
|
|
|
|
|
|
2023-11-06 12:52:34 +00:00
|
|
|
|
#: web/template/switch-company.gohtml:2 web/template/switch-company.gohtml:10
|
|
|
|
|
#: web/template/switch-company.gohtml:18
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Company Switch"
|
|
|
|
|
msgstr "Canvi d’empresa"
|
|
|
|
|
|
|
|
|
|
#: web/template/switch-company.gohtml:30
|
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Switch"
|
|
|
|
|
msgstr "Canvia"
|
|
|
|
|
|
2023-05-16 12:56:49 +00:00
|
|
|
|
#: web/template/dashboard.gohtml:3
|
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
|
|
|
|
msgctxt "title"
|
2023-01-31 12:07:17 +00:00
|
|
|
|
msgid "Dashboard"
|
|
|
|
|
msgstr "Tauler"
|
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
|
|
|
|
|
2024-01-19 19:03:04 +00:00
|
|
|
|
#: web/template/dashboard.gohtml:31
|
2023-05-16 12:56:49 +00:00
|
|
|
|
msgctxt "term"
|
|
|
|
|
msgid "Income"
|
|
|
|
|
msgstr "Ingressos"
|
|
|
|
|
|
2024-01-19 19:03:04 +00:00
|
|
|
|
#: web/template/dashboard.gohtml:35
|
2023-05-16 12:56:49 +00:00
|
|
|
|
msgctxt "term"
|
|
|
|
|
msgid "Expenses"
|
|
|
|
|
msgstr "Despeses"
|
|
|
|
|
|
2024-01-19 19:03:04 +00:00
|
|
|
|
#: web/template/dashboard.gohtml:39
|
2023-05-16 12:56:49 +00:00
|
|
|
|
msgctxt "term"
|
|
|
|
|
msgid "VAT"
|
|
|
|
|
msgstr "IVA"
|
|
|
|
|
|
2024-01-19 19:03:04 +00:00
|
|
|
|
#: web/template/dashboard.gohtml:43
|
2023-05-16 12:56:49 +00:00
|
|
|
|
msgctxt "term"
|
|
|
|
|
msgid "IRPF"
|
|
|
|
|
msgstr "IRPF"
|
|
|
|
|
|
2024-01-19 19:03:04 +00:00
|
|
|
|
#: web/template/dashboard.gohtml:47
|
2023-05-16 12:56:49 +00:00
|
|
|
|
msgctxt "term"
|
|
|
|
|
msgid "Net Income"
|
|
|
|
|
msgstr "Ingressos nets"
|
|
|
|
|
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/quotes/products.gohtml:2 web/template/quotes/products.gohtml:23
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Add Products to Quotation"
|
|
|
|
|
msgstr "Afegeix productes al pressupost"
|
|
|
|
|
|
|
|
|
|
#: web/template/quotes/products.gohtml:10 web/template/quotes/new.gohtml:10
|
|
|
|
|
#: web/template/quotes/index.gohtml:2 web/template/quotes/index.gohtml:10
|
|
|
|
|
#: web/template/quotes/view.gohtml:10 web/template/quotes/edit.gohtml:10
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Quotations"
|
|
|
|
|
msgstr "Pressuposts"
|
|
|
|
|
|
|
|
|
|
#: web/template/quotes/products.gohtml:12 web/template/quotes/new.gohtml:2
|
|
|
|
|
#: web/template/quotes/new.gohtml:11 web/template/quotes/new.gohtml:19
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "New Quotation"
|
|
|
|
|
msgstr "Nou pressupost"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/quotes/index.gohtml:28
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Download quotations"
|
|
|
|
|
msgstr "Descarrega pressuposts"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/quotes/index.gohtml:33
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "New quotation"
|
|
|
|
|
msgstr "Nou pressupost"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/quotes/index.gohtml:66
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "quote"
|
|
|
|
|
msgid "All"
|
|
|
|
|
msgstr "Tots"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/quotes/index.gohtml:68
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Quotation Num."
|
|
|
|
|
msgstr "Núm. pressupost"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/quotes/index.gohtml:81
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Select quotation %v"
|
|
|
|
|
msgstr "Selecciona pressupost %v"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/quotes/index.gohtml:129
|
2023-07-06 09:49:36 +00:00
|
|
|
|
msgid "Actions for quote %s"
|
|
|
|
|
msgstr "Accions pel pressupost %s"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/quotes/index.gohtml:153 web/template/quotes/view.gohtml:16
|
2023-06-10 18:46:03 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Create invoice"
|
|
|
|
|
msgstr "Crea factura"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/quotes/index.gohtml:163
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "No quotations added yet."
|
|
|
|
|
msgstr "No hi ha cap pressupost."
|
|
|
|
|
|
2023-06-10 18:46:03 +00:00
|
|
|
|
#: web/template/quotes/view.gohtml:2 web/template/quotes/view.gohtml:36
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Quotation %s"
|
|
|
|
|
msgstr "Pressupost %s"
|
|
|
|
|
|
2023-06-10 18:46:03 +00:00
|
|
|
|
#: web/template/quotes/view.gohtml:25
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Download quotation"
|
|
|
|
|
msgstr "Descarrega pressupost"
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: web/template/quotes/view.gohtml:65
|
Allow empty contact and payment method for quotes
I have to use a value to be used as “none” for payment method and
contact. In PL/pgSQL add_quote and edit_quote functions, that value is
NULL, while in forms it is the empty string. I can not simply pass the
empty string for either of these fields because PL/pgSQL expects
(nullable) integers, and "" is not a valid integer and is not NULL
either. A conversion is necessary.
Apparently, Go’s nil is not a valid representation for SQL’s NULL with
pgx, and had to use sql.NullString instead.
I also needed to coalesce contact’s VATIN and phone, because null values
can not be scanned to *string. I did not do that before because
`coalesce(vatin, '')` throws an error that '' is not a valid VATIN and
just left as is, wrongly expecting that pgx would do the job of leaving
the string blank for me. It does not.
Lastly, i can not blindly write Quotee’s tax details in the quote’s view
page, or we would see the (), characters for the empty address info.
2023-06-08 11:05:41 +00:00
|
|
|
|
msgid "Terms and Conditions:"
|
|
|
|
|
msgstr "Condicions d’acceptació:"
|
|
|
|
|
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/quotes/edit.gohtml:2 web/template/quotes/edit.gohtml:19
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Edit Quotation “%s”"
|
|
|
|
|
msgstr "Edició del pressupost «%s»"
|
|
|
|
|
|
2024-01-19 19:03:04 +00:00
|
|
|
|
#: web/template/app.gohtml:24
|
2023-01-30 15:48:21 +00:00
|
|
|
|
msgctxt "menu"
|
|
|
|
|
msgid "Account"
|
|
|
|
|
msgstr "Compte"
|
|
|
|
|
|
2024-01-19 19:03:04 +00:00
|
|
|
|
#: web/template/app.gohtml:30
|
2023-01-30 15:48:21 +00:00
|
|
|
|
msgctxt "menu"
|
|
|
|
|
msgid "Tax Details"
|
|
|
|
|
msgstr "Configuració fiscal"
|
|
|
|
|
|
2024-01-19 19:03:04 +00:00
|
|
|
|
#: web/template/app.gohtml:36
|
2023-11-06 12:52:34 +00:00
|
|
|
|
msgctxt "menu"
|
|
|
|
|
msgid "Switch Company"
|
|
|
|
|
msgstr "Canvi d’empresa"
|
|
|
|
|
|
2024-01-19 19:03:04 +00:00
|
|
|
|
#: web/template/app.gohtml:44
|
2023-01-30 15:48:21 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Logout"
|
|
|
|
|
msgstr "Surt"
|
|
|
|
|
|
2024-01-19 19:03:04 +00:00
|
|
|
|
#: web/template/app.gohtml:53
|
2023-01-30 15:48:21 +00:00
|
|
|
|
msgctxt "nav"
|
2023-01-31 12:29:56 +00:00
|
|
|
|
msgid "Dashboard"
|
|
|
|
|
msgstr "Tauler"
|
|
|
|
|
|
2024-01-19 19:03:04 +00:00
|
|
|
|
#: web/template/app.gohtml:54
|
2023-01-31 12:29:56 +00:00
|
|
|
|
msgctxt "nav"
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Quotations"
|
|
|
|
|
msgstr "Pressuposts"
|
|
|
|
|
|
2024-01-19 19:03:04 +00:00
|
|
|
|
#: web/template/app.gohtml:55
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "nav"
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgid "Invoices"
|
|
|
|
|
msgstr "Factures"
|
|
|
|
|
|
2024-01-19 19:03:04 +00:00
|
|
|
|
#: web/template/app.gohtml:56
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "nav"
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgid "Expenses"
|
|
|
|
|
msgstr "Despeses"
|
|
|
|
|
|
2024-01-19 19:03:04 +00:00
|
|
|
|
#: web/template/app.gohtml:57
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgctxt "nav"
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
msgid "Payments"
|
|
|
|
|
msgstr "Pagaments"
|
|
|
|
|
|
|
|
|
|
#: web/template/app.gohtml:58
|
|
|
|
|
msgctxt "nav"
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgid "Products"
|
|
|
|
|
msgstr "Productes"
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: web/template/app.gohtml:59
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "nav"
|
|
|
|
|
msgid "Contacts"
|
|
|
|
|
msgstr "Contactes"
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: web/template/app.gohtml:67
|
2024-01-19 19:03:04 +00:00
|
|
|
|
msgid "<a href=\"https://numerus.cat/\">Numerus</a> Version: %s"
|
|
|
|
|
msgstr "<a href=\"https://numerus.cat/\">Numerus</a> versió: %s"
|
|
|
|
|
|
2023-02-04 10:32:39 +00:00
|
|
|
|
#: web/template/contacts/new.gohtml:2 web/template/contacts/new.gohtml:11
|
2023-03-21 10:58:54 +00:00
|
|
|
|
#: web/template/contacts/new.gohtml:19
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "New Contact"
|
|
|
|
|
msgstr "Nou contacte"
|
|
|
|
|
|
|
|
|
|
#: web/template/contacts/new.gohtml:10 web/template/contacts/index.gohtml:2
|
2023-03-27 07:44:04 +00:00
|
|
|
|
#: web/template/contacts/index.gohtml:10 web/template/contacts/edit.gohtml:11
|
Allow importing contacts from Holded
This allows to import an Excel file exported from Holded, because it is
our own user case. When we have more customers, we will give out an
Excel template file to fill out.
Why XLSX files instead of CSV, for instance? First, because this is the
output from Holded, but even then we would have more trouble with CSV
than with XLSX because of Microsoft: they royally fucked up
interoperability when decided that CSV files, the files that only other
applications or programmers see, should be “localized”, and use a comma
or a **semicolon** to separate a **comma** separated file depending on
the locale’s decimal separator.
This is ridiculous because it means that CSV files created with an Excel
in USA uses comma while the same Excel but with a French locale expects
the fields to be separated by semicolon. And for no good reason,
either.
Since they fucked up so bad, decided to add a non-standard “meta” field
to specify the separator, writing a `sep=,` in the first line, but this
only works for reading, because saving the same file changes the
separator back to the locale-dependent character and removes the “meta”
field.
And since everyone expects to open spreadsheet with Excel, i can not
use CSV if i do not want a bunch of support tickets telling me that the
template is all in a single line.
I use an extremely old version of a xlsx reading library for golang[0]
because it is already available in Debian repositories, and the only
thing i want from it is to convert the convoluted XML file into a
string array.
Go is only responsible to read the file and dump its contents into a
temporary table, so that it can execute the PL/pgSQL function that will
actually move that data to the correct relations, much like add_contact
does but in batch.
In PostgreSQL version 16 they added a pg_input_is_valid function that
i would use to test whether input values really conform to domains,
but i will have to wait for Debian to pick up the new version.
Meanwhile, i use a couple of temporary functions, in lieu of nested
functions support in PostgreSQL.
Part of #45
[0]: https://github.com/tealeg/xlsx
2023-07-02 22:05:47 +00:00
|
|
|
|
#: web/template/contacts/import.gohtml:9
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "title"
|
2023-02-01 09:14:26 +00:00
|
|
|
|
msgid "Contacts"
|
|
|
|
|
msgstr "Contactes"
|
2023-01-30 15:48:21 +00:00
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/contacts/index.gohtml:15
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "action"
|
Allow importing contacts from Holded
This allows to import an Excel file exported from Holded, because it is
our own user case. When we have more customers, we will give out an
Excel template file to fill out.
Why XLSX files instead of CSV, for instance? First, because this is the
output from Holded, but even then we would have more trouble with CSV
than with XLSX because of Microsoft: they royally fucked up
interoperability when decided that CSV files, the files that only other
applications or programmers see, should be “localized”, and use a comma
or a **semicolon** to separate a **comma** separated file depending on
the locale’s decimal separator.
This is ridiculous because it means that CSV files created with an Excel
in USA uses comma while the same Excel but with a French locale expects
the fields to be separated by semicolon. And for no good reason,
either.
Since they fucked up so bad, decided to add a non-standard “meta” field
to specify the separator, writing a `sep=,` in the first line, but this
only works for reading, because saving the same file changes the
separator back to the locale-dependent character and removes the “meta”
field.
And since everyone expects to open spreadsheet with Excel, i can not
use CSV if i do not want a bunch of support tickets telling me that the
template is all in a single line.
I use an extremely old version of a xlsx reading library for golang[0]
because it is already available in Debian repositories, and the only
thing i want from it is to convert the convoluted XML file into a
string array.
Go is only responsible to read the file and dump its contents into a
temporary table, so that it can execute the PL/pgSQL function that will
actually move that data to the correct relations, much like add_contact
does but in batch.
In PostgreSQL version 16 they added a pg_input_is_valid function that
i would use to test whether input values really conform to domains,
but i will have to wait for Debian to pick up the new version.
Meanwhile, i use a couple of temporary functions, in lieu of nested
functions support in PostgreSQL.
Part of #45
[0]: https://github.com/tealeg/xlsx
2023-07-02 22:05:47 +00:00
|
|
|
|
msgid "Import"
|
|
|
|
|
msgstr "Importa"
|
|
|
|
|
|
|
|
|
|
#: web/template/contacts/index.gohtml:17
|
|
|
|
|
msgctxt "action"
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgid "New contact"
|
|
|
|
|
msgstr "Nou contacte"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/contacts/index.gohtml:47 web/template/expenses/index.gohtml:65
|
2023-06-20 09:33:28 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Contact"
|
|
|
|
|
msgstr "Contacte"
|
|
|
|
|
|
2023-07-16 18:56:11 +00:00
|
|
|
|
#: web/template/contacts/index.gohtml:48
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Email"
|
|
|
|
|
msgstr "Correu-e"
|
|
|
|
|
|
2023-07-16 18:56:11 +00:00
|
|
|
|
#: web/template/contacts/index.gohtml:49
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Phone"
|
|
|
|
|
msgstr "Telèfon"
|
|
|
|
|
|
2023-07-16 18:56:11 +00:00
|
|
|
|
#: web/template/contacts/index.gohtml:74
|
2023-07-06 09:49:36 +00:00
|
|
|
|
msgid "Actions for contact %s"
|
|
|
|
|
msgstr "Accions pel contacte %s"
|
|
|
|
|
|
2023-07-16 18:56:11 +00:00
|
|
|
|
#: web/template/contacts/index.gohtml:92
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgid "No contacts added yet."
|
|
|
|
|
msgstr "No hi ha cap contacte."
|
|
|
|
|
|
2023-03-27 07:44:04 +00:00
|
|
|
|
#: web/template/contacts/edit.gohtml:3 web/template/contacts/edit.gohtml:20
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Edit Contact “%s”"
|
|
|
|
|
msgstr "Edició del contacte «%s»"
|
|
|
|
|
|
Allow importing contacts from Holded
This allows to import an Excel file exported from Holded, because it is
our own user case. When we have more customers, we will give out an
Excel template file to fill out.
Why XLSX files instead of CSV, for instance? First, because this is the
output from Holded, but even then we would have more trouble with CSV
than with XLSX because of Microsoft: they royally fucked up
interoperability when decided that CSV files, the files that only other
applications or programmers see, should be “localized”, and use a comma
or a **semicolon** to separate a **comma** separated file depending on
the locale’s decimal separator.
This is ridiculous because it means that CSV files created with an Excel
in USA uses comma while the same Excel but with a French locale expects
the fields to be separated by semicolon. And for no good reason,
either.
Since they fucked up so bad, decided to add a non-standard “meta” field
to specify the separator, writing a `sep=,` in the first line, but this
only works for reading, because saving the same file changes the
separator back to the locale-dependent character and removes the “meta”
field.
And since everyone expects to open spreadsheet with Excel, i can not
use CSV if i do not want a bunch of support tickets telling me that the
template is all in a single line.
I use an extremely old version of a xlsx reading library for golang[0]
because it is already available in Debian repositories, and the only
thing i want from it is to convert the convoluted XML file into a
string array.
Go is only responsible to read the file and dump its contents into a
temporary table, so that it can execute the PL/pgSQL function that will
actually move that data to the correct relations, much like add_contact
does but in batch.
In PostgreSQL version 16 they added a pg_input_is_valid function that
i would use to test whether input values really conform to domains,
but i will have to wait for Debian to pick up the new version.
Meanwhile, i use a couple of temporary functions, in lieu of nested
functions support in PostgreSQL.
Part of #45
[0]: https://github.com/tealeg/xlsx
2023-07-02 22:05:47 +00:00
|
|
|
|
#: web/template/contacts/import.gohtml:2 web/template/contacts/import.gohtml:10
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Import Contacts"
|
|
|
|
|
msgstr "Importació de contactes"
|
|
|
|
|
|
2023-06-16 08:58:40 +00:00
|
|
|
|
#: web/template/login.gohtml:2 web/template/login.gohtml:15
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Login"
|
|
|
|
|
msgstr "Entrada"
|
|
|
|
|
|
2023-02-01 10:02:32 +00:00
|
|
|
|
#: web/template/login.gohtml:19
|
2023-01-30 15:48:21 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Login"
|
|
|
|
|
msgstr "Entra"
|
|
|
|
|
|
2023-02-03 12:58:10 +00:00
|
|
|
|
#: web/template/profile.gohtml:2 web/template/profile.gohtml:10
|
2023-03-21 10:58:54 +00:00
|
|
|
|
#: web/template/profile.gohtml:18
|
2023-01-30 15:48:21 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "User Settings"
|
|
|
|
|
msgstr "Configuració usuari"
|
|
|
|
|
|
2023-03-21 10:58:54 +00:00
|
|
|
|
#: web/template/profile.gohtml:22
|
2023-01-30 15:48:21 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "User Access Data"
|
|
|
|
|
msgstr "Dades accés usuari"
|
|
|
|
|
|
2023-03-21 10:58:54 +00:00
|
|
|
|
#: web/template/profile.gohtml:28
|
2023-01-30 15:48:21 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Password Change"
|
|
|
|
|
msgstr "Canvi contrasenya"
|
|
|
|
|
|
2023-03-21 10:58:54 +00:00
|
|
|
|
#: web/template/profile.gohtml:35
|
2023-01-31 14:40:12 +00:00
|
|
|
|
msgctxt "title"
|
2023-01-30 15:48:21 +00:00
|
|
|
|
msgid "Language"
|
|
|
|
|
msgstr "Idioma"
|
|
|
|
|
|
2023-06-09 10:43:50 +00:00
|
|
|
|
#: web/template/profile.gohtml:39 web/template/tax-details.gohtml:175
|
2023-01-30 15:48:21 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Save changes"
|
|
|
|
|
msgstr "Desa canvis"
|
|
|
|
|
|
2023-05-03 10:46:25 +00:00
|
|
|
|
#: web/template/expenses/new.gohtml:3 web/template/expenses/new.gohtml:12
|
|
|
|
|
#: web/template/expenses/new.gohtml:20
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "New Expense"
|
|
|
|
|
msgstr "Nova despesa"
|
|
|
|
|
|
|
|
|
|
#: web/template/expenses/new.gohtml:11 web/template/expenses/index.gohtml:3
|
|
|
|
|
#: web/template/expenses/index.gohtml:11 web/template/expenses/edit.gohtml:11
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Expenses"
|
|
|
|
|
msgstr "Despeses"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/expenses/index.gohtml:32
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "New expense"
|
|
|
|
|
msgstr "Nova despesa"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/expenses/index.gohtml:66
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Invoice Date"
|
|
|
|
|
msgstr "Data de factura"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: web/template/expenses/index.gohtml:67
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Invoice Number"
|
|
|
|
|
msgstr "Número de factura"
|
|
|
|
|
|
2023-10-02 10:16:50 +00:00
|
|
|
|
#: web/template/expenses/index.gohtml:135
|
2023-07-06 09:49:36 +00:00
|
|
|
|
msgid "Actions for expense %s"
|
|
|
|
|
msgstr "Accions per la despesa %s"
|
|
|
|
|
|
2023-10-02 10:16:50 +00:00
|
|
|
|
#: web/template/expenses/index.gohtml:153
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgid "No expenses added yet."
|
|
|
|
|
msgstr "No hi ha cap despesa."
|
|
|
|
|
|
|
|
|
|
#: web/template/expenses/edit.gohtml:3 web/template/expenses/edit.gohtml:20
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Edit Expense “%s”"
|
|
|
|
|
msgstr "Edició de la despesa «%s»"
|
|
|
|
|
|
2023-03-21 10:58:54 +00:00
|
|
|
|
#: web/template/tax-details.gohtml:2 web/template/tax-details.gohtml:10
|
|
|
|
|
#: web/template/tax-details.gohtml:18
|
2023-01-30 09:52:22 +00:00
|
|
|
|
msgctxt "title"
|
2023-01-30 15:48:21 +00:00
|
|
|
|
msgid "Tax Details"
|
|
|
|
|
msgstr "Configuració fiscal"
|
2023-01-30 09:52:22 +00:00
|
|
|
|
|
2023-03-21 10:58:54 +00:00
|
|
|
|
#: web/template/tax-details.gohtml:35
|
2023-02-03 12:29:10 +00:00
|
|
|
|
msgctxt "title"
|
2023-01-28 11:24:52 +00:00
|
|
|
|
msgid "Currency"
|
|
|
|
|
msgstr "Moneda"
|
|
|
|
|
|
2023-03-21 10:58:54 +00:00
|
|
|
|
#: web/template/tax-details.gohtml:41
|
2023-03-03 15:49:06 +00:00
|
|
|
|
msgctxt "title"
|
2023-06-09 10:43:50 +00:00
|
|
|
|
msgid "Invoicing and Quoting"
|
|
|
|
|
msgstr "Facturació i pressuposts"
|
2023-03-03 15:49:06 +00:00
|
|
|
|
|
2023-06-09 10:43:50 +00:00
|
|
|
|
#: web/template/tax-details.gohtml:56
|
2023-03-21 10:58:54 +00:00
|
|
|
|
msgid "Are you sure?"
|
|
|
|
|
msgstr "N’esteu segur?"
|
|
|
|
|
|
2023-06-09 10:43:50 +00:00
|
|
|
|
#: web/template/tax-details.gohtml:62
|
2023-01-28 13:18:58 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Tax Name"
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgstr "Nom impost"
|
2023-01-28 13:18:58 +00:00
|
|
|
|
|
2023-06-09 10:43:50 +00:00
|
|
|
|
#: web/template/tax-details.gohtml:63
|
2023-01-28 13:18:58 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Rate (%)"
|
|
|
|
|
msgstr "Percentatge"
|
|
|
|
|
|
2023-06-09 10:43:50 +00:00
|
|
|
|
#: web/template/tax-details.gohtml:64
|
2023-02-28 11:02:27 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Class"
|
|
|
|
|
msgstr "Classe"
|
|
|
|
|
|
2023-06-09 10:43:50 +00:00
|
|
|
|
#: web/template/tax-details.gohtml:88
|
2023-01-28 13:18:58 +00:00
|
|
|
|
msgid "No taxes added yet."
|
|
|
|
|
msgstr "No hi ha cap impost."
|
|
|
|
|
|
2023-06-09 10:43:50 +00:00
|
|
|
|
#: web/template/tax-details.gohtml:94 web/template/tax-details.gohtml:155
|
2023-01-28 13:18:58 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "New Line"
|
|
|
|
|
msgstr "Nova línia"
|
|
|
|
|
|
2023-06-09 10:43:50 +00:00
|
|
|
|
#: web/template/tax-details.gohtml:108
|
2023-01-28 13:18:58 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Add new tax"
|
|
|
|
|
msgstr "Afegeix nou impost"
|
|
|
|
|
|
2023-06-09 10:43:50 +00:00
|
|
|
|
#: web/template/tax-details.gohtml:124
|
2023-03-03 15:49:06 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Payment Method"
|
|
|
|
|
msgstr "Mètode de pagament"
|
|
|
|
|
|
2023-06-09 10:43:50 +00:00
|
|
|
|
#: web/template/tax-details.gohtml:125
|
2023-03-03 15:49:06 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Instructions"
|
|
|
|
|
msgstr "Instruccions"
|
|
|
|
|
|
2023-06-09 10:43:50 +00:00
|
|
|
|
#: web/template/tax-details.gohtml:149
|
2023-03-03 15:49:06 +00:00
|
|
|
|
msgid "No payment methods added yet."
|
|
|
|
|
msgstr "No hi ha cap mètode de pagament."
|
|
|
|
|
|
2023-06-09 10:43:50 +00:00
|
|
|
|
#: web/template/tax-details.gohtml:167
|
2023-03-03 15:49:06 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Add new payment method"
|
|
|
|
|
msgstr "Afegeix nou mètode de pagament"
|
|
|
|
|
|
2023-02-04 10:32:39 +00:00
|
|
|
|
#: web/template/products/new.gohtml:2 web/template/products/new.gohtml:11
|
2023-03-21 10:58:54 +00:00
|
|
|
|
#: web/template/products/new.gohtml:19
|
2023-01-30 15:48:21 +00:00
|
|
|
|
msgctxt "title"
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgid "New Product"
|
|
|
|
|
msgstr "Nou producte"
|
|
|
|
|
|
|
|
|
|
#: web/template/products/new.gohtml:10 web/template/products/index.gohtml:2
|
2023-03-27 07:44:04 +00:00
|
|
|
|
#: web/template/products/index.gohtml:10 web/template/products/edit.gohtml:11
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Products"
|
|
|
|
|
msgstr "Productes"
|
|
|
|
|
|
2023-04-27 22:06:48 +00:00
|
|
|
|
#: web/template/products/search.gohtml:12
|
|
|
|
|
msgid "No products found."
|
|
|
|
|
msgstr "No s’ha trobat cap producte."
|
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/products/index.gohtml:15
|
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "New product"
|
|
|
|
|
msgstr "Nou producte"
|
|
|
|
|
|
2023-07-16 18:56:11 +00:00
|
|
|
|
#: web/template/products/index.gohtml:70
|
2023-07-06 09:49:36 +00:00
|
|
|
|
msgid "Actions for product %s"
|
|
|
|
|
msgstr "Accions pel producte %s"
|
|
|
|
|
|
2023-03-27 07:44:04 +00:00
|
|
|
|
#: web/template/products/edit.gohtml:3 web/template/products/edit.gohtml:20
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Edit Product “%s”"
|
|
|
|
|
msgstr "Edició del producte «%s»"
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: web/template/payments/new.gohtml:3 web/template/payments/new.gohtml:12
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "New Payment"
|
|
|
|
|
msgstr "Nou pagament"
|
|
|
|
|
|
|
|
|
|
#: web/template/payments/new.gohtml:11 web/template/payments/index.gohtml:3
|
|
|
|
|
#: web/template/payments/index.gohtml:11 web/template/payments/edit.gohtml:11
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Payments"
|
|
|
|
|
msgstr "Pagaments"
|
|
|
|
|
|
|
|
|
|
#: web/template/payments/index.gohtml:16
|
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "New payment"
|
|
|
|
|
msgstr "Nou pagament"
|
|
|
|
|
|
|
|
|
|
#: web/template/payments/index.gohtml:25
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Payment Date"
|
|
|
|
|
msgstr "Data del pagament"
|
|
|
|
|
|
|
|
|
|
#: web/template/payments/index.gohtml:26
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Description"
|
|
|
|
|
msgstr "Descripció"
|
|
|
|
|
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: web/template/payments/index.gohtml:36
|
2024-08-11 01:22:37 +00:00
|
|
|
|
msgid "Are you sure you wish to delete this payment?"
|
|
|
|
|
msgstr "Esteu segur de voler esborrar aquest pagament?"
|
|
|
|
|
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: web/template/payments/index.gohtml:63
|
2024-08-11 01:22:37 +00:00
|
|
|
|
msgid "Actions for payment %s"
|
|
|
|
|
msgstr "Accions pel pagament %s"
|
|
|
|
|
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: web/template/payments/index.gohtml:82
|
2024-08-11 01:22:37 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Remove"
|
|
|
|
|
msgstr "Esborra"
|
|
|
|
|
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: web/template/payments/index.gohtml:92
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
msgid "No payments added yet."
|
|
|
|
|
msgstr "No hi ha cap pagament."
|
|
|
|
|
|
|
|
|
|
#: web/template/payments/edit.gohtml:3
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Edit Payment “%s”"
|
|
|
|
|
msgstr "Edició del pagament «%s»"
|
|
|
|
|
|
|
|
|
|
#: web/template/payments/accounts/new.gohtml:3
|
|
|
|
|
#: web/template/payments/accounts/new.gohtml:12
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "New Payment Account"
|
|
|
|
|
msgstr "Nou compte de pagament"
|
|
|
|
|
|
|
|
|
|
#: web/template/payments/accounts/new.gohtml:11
|
|
|
|
|
#: web/template/payments/accounts/index.gohtml:3
|
|
|
|
|
#: web/template/payments/accounts/index.gohtml:11
|
|
|
|
|
#: web/template/payments/accounts/edit.gohtml:11
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Payment Accounts"
|
|
|
|
|
msgstr "Comptes de pagament"
|
|
|
|
|
|
|
|
|
|
#: web/template/payments/accounts/index.gohtml:16
|
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "New payment account"
|
|
|
|
|
msgstr "Nou compte de pagament"
|
|
|
|
|
|
|
|
|
|
#: web/template/payments/accounts/index.gohtml:26
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Type"
|
|
|
|
|
msgstr "Tipus"
|
|
|
|
|
|
|
|
|
|
#: web/template/payments/accounts/index.gohtml:27
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Number"
|
|
|
|
|
msgstr "Número"
|
|
|
|
|
|
|
|
|
|
#: web/template/payments/accounts/index.gohtml:28
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Expiration Date"
|
|
|
|
|
msgstr "Data de caducitat"
|
|
|
|
|
|
|
|
|
|
#: web/template/payments/accounts/index.gohtml:51
|
|
|
|
|
msgid "No payment accounts added yet."
|
|
|
|
|
msgstr "No hi ha cap compte de pagament."
|
|
|
|
|
|
|
|
|
|
#: web/template/payments/accounts/edit.gohtml:3
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Edit Payment Account “%s”"
|
|
|
|
|
msgstr "Edició del compte de pagament «%s»"
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/ods.go:62 pkg/ods.go:106
|
2024-07-20 20:42:36 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "VAT number"
|
|
|
|
|
msgstr "DNI / NIF"
|
|
|
|
|
|
2024-08-11 01:22:37 +00:00
|
|
|
|
#: pkg/login.go:38 pkg/company.go:127 pkg/profile.go:40 pkg/contacts.go:276
|
2023-02-03 12:29:10 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Email"
|
|
|
|
|
msgstr "Correu-e"
|
|
|
|
|
|
2024-08-11 01:22:37 +00:00
|
|
|
|
#: pkg/login.go:49 pkg/profile.go:49
|
2023-02-01 10:02:32 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Password"
|
|
|
|
|
msgstr "Contrasenya"
|
|
|
|
|
|
2024-08-11 01:22:37 +00:00
|
|
|
|
#: pkg/login.go:76 pkg/company.go:283 pkg/profile.go:89
|
2023-02-01 10:02:32 +00:00
|
|
|
|
msgid "Email can not be empty."
|
|
|
|
|
msgstr "No podeu deixar el correu-e en blanc."
|
|
|
|
|
|
2024-08-11 01:22:37 +00:00
|
|
|
|
#: pkg/login.go:77 pkg/company.go:284 pkg/profile.go:90 pkg/contacts.go:420
|
2023-02-01 10:02:32 +00:00
|
|
|
|
msgid "This value is not a valid email. It should be like name@domain.com."
|
|
|
|
|
msgstr "Aquest valor no és un correu-e vàlid. Hauria de ser similar a nom@domini.cat."
|
|
|
|
|
|
2024-08-11 01:22:37 +00:00
|
|
|
|
#: pkg/login.go:79
|
2023-02-01 10:02:32 +00:00
|
|
|
|
msgid "Password can not be empty."
|
|
|
|
|
msgstr "No podeu deixar la contrasenya en blanc."
|
|
|
|
|
|
2024-08-11 01:22:37 +00:00
|
|
|
|
#: pkg/login.go:115
|
2023-02-01 10:02:32 +00:00
|
|
|
|
msgid "Invalid user or password."
|
|
|
|
|
msgstr "Nom d’usuari o contrasenya incorrectes."
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: pkg/products.go:172 pkg/products.go:276 pkg/quote.go:901 pkg/accounts.go:138
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/invoices.go:1147 pkg/contacts.go:149 pkg/contacts.go:262
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Name"
|
|
|
|
|
msgstr "Nom"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/products.go:177 pkg/products.go:303 pkg/quote.go:174 pkg/quote.go:708
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: pkg/payments.go:154 pkg/expenses.go:343 pkg/expenses.go:510
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: pkg/invoices.go:177 pkg/invoices.go:877 pkg/invoices.go:1462
|
|
|
|
|
#: pkg/contacts.go:154 pkg/contacts.go:362
|
2023-04-27 22:06:48 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Tags"
|
|
|
|
|
msgstr "Etiquetes"
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: pkg/products.go:181 pkg/quote.go:178 pkg/expenses.go:520 pkg/invoices.go:181
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/contacts.go:158
|
2023-04-27 22:06:48 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Tags Condition"
|
|
|
|
|
msgstr "Condició de les etiquetes"
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: pkg/products.go:185 pkg/quote.go:182 pkg/expenses.go:524 pkg/invoices.go:185
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/contacts.go:162
|
2023-04-27 22:06:48 +00:00
|
|
|
|
msgctxt "tag condition"
|
|
|
|
|
msgid "All"
|
|
|
|
|
msgstr "Totes"
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: pkg/products.go:186 pkg/expenses.go:525 pkg/invoices.go:186
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/contacts.go:163
|
2023-04-27 22:06:48 +00:00
|
|
|
|
msgid "Invoices must have all the specified labels."
|
|
|
|
|
msgstr "Les factures han de tenir totes les etiquetes."
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: pkg/products.go:190 pkg/quote.go:187 pkg/expenses.go:529 pkg/invoices.go:190
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/contacts.go:167
|
2023-04-27 22:06:48 +00:00
|
|
|
|
msgctxt "tag condition"
|
|
|
|
|
msgid "Any"
|
|
|
|
|
msgstr "Qualsevol"
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: pkg/products.go:191 pkg/expenses.go:530 pkg/invoices.go:191
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/contacts.go:168
|
2023-04-27 22:06:48 +00:00
|
|
|
|
msgid "Invoices must have at least one of the specified labels."
|
|
|
|
|
msgstr "Les factures han de tenir com a mínim una de les etiquetes."
|
|
|
|
|
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: pkg/products.go:282 pkg/quote.go:915 pkg/payments.go:121
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: pkg/invoices.go:1161
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Description"
|
|
|
|
|
msgstr "Descripció"
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/products.go:287 pkg/quote.go:919 pkg/invoices.go:1165
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Price"
|
|
|
|
|
msgstr "Preu"
|
|
|
|
|
|
2024-01-26 01:29:51 +00:00
|
|
|
|
#: pkg/products.go:297 pkg/quote.go:948 pkg/expenses.go:311
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/invoices.go:1194
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "input"
|
2023-02-08 12:47:36 +00:00
|
|
|
|
msgid "Taxes"
|
|
|
|
|
msgstr "Imposts"
|
2023-02-04 10:32:39 +00:00
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/products.go:322 pkg/quote.go:997 pkg/profile.go:92 pkg/invoices.go:1243
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/contacts.go:412
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgid "Name can not be empty."
|
|
|
|
|
msgstr "No podeu deixar el nom en blanc."
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/products.go:323 pkg/quote.go:998 pkg/invoices.go:1244
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgid "Price can not be empty."
|
|
|
|
|
msgstr "No podeu deixar el preu en blanc."
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/products.go:324 pkg/quote.go:999 pkg/invoices.go:1245
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgid "Price must be a number greater than zero."
|
|
|
|
|
msgstr "El preu ha de ser un número major a zero."
|
|
|
|
|
|
2024-01-26 01:29:51 +00:00
|
|
|
|
#: pkg/products.go:326 pkg/quote.go:1007 pkg/expenses.go:379
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/invoices.go:1253
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgid "Selected tax is not valid."
|
|
|
|
|
msgstr "Heu seleccionat un impost que no és vàlid."
|
|
|
|
|
|
2024-01-26 01:29:51 +00:00
|
|
|
|
#: pkg/products.go:327 pkg/quote.go:1008 pkg/expenses.go:380
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/invoices.go:1254
|
2023-03-01 13:08:12 +00:00
|
|
|
|
msgid "You can only select a tax of each class."
|
|
|
|
|
msgstr "Només podeu seleccionar un impost de cada classe."
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:113
|
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Trade name"
|
|
|
|
|
msgstr "Nom comercial"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:118 pkg/contacts.go:268
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Phone"
|
|
|
|
|
msgstr "Telèfon"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:136 pkg/contacts.go:284
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Web"
|
|
|
|
|
msgstr "Web"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:144 pkg/contacts.go:296
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Business name"
|
|
|
|
|
msgstr "Nom i cognoms"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:154 pkg/contacts.go:306
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "VAT number"
|
|
|
|
|
msgstr "DNI / NIF"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:160 pkg/contacts.go:312
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Address"
|
|
|
|
|
msgstr "Adreça"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:169 pkg/contacts.go:321
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "City"
|
|
|
|
|
msgstr "Població"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:175 pkg/contacts.go:327
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Province"
|
|
|
|
|
msgstr "Província"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:181 pkg/contacts.go:333
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Postal code"
|
|
|
|
|
msgstr "Codi postal"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:190 pkg/contacts.go:342
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Country"
|
|
|
|
|
msgstr "País"
|
|
|
|
|
|
|
|
|
|
#: pkg/company.go:200
|
2023-02-03 12:29:10 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Currency"
|
|
|
|
|
msgstr "Moneda"
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:207
|
2023-03-03 15:49:06 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Invoice number format"
|
|
|
|
|
msgstr "Format del número de factura"
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:213
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Next invoice number"
|
|
|
|
|
msgstr "Següent número de factura"
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:222
|
2023-06-09 10:43:50 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Quotation number format"
|
|
|
|
|
msgstr "Format del número de pressupost"
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:228
|
2023-06-09 10:43:50 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Next quotation number"
|
|
|
|
|
msgstr "Següent número de pressupost"
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:237
|
2023-03-03 15:49:06 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Legal disclaimer"
|
|
|
|
|
msgstr "Nota legal"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:271 pkg/contacts.go:394
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgid "Selected country is not valid."
|
|
|
|
|
msgstr "Heu seleccionat un país que no és vàlid."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:275 pkg/contacts.go:397
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgid "Business name can not be empty."
|
|
|
|
|
msgstr "No podeu deixar el nom i els cognoms en blanc."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:276 pkg/contacts.go:398
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgid "Business name must have at least two letters."
|
|
|
|
|
msgstr "Nom i cognoms han de tenir com a mínim dues lletres."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:277 pkg/contacts.go:400
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgid "VAT number can not be empty."
|
|
|
|
|
msgstr "No podeu deixar el DNI o NIF en blanc."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:278 pkg/contacts.go:401
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgid "This value is not a valid VAT number."
|
|
|
|
|
msgstr "Aquest valor no és un DNI o NIF vàlid."
|
|
|
|
|
|
|
|
|
|
#: pkg/company.go:280
|
|
|
|
|
msgid "Phone can not be empty."
|
|
|
|
|
msgstr "No podeu deixar el telèfon en blanc."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:281 pkg/contacts.go:417
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgid "This value is not a valid phone number."
|
|
|
|
|
msgstr "Aquest valor no és un telèfon vàlid."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:287 pkg/contacts.go:423
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgid "This value is not a valid web address. It should be like https://domain.com/."
|
|
|
|
|
msgstr "Aquest valor no és una adreça web vàlida. Hauria de ser similar a https://domini.cat/."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:289 pkg/contacts.go:403
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgid "Address can not be empty."
|
|
|
|
|
msgstr "No podeu deixar l’adreça en blanc."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:290 pkg/contacts.go:404
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgid "City can not be empty."
|
|
|
|
|
msgstr "No podeu deixar la població en blanc."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:291 pkg/contacts.go:405
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgid "Province can not be empty."
|
|
|
|
|
msgstr "No podeu deixar la província en blanc."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:292 pkg/contacts.go:407
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgid "Postal code can not be empty."
|
|
|
|
|
msgstr "No podeu deixar el codi postal en blanc."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/company.go:293 pkg/contacts.go:408
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgid "This value is not a valid postal code."
|
|
|
|
|
msgstr "Aquest valor no és un codi postal vàlid."
|
|
|
|
|
|
|
|
|
|
#: pkg/company.go:295
|
2023-02-03 12:29:10 +00:00
|
|
|
|
msgid "Selected currency is not valid."
|
|
|
|
|
msgstr "Heu seleccionat una moneda que no és vàlida."
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:296
|
2023-03-03 15:49:06 +00:00
|
|
|
|
msgid "Invoice number format can not be empty."
|
|
|
|
|
msgstr "No podeu deixar el format del número de factura en blanc."
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:297
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Next invoice number must be a number greater than zero."
|
|
|
|
|
msgstr "El següent número de factura ha de ser un número major a zero."
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:298
|
2023-06-09 10:43:50 +00:00
|
|
|
|
msgid "Quotation number format can not be empty."
|
|
|
|
|
msgstr "No podeu deixar el format del número de pressupost en blanc."
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:299
|
2023-06-09 10:43:50 +00:00
|
|
|
|
msgid "Next quotation number must be a number greater than zero."
|
|
|
|
|
msgstr "El següent número de pressupost ha de ser un número major a zero."
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:563
|
2023-02-03 12:29:10 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Tax name"
|
|
|
|
|
msgstr "Nom impost"
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:569
|
2023-02-28 11:02:27 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Tax Class"
|
|
|
|
|
msgstr "Classe d’impost"
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:572
|
2023-02-28 11:02:27 +00:00
|
|
|
|
msgid "Select a tax class"
|
|
|
|
|
msgstr "Escolliu una classe d’impost"
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:576
|
2023-02-03 12:29:10 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Rate (%)"
|
|
|
|
|
msgstr "Percentatge"
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:599
|
2023-02-03 12:29:10 +00:00
|
|
|
|
msgid "Tax name can not be empty."
|
|
|
|
|
msgstr "No podeu deixar el nom de l’impost en blanc."
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:600
|
2023-02-28 11:02:27 +00:00
|
|
|
|
msgid "Selected tax class is not valid."
|
|
|
|
|
msgstr "Heu seleccionat una classe d’impost que no és vàlida."
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:601
|
2023-02-03 12:29:10 +00:00
|
|
|
|
msgid "Tax rate can not be empty."
|
|
|
|
|
msgstr "No podeu deixar percentatge en blanc."
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:602
|
2023-02-03 12:29:10 +00:00
|
|
|
|
msgid "Tax rate must be an integer between -99 and 99."
|
|
|
|
|
msgstr "El percentatge ha de ser entre -99 i 99."
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:665
|
2023-03-03 15:49:06 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Payment method name"
|
|
|
|
|
msgstr "Nom del mètode de pagament"
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:671
|
2023-03-03 15:49:06 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Instructions"
|
|
|
|
|
msgstr "Instruccions"
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:689
|
2023-03-03 15:49:06 +00:00
|
|
|
|
msgid "Payment method name can not be empty."
|
|
|
|
|
msgstr "No podeu deixar el nom del mètode de pagament en blanc."
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
#: pkg/company.go:690
|
2023-03-03 15:49:06 +00:00
|
|
|
|
msgid "Payment instructions can not be empty."
|
|
|
|
|
msgstr "No podeu deixar les instruccions de pagament en blanc."
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/quote.go:147 pkg/quote.go:686 pkg/invoices.go:150 pkg/invoices.go:860
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
2023-06-20 09:37:02 +00:00
|
|
|
|
msgid "Customer"
|
|
|
|
|
msgstr "Client"
|
2023-06-07 14:35:31 +00:00
|
|
|
|
|
2024-01-26 01:29:51 +00:00
|
|
|
|
#: pkg/quote.go:148 pkg/invoices.go:151
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "All customers"
|
|
|
|
|
msgstr "Tots els clients"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/quote.go:153 pkg/quote.go:680
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Quotation Status"
|
|
|
|
|
msgstr "Estat del pressupost"
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: pkg/quote.go:154 pkg/expenses.go:515 pkg/invoices.go:157
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "All status"
|
|
|
|
|
msgstr "Tots els estats"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:159
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Quotation Number"
|
|
|
|
|
msgstr "Número de pressupost"
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: pkg/quote.go:164 pkg/expenses.go:500 pkg/invoices.go:167
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "From Date"
|
|
|
|
|
msgstr "A partir de la data"
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: pkg/quote.go:169 pkg/expenses.go:505 pkg/invoices.go:172
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "To Date"
|
|
|
|
|
msgstr "Fins la data"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:183
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Quotations must have all the specified labels."
|
|
|
|
|
msgstr "Els pressuposts han de tenir totes les etiquetes."
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:188
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Quotations must have at least one of the specified labels."
|
|
|
|
|
msgstr "Els pressuposts han de tenir com a mínim una de les etiquetes."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/quote.go:618
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "quotations.zip"
|
|
|
|
|
msgstr "pressuposts.zip"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/quote.go:632
|
|
|
|
|
msgid "quotations.ods"
|
|
|
|
|
msgstr "pressuposts.ods"
|
|
|
|
|
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: pkg/quote.go:634 pkg/quote.go:1176 pkg/quote.go:1184 pkg/expenses.go:704
|
|
|
|
|
#: pkg/expenses.go:734 pkg/invoices.go:684 pkg/invoices.go:1437
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/invoices.go:1445
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Invalid action"
|
|
|
|
|
msgstr "Acció invàlida."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/quote.go:687
|
Allow empty contact and payment method for quotes
I have to use a value to be used as “none” for payment method and
contact. In PL/pgSQL add_quote and edit_quote functions, that value is
NULL, while in forms it is the empty string. I can not simply pass the
empty string for either of these fields because PL/pgSQL expects
(nullable) integers, and "" is not a valid integer and is not NULL
either. A conversion is necessary.
Apparently, Go’s nil is not a valid representation for SQL’s NULL with
pgx, and had to use sql.NullString instead.
I also needed to coalesce contact’s VATIN and phone, because null values
can not be scanned to *string. I did not do that before because
`coalesce(vatin, '')` throws an error that '' is not a valid VATIN and
just left as is, wrongly expecting that pgx would do the job of leaving
the string blank for me. It does not.
Lastly, i can not blindly write Quotee’s tax details in the quote’s view
page, or we would see the (), characters for the empty address info.
2023-06-08 11:05:41 +00:00
|
|
|
|
msgid "Select a customer to quote."
|
|
|
|
|
msgstr "Escolliu un client a pressupostar."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/quote.go:692
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Quotation Date"
|
|
|
|
|
msgstr "Data del pressupost"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/quote.go:698
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Terms and conditions"
|
|
|
|
|
msgstr "Condicions d’acceptació"
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/quote.go:703 pkg/invoices.go:872
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Notes"
|
|
|
|
|
msgstr "Notes"
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/quote.go:712 pkg/invoices.go:882
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Payment Method"
|
|
|
|
|
msgstr "Mètode de pagament"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/quote.go:713
|
Allow empty contact and payment method for quotes
I have to use a value to be used as “none” for payment method and
contact. In PL/pgSQL add_quote and edit_quote functions, that value is
NULL, while in forms it is the empty string. I can not simply pass the
empty string for either of these fields because PL/pgSQL expects
(nullable) integers, and "" is not a valid integer and is not NULL
either. A conversion is necessary.
Apparently, Go’s nil is not a valid representation for SQL’s NULL with
pgx, and had to use sql.NullString instead.
I also needed to coalesce contact’s VATIN and phone, because null values
can not be scanned to *string. I did not do that before because
`coalesce(vatin, '')` throws an error that '' is not a valid VATIN and
just left as is, wrongly expecting that pgx would do the job of leaving
the string blank for me. It does not.
Lastly, i can not blindly write Quotee’s tax details in the quote’s view
page, or we would see the (), characters for the empty address info.
2023-06-08 11:05:41 +00:00
|
|
|
|
msgid "Select a payment method."
|
|
|
|
|
msgstr "Escolliu un mètode de pagament."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/quote.go:749
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Selected quotation status is not valid."
|
|
|
|
|
msgstr "Heu seleccionat un estat de pressupost que no és vàlid."
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/quote.go:751 pkg/invoices.go:937
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Selected customer is not valid."
|
|
|
|
|
msgstr "Heu seleccionat un client que no és vàlid."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/quote.go:753
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Quotation date can not be empty."
|
|
|
|
|
msgstr "No podeu deixar la data del pressupost en blanc."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/quote.go:754
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Quotation date must be a valid date."
|
|
|
|
|
msgstr "La data del pressupost ha de ser vàlida."
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/quote.go:757 pkg/invoices.go:941
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Selected payment method is not valid."
|
|
|
|
|
msgstr "Heu seleccionat un mètode de pagament que no és vàlid."
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/quote.go:891 pkg/quote.go:896 pkg/invoices.go:1137 pkg/invoices.go:1142
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Id"
|
|
|
|
|
msgstr "Identificador"
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/quote.go:929 pkg/invoices.go:1175
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Quantity"
|
|
|
|
|
msgstr "Quantitat"
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/quote.go:938 pkg/invoices.go:1184
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Discount (%)"
|
|
|
|
|
msgstr "Descompte (%)"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/quote.go:992
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Quotation product ID must be a number greater than zero."
|
|
|
|
|
msgstr "L’ID del producte de pressupost ha de ser un número major a zero."
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/quote.go:995 pkg/invoices.go:1241
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Product ID must be a positive number or zero."
|
|
|
|
|
msgstr "L’ID del producte ha de ser un número positiu o zero."
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/quote.go:1001 pkg/invoices.go:1247
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Quantity can not be empty."
|
|
|
|
|
msgstr "No podeu deixar la quantitat en blanc."
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/quote.go:1002 pkg/invoices.go:1248
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Quantity must be a number greater than zero."
|
|
|
|
|
msgstr "La quantitat ha de ser un número major a zero."
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/quote.go:1004 pkg/invoices.go:1250
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Discount can not be empty."
|
|
|
|
|
msgstr "No podeu deixar el descompte en blanc."
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/quote.go:1005 pkg/invoices.go:1251
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Discount must be a percentage between 0 and 100."
|
|
|
|
|
msgstr "El descompte ha de ser un percentatge entre 0 i 100."
|
|
|
|
|
|
2023-02-03 12:29:10 +00:00
|
|
|
|
#: pkg/profile.go:25
|
2023-01-31 14:40:12 +00:00
|
|
|
|
msgctxt "language option"
|
|
|
|
|
msgid "Automatic"
|
|
|
|
|
msgstr "Automàtic"
|
|
|
|
|
|
2023-02-03 12:29:10 +00:00
|
|
|
|
#: pkg/profile.go:31
|
2023-01-31 14:40:12 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "User name"
|
|
|
|
|
msgstr "Nom d’usuari"
|
|
|
|
|
|
2023-02-03 12:29:10 +00:00
|
|
|
|
#: pkg/profile.go:57
|
2023-01-31 14:40:12 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Password Confirmation"
|
|
|
|
|
msgstr "Confirmació contrasenya"
|
|
|
|
|
|
2023-02-03 12:29:10 +00:00
|
|
|
|
#: pkg/profile.go:65
|
2023-01-31 14:40:12 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Language"
|
|
|
|
|
msgstr "Idioma"
|
|
|
|
|
|
2023-02-05 13:06:33 +00:00
|
|
|
|
#: pkg/profile.go:93
|
2023-01-31 14:40:12 +00:00
|
|
|
|
msgid "Confirmation does not match password."
|
|
|
|
|
msgstr "La confirmació no és igual a la contrasenya."
|
|
|
|
|
|
2023-02-05 13:06:33 +00:00
|
|
|
|
#: pkg/profile.go:94
|
2023-01-31 14:40:12 +00:00
|
|
|
|
msgid "Selected language is not valid."
|
|
|
|
|
msgstr "Heu seleccionat un idioma que no és vàlid."
|
2023-02-01 09:14:26 +00:00
|
|
|
|
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: pkg/payments.go:127 pkg/expenses.go:305 pkg/invoices.go:866
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Invoice Date"
|
|
|
|
|
msgstr "Data de factura"
|
|
|
|
|
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: pkg/payments.go:133
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Account"
|
|
|
|
|
msgstr "Compte"
|
|
|
|
|
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: pkg/payments.go:139 pkg/expenses.go:320
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Amount"
|
|
|
|
|
msgstr "Import"
|
|
|
|
|
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: pkg/payments.go:149 pkg/expenses.go:331 pkg/invoices.go:888
|
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "File"
|
|
|
|
|
msgstr "Fitxer"
|
|
|
|
|
|
|
|
|
|
#: pkg/payments.go:161
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
msgid "Select an account."
|
|
|
|
|
msgstr "Escolliu un compte."
|
|
|
|
|
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: pkg/payments.go:210
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
msgid "Description can not be empty."
|
|
|
|
|
msgstr "No podeu deixar la descripció en blanc."
|
|
|
|
|
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: pkg/payments.go:211
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
msgid "Selected payment account is not valid."
|
|
|
|
|
msgstr "Heu seleccionat un compte de pagament que no és vàlid."
|
|
|
|
|
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: pkg/payments.go:212
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
msgid "Payment date must be a valid date."
|
|
|
|
|
msgstr "La data de pagament ha de ser vàlida."
|
|
|
|
|
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: pkg/payments.go:213 pkg/expenses.go:381
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
msgid "Amount can not be empty."
|
|
|
|
|
msgstr "No podeu deixar l’import en blanc."
|
|
|
|
|
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: pkg/payments.go:214 pkg/expenses.go:382
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
msgid "Amount must be a number greater than zero."
|
|
|
|
|
msgstr "L’import ha de ser un número major a zero."
|
|
|
|
|
|
|
|
|
|
#: pkg/accounts.go:129
|
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Type"
|
|
|
|
|
msgstr "Tipus"
|
|
|
|
|
|
|
|
|
|
#: pkg/accounts.go:144 pkg/contacts.go:352
|
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "IBAN"
|
|
|
|
|
msgstr "IBAN"
|
|
|
|
|
|
|
|
|
|
#: pkg/accounts.go:150
|
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Card’s last four digits"
|
|
|
|
|
msgstr "Els quatre darrers dígits de la targeta"
|
|
|
|
|
|
|
|
|
|
#: pkg/accounts.go:161
|
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Expiration date"
|
|
|
|
|
msgstr "Data de caducitat"
|
|
|
|
|
|
|
|
|
|
#: pkg/accounts.go:227
|
|
|
|
|
msgid "Selected payment account type is not valid."
|
|
|
|
|
msgstr "Heu seleccionat un tipus de compte de pagament que no és vàlid."
|
|
|
|
|
|
|
|
|
|
#: pkg/accounts.go:230
|
|
|
|
|
msgid "IBAN can not be empty."
|
|
|
|
|
msgstr "No podeu deixar l’IBAN en blanc."
|
|
|
|
|
|
|
|
|
|
#: pkg/accounts.go:231
|
|
|
|
|
msgid "This value is not a valid IBAN."
|
|
|
|
|
msgstr "Aquest valor no és un IBAN vàlid."
|
|
|
|
|
|
|
|
|
|
#: pkg/accounts.go:234
|
|
|
|
|
msgid "Last four digits can not be empty."
|
|
|
|
|
msgstr "No podeu deixar el quatre darrers dígits en blanc."
|
|
|
|
|
|
|
|
|
|
#: pkg/accounts.go:235
|
|
|
|
|
msgid "You must enter the card’s last four digits"
|
|
|
|
|
msgstr "Heu d’entrar els quatre darrers dígits de la targeta"
|
|
|
|
|
|
|
|
|
|
#: pkg/accounts.go:236
|
|
|
|
|
msgid "Last four digits must be a number."
|
|
|
|
|
msgstr "El quatre darrera dígits han de ser un número."
|
|
|
|
|
|
|
|
|
|
#: pkg/accounts.go:239
|
|
|
|
|
msgid "Expiration date can not be empty."
|
|
|
|
|
msgstr "No podeu deixar la data de pagament en blanc."
|
|
|
|
|
|
|
|
|
|
#: pkg/accounts.go:241
|
|
|
|
|
msgid "Expiration date should be a valid date in format MM/YY (e.g., 08/24)."
|
|
|
|
|
msgstr "La data de caducitat has de ser vàlida i en format MM/AA (p. ex., 08/24)."
|
|
|
|
|
|
|
|
|
|
#: pkg/accounts.go:245
|
|
|
|
|
msgid "Payment account name can not be empty."
|
|
|
|
|
msgstr "No podeu deixar el nom del compte de pagament en blanc."
|
|
|
|
|
|
2023-05-22 09:16:21 +00:00
|
|
|
|
#: pkg/dashboard.go:138
|
2023-05-17 10:05:30 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Period"
|
|
|
|
|
msgstr "Període"
|
|
|
|
|
|
2023-05-22 09:16:21 +00:00
|
|
|
|
#: pkg/dashboard.go:141
|
2023-05-17 10:05:30 +00:00
|
|
|
|
msgctxt "period option"
|
2023-05-19 12:05:57 +00:00
|
|
|
|
msgid "Month"
|
|
|
|
|
msgstr "Mes"
|
|
|
|
|
|
2023-05-22 09:16:21 +00:00
|
|
|
|
#: pkg/dashboard.go:145
|
2023-05-19 12:05:57 +00:00
|
|
|
|
msgctxt "period option"
|
|
|
|
|
msgid "Previous month"
|
|
|
|
|
msgstr "Mes anterior"
|
2023-05-17 10:05:30 +00:00
|
|
|
|
|
2023-05-22 09:16:21 +00:00
|
|
|
|
#: pkg/dashboard.go:149
|
2023-05-17 10:05:30 +00:00
|
|
|
|
msgctxt "period option"
|
|
|
|
|
msgid "Quarter"
|
|
|
|
|
msgstr "Trimestre"
|
|
|
|
|
|
2023-05-22 09:16:21 +00:00
|
|
|
|
#: pkg/dashboard.go:153
|
2023-05-17 10:05:30 +00:00
|
|
|
|
msgctxt "period option"
|
2023-05-19 12:05:57 +00:00
|
|
|
|
msgid "Previous quarter"
|
|
|
|
|
msgstr "Trimestre anterior"
|
|
|
|
|
|
2023-05-22 09:16:21 +00:00
|
|
|
|
#: pkg/dashboard.go:157
|
2023-05-19 12:05:57 +00:00
|
|
|
|
msgctxt "period option"
|
|
|
|
|
msgid "Year"
|
|
|
|
|
msgstr "Any"
|
2023-05-17 10:05:30 +00:00
|
|
|
|
|
2023-05-22 09:16:21 +00:00
|
|
|
|
#: pkg/dashboard.go:161
|
2023-05-17 10:05:30 +00:00
|
|
|
|
msgctxt "period option"
|
2023-05-19 12:05:57 +00:00
|
|
|
|
msgid "Previous year"
|
2023-05-17 10:05:30 +00:00
|
|
|
|
msgstr "Any anterior"
|
|
|
|
|
|
2024-01-26 01:29:51 +00:00
|
|
|
|
#: pkg/expenses.go:237
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgid "Select a contact."
|
|
|
|
|
msgstr "Escolliu un contacte."
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: pkg/expenses.go:294 pkg/expenses.go:489
|
2023-06-20 09:37:02 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Contact"
|
|
|
|
|
msgstr "Contacte"
|
|
|
|
|
|
2024-01-26 01:29:51 +00:00
|
|
|
|
#: pkg/expenses.go:300
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Invoice number"
|
|
|
|
|
msgstr "Número de factura"
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: pkg/expenses.go:337 pkg/expenses.go:514
|
2023-07-12 18:06:53 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Expense Status"
|
|
|
|
|
msgstr "Estat de la despesa"
|
|
|
|
|
|
2024-01-26 01:29:51 +00:00
|
|
|
|
#: pkg/expenses.go:377
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgid "Selected contact is not valid."
|
|
|
|
|
msgstr "Heu seleccionat un contacte que no és vàlid."
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/expenses.go:378 pkg/invoices.go:939
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgid "Invoice date must be a valid date."
|
|
|
|
|
msgstr "La data de facturació ha de ser vàlida."
|
|
|
|
|
|
2024-01-26 01:29:51 +00:00
|
|
|
|
#: pkg/expenses.go:384
|
2023-07-12 18:06:53 +00:00
|
|
|
|
msgid "Selected expense status is not valid."
|
|
|
|
|
msgstr "Heu seleccionat un estat de despesa que no és vàlid."
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: pkg/expenses.go:490
|
2023-06-20 09:17:07 +00:00
|
|
|
|
msgid "All contacts"
|
|
|
|
|
msgstr "Tots els contactes"
|
|
|
|
|
|
Add the payments section
This actually should be the “payments and receivables” section, however
this is quite a mouthful; a “receivable” is a payment made **to** you,
therefore “payments” is ok.
In fact, there is still no receivables in there, as they should be in
a separate relation, to constraint them to invoices instead of expenses.
It will be done in a separate commit.
Since this section will be, in a sense, sort of simplified accounting,
i needed to introduce the “payment account” concept. There is no way,
yet, for users to add them, because i have to revamp the “tax details”
section, but this commit started to grow too big already.
The same reasoning for the attachment payment slips as PDF to payment:
something i have to add, but not yet in this commit.
2024-08-10 02:34:07 +00:00
|
|
|
|
#: pkg/expenses.go:495 pkg/invoices.go:162
|
Add filters form for invoices
Instead of using links in the invoice tags, that we will replace with a
“click-to-edit field”, with Oriol agreed to add a form with filters that
includes not only the tags but also dates, customer, status, and the
invoice number.
This means i now need dynamic SQL, and i do not think this belongs to
the database (i.e., no PL/pgSQL function for that). I have looked at
query builder libraries for Golang, and did not find anything that
suited me: either they wanted to manage not only the SQL query but also
all structs, or they managed to confuse Goland’s SQL analyzer.
For now, at least, i am using a very simple approach with arrays, that
still confuses Goland’s analyzer, but just in a very specific part,
which i find tolerable—not that their analyzer is that great to begin
with, but that’s a story for another day.
2023-03-29 14:16:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Invoice Number"
|
|
|
|
|
msgstr "Número de factura"
|
|
|
|
|
|
2024-08-11 22:08:18 +00:00
|
|
|
|
#: pkg/expenses.go:732
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
msgid "expenses.ods"
|
|
|
|
|
msgstr "despeses.ods"
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/invoices.go:156 pkg/invoices.go:854
|
2023-05-11 21:32:21 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Invoice Status"
|
|
|
|
|
msgstr "Estat de la factura"
|
|
|
|
|
|
2024-01-26 01:29:51 +00:00
|
|
|
|
#: pkg/invoices.go:560
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgid "Select a customer to bill."
|
|
|
|
|
msgstr "Escolliu un client a facturar."
|
|
|
|
|
|
2024-01-26 01:29:51 +00:00
|
|
|
|
#: pkg/invoices.go:664
|
2023-03-13 14:00:35 +00:00
|
|
|
|
msgid "invoices.zip"
|
|
|
|
|
msgstr "factures.zip"
|
|
|
|
|
|
2024-07-20 20:42:36 +00:00
|
|
|
|
#: pkg/invoices.go:682
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
msgid "invoices.ods"
|
|
|
|
|
msgstr "factures.ods"
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/invoices.go:936
|
2023-03-13 14:00:35 +00:00
|
|
|
|
msgid "Selected invoice status is not valid."
|
|
|
|
|
msgstr "Heu seleccionat un estat de factura que no és vàlid."
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/invoices.go:938
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgid "Invoice date can not be empty."
|
|
|
|
|
msgstr "No podeu deixar la data de la factura en blanc."
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/invoices.go:1074
|
2023-06-10 18:46:03 +00:00
|
|
|
|
#, c-format
|
|
|
|
|
msgid "Re: quotation #%s of %s"
|
|
|
|
|
msgstr "Ref: pressupost núm. %s del %s"
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/invoices.go:1075
|
2023-06-10 18:46:03 +00:00
|
|
|
|
msgctxt "to_char"
|
|
|
|
|
msgid "MM/DD/YYYY"
|
|
|
|
|
msgstr "DD/MM/YYYY"
|
|
|
|
|
|
2024-07-20 20:52:00 +00:00
|
|
|
|
#: pkg/invoices.go:1238
|
2023-05-22 09:16:21 +00:00
|
|
|
|
msgid "Invoice product ID must be a number greater than zero."
|
|
|
|
|
msgstr "L’ID del producte de factura ha de ser un número major a zero."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/contacts.go:292
|
2023-02-03 12:29:10 +00:00
|
|
|
|
msgctxt "input"
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgid "Need to input tax details"
|
|
|
|
|
msgstr "Necessito poder facturar aquest contacte"
|
2023-02-08 12:47:36 +00:00
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/contacts.go:357
|
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
|
|
|
|
msgctxt "bic"
|
|
|
|
|
msgid "BIC"
|
|
|
|
|
msgstr "BIC"
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/contacts.go:413
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
msgid "Name must have at least two letters."
|
|
|
|
|
msgstr "El nom ha de tenir com a mínim dues lletres."
|
2023-02-03 12:29:10 +00:00
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/contacts.go:426
|
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
|
|
|
|
msgid "This values is not a valid IBAN."
|
|
|
|
|
msgstr "Aquest valor no és un IBAN vàlid."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/contacts.go:429
|
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
|
|
|
|
msgid "This values is not a valid BIC."
|
|
|
|
|
msgstr "Aquest valor no és un BIC vàlid."
|
|
|
|
|
|
Add option to export the list of quotes, invoices, and expenses to ODS
This was requested by a potential user, as they want to be able to do
whatever they want to do to these lists with a spreadsheet.
In fact, they requested to be able to export to CSV, but, as always,
using CSV is a minefield because of Microsoft: since their Excel product
is fucking unable to write and read CSV from different locales, even if
using the same exact Excel product, i can not also create a CSV file
that is guaranteed to work on all locales. If i used the non-standard
sep=; thing to tell Excel that it is a fucking stupid application, then
proper applications would show that line as a row, which is the correct
albeit undesirable behaviour.
The solution is to use a spreadsheet file format that does not have this
issue. As far as I know, by default Excel is able to read XLSX and ODS
files, but i refuse to use the artificially complex, not the actually
used in Excel, and lobbied standard that Microsoft somehow convinced ISO
to publish, as i am using a different format because of the mess they
made, and i do not want to bend over in front of them, so ODS it is.
ODS is neither an elegant or good format by any means, but at least i
can write them using simple strings, because there is no ODS library
in Debian and i am not going to write yet another DEB package for an
overengineered package to write a simple table—all i want is to say
“here are these n columns, and these m columns; have a good day!”.
Part of #51.
2023-07-18 11:29:36 +00:00
|
|
|
|
#: pkg/contacts.go:551
|
Allow importing contacts from Holded
This allows to import an Excel file exported from Holded, because it is
our own user case. When we have more customers, we will give out an
Excel template file to fill out.
Why XLSX files instead of CSV, for instance? First, because this is the
output from Holded, but even then we would have more trouble with CSV
than with XLSX because of Microsoft: they royally fucked up
interoperability when decided that CSV files, the files that only other
applications or programmers see, should be “localized”, and use a comma
or a **semicolon** to separate a **comma** separated file depending on
the locale’s decimal separator.
This is ridiculous because it means that CSV files created with an Excel
in USA uses comma while the same Excel but with a French locale expects
the fields to be separated by semicolon. And for no good reason,
either.
Since they fucked up so bad, decided to add a non-standard “meta” field
to specify the separator, writing a `sep=,` in the first line, but this
only works for reading, because saving the same file changes the
separator back to the locale-dependent character and removes the “meta”
field.
And since everyone expects to open spreadsheet with Excel, i can not
use CSV if i do not want a bunch of support tickets telling me that the
template is all in a single line.
I use an extremely old version of a xlsx reading library for golang[0]
because it is already available in Debian repositories, and the only
thing i want from it is to convert the convoluted XML file into a
string array.
Go is only responsible to read the file and dump its contents into a
temporary table, so that it can execute the PL/pgSQL function that will
actually move that data to the correct relations, much like add_contact
does but in batch.
In PostgreSQL version 16 they added a pg_input_is_valid function that
i would use to test whether input values really conform to domains,
but i will have to wait for Debian to pick up the new version.
Meanwhile, i use a couple of temporary functions, in lieu of nested
functions support in PostgreSQL.
Part of #45
[0]: https://github.com/tealeg/xlsx
2023-07-02 22:05:47 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Holded Excel file"
|
|
|
|
|
msgstr "Fitxer Excel del Holded"
|
|
|
|
|
|
2024-01-19 22:05:01 +00:00
|
|
|
|
#~ msgctxt "link"
|
|
|
|
|
#~ msgid "login"
|
|
|
|
|
#~ msgstr "Entrada"
|
|
|
|
|
|
2024-01-19 19:03:04 +00:00
|
|
|
|
#~ msgid "If you want to sign in, just head to %sthe login page%s and enter your credentials in the form."
|
|
|
|
|
#~ msgstr "Si vols accedir al teu usuari només has d'anar a %sla pàgina d’entrada%s i apuntar les teves credencials al seu lloc."
|
|
|
|
|
|
|
|
|
|
#~ msgid "manager"
|
|
|
|
|
#~ msgstr "gestor"
|
|
|
|
|
|
|
|
|
|
#~ msgid "Tool to simplify management for small business and freelancers"
|
|
|
|
|
#~ msgstr "Eina per simplificar la gestió d’autònoms i petites empreses."
|
|
|
|
|
|
|
|
|
|
#~ msgid "Reduce management time, take control of your balance."
|
|
|
|
|
#~ msgstr "Redueix el temps de gestió, tingues controlats els teus números."
|
|
|
|
|
|
|
|
|
|
#~ msgid "application"
|
|
|
|
|
#~ msgstr "aplicació"
|
|
|
|
|
|
|
|
|
|
#~ msgctxt "term"
|
|
|
|
|
#~ msgid "Sales"
|
|
|
|
|
#~ msgstr "Vendes"
|
|
|
|
|
|
2023-11-06 12:52:34 +00:00
|
|
|
|
#~ msgctxt "title"
|
|
|
|
|
#~ msgid "Switch Company"
|
|
|
|
|
#~ msgstr "Canvi d’empresa"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#~ msgctxt "expense"
|
|
|
|
|
#~ msgid "All"
|
|
|
|
|
#~ msgstr "Totes"
|
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#~ msgctxt "action"
|
|
|
|
|
#~ msgid "Update contact"
|
|
|
|
|
#~ msgstr "Actualitza contacte"
|
|
|
|
|
|
|
|
|
|
#~ msgctxt "action"
|
|
|
|
|
#~ msgid "Update expense"
|
|
|
|
|
#~ msgstr "Actualitza despesa"
|
|
|
|
|
|
|
|
|
|
#~ msgctxt "action"
|
|
|
|
|
#~ msgid "Update product"
|
|
|
|
|
#~ msgstr "Actualitza producte"
|
|
|
|
|
|
2023-05-23 12:21:04 +00:00
|
|
|
|
#~ msgctxt "action"
|
|
|
|
|
#~ msgid "Edit invoice"
|
|
|
|
|
#~ msgstr "Edita factura"
|
|
|
|
|
|
|
|
|
|
#~ msgctxt "contact"
|
|
|
|
|
#~ msgid "All"
|
|
|
|
|
#~ msgstr "Tots"
|
|
|
|
|
|
2023-04-27 22:06:48 +00:00
|
|
|
|
#~ msgid "Product ID can not be empty."
|
|
|
|
|
#~ msgstr "No podeu deixar l’identificador del producte en blanc."
|
|
|
|
|
|
2023-03-10 13:02:55 +00:00
|
|
|
|
#~ msgctxt "title"
|
|
|
|
|
#~ msgid "Label"
|
|
|
|
|
#~ msgstr "Etiqueta"
|
|
|
|
|
|
2023-02-08 12:47:36 +00:00
|
|
|
|
#~ msgid "Select a tax for this product."
|
|
|
|
|
#~ msgstr "Escolliu un impost per aquest producte."
|
2023-02-03 12:29:10 +00:00
|
|
|
|
|
2023-02-04 10:32:39 +00:00
|
|
|
|
#~ msgctxt "input"
|
2023-02-08 12:47:36 +00:00
|
|
|
|
#~ msgid "Tax"
|
|
|
|
|
#~ msgstr "Impost"
|
2023-02-04 10:32:39 +00:00
|
|
|
|
|
2023-02-01 09:14:26 +00:00
|
|
|
|
#~ msgctxt "title"
|
|
|
|
|
#~ msgid "Customers"
|
|
|
|
|
#~ msgstr "Clients"
|
|
|
|
|
|
|
|
|
|
#~ msgid "No customers added yet."
|
|
|
|
|
#~ msgstr "No hi ha cap client."
|