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
|
|
|
|
# Spanish translations for numerus package.
|
|
|
|
|
# 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"
|
2023-07-06 09:49:36 +00:00
|
|
|
|
"POT-Creation-Date: 2023-07-06 11:45+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:45+0100\n"
|
|
|
|
|
"Last-Translator: jordi fita mas <jordi@tandem.blog>\n"
|
|
|
|
|
"Language-Team: Spanish <es@tp.org.es>\n"
|
|
|
|
|
"Language: es\n"
|
|
|
|
|
"MIME-Version: 1.0\n"
|
|
|
|
|
"Content-Type: text/plain; charset=UTF-8\n"
|
|
|
|
|
"Content-Transfer-Encoding: 8bit\n"
|
|
|
|
|
"Plural-Forms: nplurals=2; plural=(n != 1);\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 "Añadir productos 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
|
|
|
|
|
#: 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
|
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: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
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Home"
|
|
|
|
|
msgstr "Inicio"
|
|
|
|
|
|
|
|
|
|
#: 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 "Facturas"
|
|
|
|
|
|
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 "Nueva 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 "Todos"
|
|
|
|
|
|
2023-04-27 22:06:48 +00:00
|
|
|
|
#: web/template/invoices/products.gohtml:49
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/quotes/products.gohtml:49 web/template/products/index.gohtml:40
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Name"
|
|
|
|
|
msgstr "Nombre"
|
|
|
|
|
|
2023-04-27 22:06:48 +00:00
|
|
|
|
#: web/template/invoices/products.gohtml:50
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/invoices/view.gohtml:62 web/template/quotes/products.gohtml:50
|
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:73 web/template/products/index.gohtml:42
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Price"
|
|
|
|
|
msgstr "Precio"
|
|
|
|
|
|
2023-04-27 22:06:48 +00:00
|
|
|
|
#: web/template/invoices/products.gohtml:64
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/quotes/products.gohtml:64 web/template/products/index.gohtml:83
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgid "No products added yet."
|
|
|
|
|
msgstr "No hay productos."
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/invoices/products.gohtml:72 web/template/invoices/new.gohtml:87
|
|
|
|
|
#: web/template/invoices/edit.gohtml:88 web/template/quotes/products.gohtml:72
|
|
|
|
|
#: 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 "Añadir productos"
|
|
|
|
|
|
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 "Se ha borrado el producto «%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 "Deshacer"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/invoices/new.gohtml:63 web/template/invoices/view.gohtml:67
|
|
|
|
|
#: web/template/invoices/edit.gohtml:64 web/template/quotes/new.gohtml:64
|
|
|
|
|
#: 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-06 09:49:36 +00:00
|
|
|
|
#: web/template/invoices/new.gohtml:73 web/template/invoices/view.gohtml:71
|
|
|
|
|
#: web/template/invoices/view.gohtml:111 web/template/invoices/edit.gohtml:74
|
|
|
|
|
#: 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-02-24 11:22:15 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Total"
|
|
|
|
|
msgstr "Total"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/invoices/new.gohtml:91 web/template/invoices/edit.gohtml:92
|
|
|
|
|
#: web/template/quotes/new.gohtml:92 web/template/quotes/edit.gohtml:93
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Update"
|
|
|
|
|
msgstr "Actualizar"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/invoices/new.gohtml:94 web/template/invoices/edit.gohtml:95
|
|
|
|
|
#: 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-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/expenses/new.gohtml:33 web/template/expenses/edit.gohtml:38
|
|
|
|
|
#: web/template/products/new.gohtml:30 web/template/products/edit.gohtml:36
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "action"
|
2023-05-26 11:38:04 +00:00
|
|
|
|
msgid "Save"
|
|
|
|
|
msgstr "Guardad"
|
2023-02-12 20:06:48 +00:00
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:19
|
2023-03-09 11:11:53 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Download invoices"
|
|
|
|
|
msgstr "Descargar facturas"
|
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:21
|
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "New invoice"
|
|
|
|
|
msgstr "Nueva factura"
|
|
|
|
|
|
|
|
|
|
#: web/template/invoices/index.gohtml:43 web/template/dashboard.gohtml:23
|
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/quotes/index.gohtml:43 web/template/contacts/index.gohtml:36
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/expenses/index.gohtml:36 web/template/products/index.gohtml:34
|
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 "Filtrar"
|
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:49
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "invoice"
|
|
|
|
|
msgid "All"
|
|
|
|
|
msgstr "Todas"
|
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:50 web/template/invoices/view.gohtml:34
|
2023-06-10 18:46:03 +00:00
|
|
|
|
#: web/template/quotes/index.gohtml:50 web/template/quotes/view.gohtml:37
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Date"
|
|
|
|
|
msgstr "Fecha"
|
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:51
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Invoice Num."
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgstr "N.º factura"
|
2023-02-12 20:06:48 +00:00
|
|
|
|
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:52 web/template/quotes/index.gohtml:52
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
2023-06-20 09:33:28 +00:00
|
|
|
|
msgid "Customer"
|
|
|
|
|
msgstr "Cliente"
|
2023-02-12 20:06:48 +00:00
|
|
|
|
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:53 web/template/quotes/index.gohtml:53
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Status"
|
|
|
|
|
msgstr "Estado"
|
|
|
|
|
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:54 web/template/quotes/index.gohtml:54
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/contacts/index.gohtml:45 web/template/expenses/index.gohtml:45
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/products/index.gohtml:41
|
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
|
|
|
|
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:55 web/template/quotes/index.gohtml:55
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/expenses/index.gohtml:46
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "title"
|
2023-02-22 13:39:38 +00:00
|
|
|
|
msgid "Amount"
|
|
|
|
|
msgstr "Importe"
|
|
|
|
|
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:56 web/template/quotes/index.gohtml:56
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/expenses/index.gohtml:47
|
2023-02-22 13:39:38 +00:00
|
|
|
|
msgctxt "title"
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgid "Download"
|
|
|
|
|
msgstr "Descargar"
|
|
|
|
|
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:57 web/template/quotes/index.gohtml:57
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/contacts/index.gohtml:46 web/template/expenses/index.gohtml:48
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/products/index.gohtml:43
|
2023-03-08 10:54:06 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Actions"
|
|
|
|
|
msgstr "Acciones"
|
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:64
|
2023-03-09 11:11:53 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Select invoice %v"
|
|
|
|
|
msgstr "Seleccionar factura %v"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:105
|
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Download invoice %s"
|
|
|
|
|
msgstr "Descargar factura %s"
|
|
|
|
|
|
|
|
|
|
#: web/template/invoices/index.gohtml:113
|
|
|
|
|
msgid "Actions for invoice %s"
|
|
|
|
|
msgstr "Acciones para la factura %s"
|
|
|
|
|
|
|
|
|
|
#: web/template/invoices/index.gohtml:121 web/template/invoices/view.gohtml:19
|
|
|
|
|
#: web/template/quotes/index.gohtml:120 web/template/quotes/view.gohtml:22
|
|
|
|
|
#: web/template/contacts/index.gohtml:77 web/template/expenses/index.gohtml:87
|
|
|
|
|
#: web/template/products/index.gohtml:73
|
2023-03-13 14:00:35 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Edit"
|
|
|
|
|
msgstr "Editar"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:129 web/template/invoices/view.gohtml:16
|
|
|
|
|
#: web/template/quotes/index.gohtml:128 web/template/quotes/view.gohtml:19
|
2023-03-08 10:54:06 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Duplicate"
|
|
|
|
|
msgstr "Duplicar"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:139
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgid "No invoices added yet."
|
|
|
|
|
msgstr "No hay facturas."
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/invoices/index.gohtml:146 web/template/quotes/index.gohtml:153
|
|
|
|
|
#: web/template/expenses/index.gohtml:104
|
2023-06-20 09:33:28 +00:00
|
|
|
|
msgid "Total"
|
|
|
|
|
msgstr "Total"
|
|
|
|
|
|
2023-04-15 02:05:59 +00:00
|
|
|
|
#: web/template/invoices/view.gohtml:2 web/template/invoices/view.gohtml:33
|
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 "Descargar 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
|
|
|
|
#: web/template/invoices/view.gohtml:61 web/template/quotes/view.gohtml:72
|
2023-02-24 11:22:15 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Concept"
|
|
|
|
|
msgstr "Concepto"
|
|
|
|
|
|
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/invoices/view.gohtml:64 web/template/quotes/view.gohtml:75
|
2023-03-01 13:08:12 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Discount"
|
|
|
|
|
msgstr "Descuento"
|
|
|
|
|
|
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/invoices/view.gohtml:66 web/template/quotes/view.gohtml:77
|
2023-02-24 11:22:15 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Units"
|
|
|
|
|
msgstr "Unidades"
|
|
|
|
|
|
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/invoices/view.gohtml:101 web/template/quotes/view.gohtml:112
|
2023-03-01 13:08:12 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Tax Base"
|
|
|
|
|
msgstr "Base imponible"
|
|
|
|
|
|
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”"
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgstr "Edición de la factura «%s»"
|
2023-03-13 14:00:35 +00:00
|
|
|
|
|
2023-06-16 08:58:40 +00:00
|
|
|
|
#: web/template/home.gohtml:9
|
|
|
|
|
msgid "If you want to sign in, just head to %sthe login page%s and enter your credentials in the form."
|
|
|
|
|
msgstr "Si quieres acceder a tu usuario solo tienes que ir a %sla página de entrada% y anotar tus credenciales a su sitio."
|
|
|
|
|
|
|
|
|
|
#: web/template/home.gohtml:12
|
|
|
|
|
msgid "manager"
|
|
|
|
|
msgstr "gestor"
|
|
|
|
|
|
|
|
|
|
#: web/template/home.gohtml:16
|
|
|
|
|
msgid "Tool to simplify management for small business and freelancers"
|
|
|
|
|
msgstr "Herramienta para simplificar la gestión de autónomos y pequeñas empresas."
|
|
|
|
|
|
|
|
|
|
#: web/template/home.gohtml:19
|
|
|
|
|
msgid "Reduce management time, take control of your balance."
|
|
|
|
|
msgstr "Reduce el tiempo de gestión, ten controlados tus números."
|
|
|
|
|
|
|
|
|
|
#: web/template/home.gohtml:20
|
|
|
|
|
msgid "application"
|
|
|
|
|
msgstr "aplicación"
|
2023-06-11 20:24:25 +00:00
|
|
|
|
|
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)"
|
|
|
|
|
|
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/form.gohtml:200
|
2023-05-26 11:38:04 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Filters"
|
|
|
|
|
msgstr "Filtrar"
|
|
|
|
|
|
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 "Panel"
|
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
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/dashboard.gohtml:29
|
2023-05-16 12:56:49 +00:00
|
|
|
|
msgctxt "term"
|
|
|
|
|
msgid "Sales"
|
|
|
|
|
msgstr "Ventas"
|
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/dashboard.gohtml:33
|
2023-05-16 12:56:49 +00:00
|
|
|
|
msgctxt "term"
|
|
|
|
|
msgid "Income"
|
|
|
|
|
msgstr "Ingresos"
|
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/dashboard.gohtml:37
|
2023-05-16 12:56:49 +00:00
|
|
|
|
msgctxt "term"
|
|
|
|
|
msgid "Expenses"
|
|
|
|
|
msgstr "Gastos"
|
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/dashboard.gohtml:41
|
2023-05-16 12:56:49 +00:00
|
|
|
|
msgctxt "term"
|
|
|
|
|
msgid "VAT"
|
|
|
|
|
msgstr "IVA"
|
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/dashboard.gohtml:45
|
2023-05-16 12:56:49 +00:00
|
|
|
|
msgctxt "term"
|
|
|
|
|
msgid "IRPF"
|
|
|
|
|
msgstr "IRPF"
|
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/dashboard.gohtml:49
|
2023-05-16 12:56:49 +00:00
|
|
|
|
msgctxt "term"
|
|
|
|
|
msgid "Net Income"
|
|
|
|
|
msgstr "Ingresos netos"
|
|
|
|
|
|
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 "Añadir productos al presupuesto"
|
|
|
|
|
|
|
|
|
|
#: 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 "Presupuestos"
|
|
|
|
|
|
|
|
|
|
#: 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 "Nuevo presupuesto"
|
|
|
|
|
|
|
|
|
|
#: web/template/quotes/index.gohtml:19
|
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Download quotations"
|
|
|
|
|
msgstr "Descargar presupuestos"
|
|
|
|
|
|
|
|
|
|
#: web/template/quotes/index.gohtml:21
|
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "New quotation"
|
|
|
|
|
msgstr "Nuevo presupuesto"
|
|
|
|
|
|
|
|
|
|
#: web/template/quotes/index.gohtml:49
|
|
|
|
|
msgctxt "quote"
|
|
|
|
|
msgid "All"
|
|
|
|
|
msgstr "Todos"
|
|
|
|
|
|
|
|
|
|
#: web/template/quotes/index.gohtml:51
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Quotation Num."
|
|
|
|
|
msgstr "N.º de presupuesto"
|
|
|
|
|
|
|
|
|
|
#: web/template/quotes/index.gohtml:64
|
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Select quotation %v"
|
|
|
|
|
msgstr "Seleccionar presupuesto %v"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/quotes/index.gohtml:112
|
|
|
|
|
msgid "Actions for quote %s"
|
|
|
|
|
msgstr "Acciones para el presupuesto %s"
|
|
|
|
|
|
|
|
|
|
#: web/template/quotes/index.gohtml:136 web/template/quotes/view.gohtml:16
|
2023-06-10 18:46:03 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Create invoice"
|
|
|
|
|
msgstr "Crear factura"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/quotes/index.gohtml:146
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "No quotations added yet."
|
|
|
|
|
msgstr "No hay presupuestos."
|
|
|
|
|
|
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 "Estado del presupuesto"
|
|
|
|
|
|
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 "Descargar presupuesto"
|
|
|
|
|
|
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 "Condiciones de aceptación:"
|
|
|
|
|
|
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ón del presupuesto «%s»"
|
|
|
|
|
|
2023-03-27 07:44:04 +00:00
|
|
|
|
#: web/template/app.gohtml:23
|
2023-01-30 15:48:21 +00:00
|
|
|
|
msgctxt "menu"
|
|
|
|
|
msgid "Account"
|
|
|
|
|
msgstr "Cuenta"
|
|
|
|
|
|
2023-03-27 07:44:04 +00:00
|
|
|
|
#: web/template/app.gohtml:29
|
2023-01-30 15:48:21 +00:00
|
|
|
|
msgctxt "menu"
|
|
|
|
|
msgid "Tax Details"
|
|
|
|
|
msgstr "Configuración fiscal"
|
|
|
|
|
|
2023-03-27 07:44:04 +00:00
|
|
|
|
#: web/template/app.gohtml:37
|
2023-01-30 15:48:21 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "Logout"
|
|
|
|
|
msgstr "Salir"
|
|
|
|
|
|
2023-03-27 07:44:04 +00:00
|
|
|
|
#: web/template/app.gohtml:46
|
2023-01-30 15:48:21 +00:00
|
|
|
|
msgctxt "nav"
|
2023-01-31 12:29:56 +00:00
|
|
|
|
msgid "Dashboard"
|
|
|
|
|
msgstr "Panel"
|
|
|
|
|
|
2023-03-27 07:44:04 +00:00
|
|
|
|
#: web/template/app.gohtml:47
|
2023-01-31 12:29:56 +00:00
|
|
|
|
msgctxt "nav"
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Quotations"
|
|
|
|
|
msgstr "Presupuestos"
|
|
|
|
|
|
|
|
|
|
#: web/template/app.gohtml:48
|
|
|
|
|
msgctxt "nav"
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgid "Invoices"
|
|
|
|
|
msgstr "Facturas"
|
|
|
|
|
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/app.gohtml:49
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgctxt "nav"
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgid "Expenses"
|
|
|
|
|
msgstr "Gastos"
|
|
|
|
|
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/app.gohtml:50
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgctxt "nav"
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgid "Products"
|
|
|
|
|
msgstr "Productos"
|
|
|
|
|
|
2023-06-07 14:35:31 +00:00
|
|
|
|
#: web/template/app.gohtml:51
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "nav"
|
2023-02-01 09:14:26 +00:00
|
|
|
|
msgid "Contacts"
|
|
|
|
|
msgstr "Contactos"
|
2023-01-30 15:48:21 +00:00
|
|
|
|
|
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 "Nuevo contacto"
|
|
|
|
|
|
|
|
|
|
#: 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"
|
|
|
|
|
msgid "Contacts"
|
|
|
|
|
msgstr "Contactos"
|
|
|
|
|
|
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 "Importar"
|
|
|
|
|
|
|
|
|
|
#: web/template/contacts/index.gohtml:17
|
|
|
|
|
msgctxt "action"
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgid "New contact"
|
|
|
|
|
msgstr "Nuevo contacto"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/contacts/index.gohtml:42 web/template/expenses/index.gohtml:42
|
2023-06-20 09:33:28 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Contact"
|
|
|
|
|
msgstr "Contacto"
|
|
|
|
|
|
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/index.gohtml:43
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Email"
|
|
|
|
|
msgstr "Correo-e"
|
|
|
|
|
|
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/index.gohtml:44
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Phone"
|
|
|
|
|
msgstr "Teléfono"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/contacts/index.gohtml:69
|
|
|
|
|
msgid "Actions for contact %s"
|
|
|
|
|
msgstr "Acciones para el contacto %s"
|
|
|
|
|
|
|
|
|
|
#: web/template/contacts/index.gohtml:87
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgid "No contacts added yet."
|
|
|
|
|
msgstr "No hay contactos."
|
|
|
|
|
|
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ón del contacto «%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ón de contactos"
|
|
|
|
|
|
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 "Entrar"
|
|
|
|
|
|
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ón usuario"
|
|
|
|
|
|
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 "Datos acceso usuario"
|
|
|
|
|
|
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 "Cambio de contraseña"
|
|
|
|
|
|
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 "Guardar cambios"
|
|
|
|
|
|
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 "Nuevo gasto"
|
|
|
|
|
|
|
|
|
|
#: 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 "Gastos"
|
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/expenses/index.gohtml:16
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "New expense"
|
|
|
|
|
msgstr "Nuevo gasto"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/expenses/index.gohtml:43
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Invoice Date"
|
|
|
|
|
msgstr "Fecha de factura"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/expenses/index.gohtml:44
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Invoice Number"
|
|
|
|
|
msgstr "Número de factura"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/expenses/index.gohtml:79
|
|
|
|
|
msgid "Actions for expense %s"
|
|
|
|
|
msgstr "Acciones para el gasto %s"
|
|
|
|
|
|
|
|
|
|
#: web/template/expenses/index.gohtml:97
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgid "No expenses added yet."
|
|
|
|
|
msgstr "No hay gastos."
|
|
|
|
|
|
|
|
|
|
#: web/template/expenses/edit.gohtml:3 web/template/expenses/edit.gohtml:20
|
|
|
|
|
msgctxt "title"
|
|
|
|
|
msgid "Edit Expense “%s”"
|
|
|
|
|
msgstr "Edición del gasto «%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ón 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ón y presupuestos"
|
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 "¿Estáis seguro?"
|
|
|
|
|
|
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"
|
|
|
|
|
msgstr "Nombre impuesto"
|
|
|
|
|
|
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 (%)"
|
2023-02-03 12:29:10 +00:00
|
|
|
|
msgstr "Porcentaje"
|
2023-01-28 13:18:58 +00:00
|
|
|
|
|
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 "Clase"
|
|
|
|
|
|
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 hay impuestos."
|
|
|
|
|
|
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 "Nueva línea"
|
|
|
|
|
|
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 "Añadir nuevo impuesto"
|
|
|
|
|
|
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étodo de pago"
|
|
|
|
|
|
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 "Instrucciones"
|
|
|
|
|
|
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 hay métodos de pago."
|
|
|
|
|
|
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 "Añadir nuevo método de pago"
|
|
|
|
|
|
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 "Nuevo producto"
|
|
|
|
|
|
|
|
|
|
#: 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 "Productos"
|
|
|
|
|
|
2023-04-27 22:06:48 +00:00
|
|
|
|
#: web/template/products/search.gohtml:12
|
|
|
|
|
msgid "No products found."
|
|
|
|
|
msgstr "No se ha encontrado ningún producto."
|
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#: web/template/products/index.gohtml:15
|
|
|
|
|
msgctxt "action"
|
|
|
|
|
msgid "New product"
|
|
|
|
|
msgstr "Nuevo producto"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: web/template/products/index.gohtml:65
|
|
|
|
|
msgid "Actions for product %s"
|
|
|
|
|
msgstr "Acciones para el producto %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ón del producto «%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
|
|
|
|
#: pkg/login.go:37 pkg/company.go:127 pkg/profile.go:40 pkg/contacts.go:262
|
2023-02-03 12:29:10 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Email"
|
|
|
|
|
msgstr "Correo-e"
|
|
|
|
|
|
2023-06-16 08:58:40 +00:00
|
|
|
|
#: pkg/login.go:48 pkg/profile.go:49
|
2023-02-01 10:02:32 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Password"
|
|
|
|
|
msgstr "Contraseña"
|
|
|
|
|
|
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/login.go:70 pkg/company.go:283 pkg/profile.go:89
|
2023-02-01 10:02:32 +00:00
|
|
|
|
msgid "Email can not be empty."
|
|
|
|
|
msgstr "No podéis dejar el correo-e en blanco."
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: pkg/login.go:71 pkg/company.go:284 pkg/profile.go:90 pkg/contacts.go:406
|
2023-02-01 10:02:32 +00:00
|
|
|
|
msgid "This value is not a valid email. It should be like name@domain.com."
|
|
|
|
|
msgstr "Este valor no es un correo-e válido. Tiene que ser parecido a nombre@dominio.es."
|
|
|
|
|
|
2023-06-16 08:58:40 +00:00
|
|
|
|
#: pkg/login.go:73
|
2023-02-01 10:02:32 +00:00
|
|
|
|
msgid "Password can not be empty."
|
2023-02-03 12:29:10 +00:00
|
|
|
|
msgstr "No podéis dejar la contraseña en blanco."
|
2023-02-01 10:02:32 +00:00
|
|
|
|
|
2023-06-16 08:58:40 +00:00
|
|
|
|
#: pkg/login.go:109
|
2023-02-01 10:02:32 +00:00
|
|
|
|
msgid "Invalid user or password."
|
|
|
|
|
msgstr "Nombre de usuario o contraseña inválido."
|
|
|
|
|
|
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/products.go:164 pkg/products.go:263 pkg/quote.go:823 pkg/invoices.go:909
|
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
|
|
|
|
#: pkg/contacts.go:140 pkg/contacts.go:248
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Name"
|
|
|
|
|
msgstr "Nombre"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/products.go:169 pkg/products.go:290 pkg/quote.go:174 pkg/quote.go:630
|
|
|
|
|
#: pkg/expenses.go:188 pkg/expenses.go:347 pkg/invoices.go:174
|
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
|
|
|
|
#: pkg/invoices.go:657 pkg/invoices.go:1208 pkg/contacts.go:145
|
|
|
|
|
#: pkg/contacts.go:348
|
2023-04-27 22:06:48 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Tags"
|
|
|
|
|
msgstr "Etiquetes"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/products.go:173 pkg/quote.go:178 pkg/expenses.go:351 pkg/invoices.go:178
|
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
|
|
|
|
#: pkg/contacts.go:149
|
2023-04-27 22:06:48 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Tags Condition"
|
|
|
|
|
msgstr "Condición de las etiquetas"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/products.go:177 pkg/quote.go:182 pkg/expenses.go:355 pkg/invoices.go:182
|
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
|
|
|
|
#: pkg/contacts.go:153
|
2023-04-27 22:06:48 +00:00
|
|
|
|
msgctxt "tag condition"
|
|
|
|
|
msgid "All"
|
|
|
|
|
msgstr "Todas"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/products.go:178 pkg/expenses.go:356 pkg/invoices.go:183
|
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
|
|
|
|
#: pkg/contacts.go:154
|
2023-04-27 22:06:48 +00:00
|
|
|
|
msgid "Invoices must have all the specified labels."
|
|
|
|
|
msgstr "Las facturas deben tener todas las etiquetas."
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/products.go:182 pkg/quote.go:187 pkg/expenses.go:360 pkg/invoices.go:187
|
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
|
|
|
|
#: pkg/contacts.go:158
|
2023-04-27 22:06:48 +00:00
|
|
|
|
msgctxt "tag condition"
|
|
|
|
|
msgid "Any"
|
|
|
|
|
msgstr "Cualquiera"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/products.go:183 pkg/expenses.go:361 pkg/invoices.go:188
|
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
|
|
|
|
#: pkg/contacts.go:159
|
2023-04-27 22:06:48 +00:00
|
|
|
|
msgid "Invoices must have at least one of the specified labels."
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgstr "Las facturas deben tener como mínimo una de las etiquetas."
|
2023-04-27 22:06:48 +00:00
|
|
|
|
|
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/products.go:269 pkg/quote.go:837 pkg/invoices.go:923
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Description"
|
|
|
|
|
msgstr "Descripción"
|
|
|
|
|
|
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/products.go:274 pkg/quote.go:841 pkg/invoices.go:927
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Price"
|
|
|
|
|
msgstr "Precio"
|
|
|
|
|
|
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/products.go:284 pkg/quote.go:870 pkg/expenses.go:167 pkg/invoices.go:956
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgctxt "input"
|
2023-02-08 12:47:36 +00:00
|
|
|
|
msgid "Taxes"
|
|
|
|
|
msgstr "Impuestos"
|
2023-02-04 10:32:39 +00:00
|
|
|
|
|
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/products.go:309 pkg/quote.go:919 pkg/profile.go:92 pkg/invoices.go:1005
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: pkg/contacts.go:398
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgid "Name can not be empty."
|
|
|
|
|
msgstr "No podéis dejar el nombre en blanco."
|
|
|
|
|
|
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/products.go:310 pkg/quote.go:920 pkg/invoices.go:1006
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgid "Price can not be empty."
|
|
|
|
|
msgstr "No podéis dejar el precio en blanco."
|
|
|
|
|
|
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/products.go:311 pkg/quote.go:921 pkg/invoices.go:1007
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgid "Price must be a number greater than zero."
|
|
|
|
|
msgstr "El precio tiene que ser un número mayor a cero."
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/products.go:313 pkg/quote.go:929 pkg/expenses.go:213 pkg/expenses.go:218
|
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/invoices.go:1015
|
2023-02-04 10:32:39 +00:00
|
|
|
|
msgid "Selected tax is not valid."
|
|
|
|
|
msgstr "Habéis escogido un impuesto que no es válido."
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/products.go:314 pkg/quote.go:930 pkg/expenses.go:214 pkg/expenses.go:219
|
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/invoices.go:1016
|
2023-03-01 13:08:12 +00:00
|
|
|
|
msgid "You can only select a tax of each class."
|
2023-03-04 21:15:52 +00:00
|
|
|
|
msgstr "Solo podéis escoger un impuesto de cada clase."
|
2023-03-01 13:08:12 +00:00
|
|
|
|
|
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 "Nombre comercial"
|
|
|
|
|
|
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
|
|
|
|
#: pkg/company.go:118 pkg/contacts.go:254
|
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éfono"
|
|
|
|
|
|
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
|
|
|
|
#: pkg/company.go:136 pkg/contacts.go:270
|
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"
|
|
|
|
|
|
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
|
|
|
|
#: pkg/company.go:144 pkg/contacts.go:282
|
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 "Nombre y apellidos"
|
|
|
|
|
|
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
|
|
|
|
#: pkg/company.go:154 pkg/contacts.go:292
|
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"
|
|
|
|
|
|
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
|
|
|
|
#: pkg/company.go:160 pkg/contacts.go:298
|
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 "Dirección"
|
|
|
|
|
|
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
|
|
|
|
#: pkg/company.go:169 pkg/contacts.go:307
|
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ón"
|
|
|
|
|
|
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
|
|
|
|
#: pkg/company.go:175 pkg/contacts.go:313
|
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 "Provincia"
|
|
|
|
|
|
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
|
|
|
|
#: pkg/company.go:181 pkg/contacts.go:319
|
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 "Código postal"
|
|
|
|
|
|
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
|
|
|
|
#: pkg/company.go:190 pkg/contacts.go:328
|
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 "Formato 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"
|
2023-06-09 10:43:50 +00:00
|
|
|
|
msgstr "Siguiente 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 "Formato del número de presupuesto"
|
2023-06-07 14:35:31 +00:00
|
|
|
|
|
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 "Siguiente número de presupuesto"
|
|
|
|
|
|
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"
|
|
|
|
|
|
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
|
|
|
|
#: pkg/company.go:271 pkg/contacts.go:380
|
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 "Habéis escogido un país que no es válido."
|
|
|
|
|
|
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
|
|
|
|
#: pkg/company.go:275 pkg/contacts.go:383
|
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 podéis dejar el nombre y los apellidos en blanco."
|
|
|
|
|
|
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
|
|
|
|
#: pkg/company.go:276 pkg/contacts.go:384
|
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 "El nombre y los apellidos deben contener como mínimo dos letras."
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: pkg/company.go:277 pkg/contacts.go:386
|
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 podéis dejar el DNI o NIF en blanco."
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: pkg/company.go:278 pkg/contacts.go:387
|
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 "Este valor no es un DNI o NIF válido."
|
|
|
|
|
|
|
|
|
|
#: pkg/company.go:280
|
|
|
|
|
msgid "Phone can not be empty."
|
|
|
|
|
msgstr "No podéis dejar el teléfono en blanco."
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: pkg/company.go:281 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 "This value is not a valid phone number."
|
|
|
|
|
msgstr "Este valor no es un teléfono válido."
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: pkg/company.go:287 pkg/contacts.go:409
|
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 "Este valor no es una dirección web válida. Tiene que ser parecida a https://dominio.es/."
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: pkg/company.go:289 pkg/contacts.go:389
|
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 podéis dejar la dirección en blanco."
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: pkg/company.go:290 pkg/contacts.go:390
|
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 podéis dejar la población en blanco."
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: pkg/company.go:291 pkg/contacts.go:391
|
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 podéis dejar la provincia en blanco."
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: pkg/company.go:292 pkg/contacts.go:393
|
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 podéis dejar el código postal en blanco."
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: pkg/company.go:293 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 "This value is not a valid postal code."
|
|
|
|
|
msgstr "Este valor no es un código postal válido válido."
|
|
|
|
|
|
|
|
|
|
#: pkg/company.go:295
|
2023-02-03 12:29:10 +00:00
|
|
|
|
msgid "Selected currency is not valid."
|
|
|
|
|
msgstr "Habéis escogido una moneda que no es 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 podéis dejar el formato del número de factura en blanco."
|
|
|
|
|
|
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 siguiente número de factura tiene que ser un número mayor a cero."
|
|
|
|
|
|
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 podéis dejar el formato del número de presupuesto en blanco."
|
|
|
|
|
|
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 siguiente número de presupuesto tiene que ser un número mayor a cero."
|
|
|
|
|
|
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 "Nombre impuesto"
|
|
|
|
|
|
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 "Clase de impuesto"
|
|
|
|
|
|
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 "Escoged una clase de impuesto"
|
|
|
|
|
|
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 "Porcentaje"
|
|
|
|
|
|
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 podéis dejar el nombre del impuesto en blanco."
|
|
|
|
|
|
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 "Habéis escogido una clase impuesto que no es 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 podéis dejar el porcentaje en blanco."
|
|
|
|
|
|
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 porcentaje tiene que estar entre -99 y 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 "Nombre del método de pago"
|
|
|
|
|
|
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 "Instrucciones"
|
|
|
|
|
|
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 podéis dejar el nombre del método de pago en blanco."
|
|
|
|
|
|
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 podéis dejar las instrucciones de pago en blanco."
|
|
|
|
|
|
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/quote.go:147 pkg/quote.go:608 pkg/invoices.go:147 pkg/invoices.go:640
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
2023-06-20 09:37:02 +00:00
|
|
|
|
msgid "Customer"
|
|
|
|
|
msgstr "Cliente"
|
2023-06-07 14:35:31 +00:00
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:148 pkg/invoices.go:148
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "All customers"
|
|
|
|
|
msgstr "Todos los clientes"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:153 pkg/quote.go:602
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Quotation Status"
|
|
|
|
|
msgstr "Estado del presupuesto"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:154 pkg/invoices.go:154
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "All status"
|
|
|
|
|
msgstr "Todos los estados"
|
|
|
|
|
|
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 presupuesto"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:164 pkg/expenses.go:337 pkg/invoices.go:164
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "From Date"
|
|
|
|
|
msgstr "A partir de la fecha"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:169 pkg/expenses.go:342 pkg/invoices.go:169
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "To Date"
|
|
|
|
|
msgstr "Hasta la fecha"
|
|
|
|
|
|
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 "Los presupuestos deben tener todas las etiquetas."
|
|
|
|
|
|
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 "Los presupuestos deben tener como mínimo una de las etiquetas."
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:550
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "quotations.zip"
|
|
|
|
|
msgstr "presupuestos.zip"
|
|
|
|
|
|
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/quote.go:556 pkg/quote.go:1085 pkg/quote.go:1093 pkg/invoices.go:589
|
|
|
|
|
#: pkg/invoices.go:1183 pkg/invoices.go:1191
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Invalid action"
|
|
|
|
|
msgstr "Acción inválida."
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:609
|
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 "Escoged un cliente a presupuestar."
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:614
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Quotation Date"
|
|
|
|
|
msgstr "Fecha del presupuesto"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:620
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Terms and conditions"
|
|
|
|
|
msgstr "Condiciones de aceptación"
|
|
|
|
|
|
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/quote.go:625 pkg/invoices.go:652
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Notes"
|
|
|
|
|
msgstr "Notas"
|
|
|
|
|
|
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/quote.go:634 pkg/invoices.go:662
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Payment Method"
|
|
|
|
|
msgstr "Método de pago"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:635
|
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 "Escoged un método e pago."
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:671
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Selected quotation status is not valid."
|
|
|
|
|
msgstr "Habéis escogido un estado de presupuesto que no es válido."
|
|
|
|
|
|
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/quote.go:673 pkg/invoices.go:699
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Selected customer is not valid."
|
|
|
|
|
msgstr "Habéis escogido un cliente que no es válido."
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:675
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Quotation date can not be empty."
|
|
|
|
|
msgstr "No podéis dejar la fecha del presupuesto en blanco."
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:676
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Quotation date must be a valid date."
|
|
|
|
|
msgstr "La fecha de presupuesto debe ser 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/quote.go:679 pkg/invoices.go:703
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Selected payment method is not valid."
|
|
|
|
|
msgstr "Habéis escogido un método de pago que no es válido."
|
|
|
|
|
|
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/quote.go:813 pkg/quote.go:818 pkg/invoices.go:899 pkg/invoices.go:904
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Id"
|
|
|
|
|
msgstr "Identificador"
|
|
|
|
|
|
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/quote.go:851 pkg/invoices.go:937
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Quantity"
|
|
|
|
|
msgstr "Cantidad"
|
|
|
|
|
|
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/quote.go:860 pkg/invoices.go:946
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Discount (%)"
|
|
|
|
|
msgstr "Descuento (%)"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/quote.go:914
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Quotation product ID must be a number greater than zero."
|
|
|
|
|
msgstr "El ID de producto de presupuesto tiene que ser un número mayor a cero."
|
|
|
|
|
|
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/quote.go:917 pkg/invoices.go:1003
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Product ID must be a positive number or zero."
|
|
|
|
|
msgstr "El ID de producto tiene que ser un número positivo o cero."
|
|
|
|
|
|
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/quote.go:923 pkg/invoices.go:1009
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Quantity can not be empty."
|
|
|
|
|
msgstr "No podéis dejar la cantidad en blanco."
|
|
|
|
|
|
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/quote.go:924 pkg/invoices.go:1010
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Quantity must be a number greater than zero."
|
|
|
|
|
msgstr "La cantidad tiene que ser un número mayor a cero."
|
|
|
|
|
|
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/quote.go:926 pkg/invoices.go:1012
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Discount can not be empty."
|
|
|
|
|
msgstr "No podéis dejar el descuento en blanco."
|
|
|
|
|
|
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/quote.go:927 pkg/invoices.go:1013
|
2023-06-07 14:35:31 +00:00
|
|
|
|
msgid "Discount must be a percentage between 0 and 100."
|
|
|
|
|
msgstr "El descuento tiene que ser un porcentaje entre 0 y 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ático"
|
|
|
|
|
|
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 "Nombre de usuario"
|
|
|
|
|
|
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"
|
2023-02-03 12:29:10 +00:00
|
|
|
|
msgstr "Confirmación contraseña"
|
2023-01-31 14:40:12 +00:00
|
|
|
|
|
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ón no corresponde con la contraseña."
|
|
|
|
|
|
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 "Habéis escogido un idioma que no es válido."
|
2023-02-01 09:14:26 +00:00
|
|
|
|
|
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 "Periodo"
|
|
|
|
|
|
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 "Año"
|
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 "Año anterior"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/expenses.go:115
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgid "Select a contact."
|
|
|
|
|
msgstr "Escoged un contacto"
|
|
|
|
|
|
2023-06-20 09:37:02 +00:00
|
|
|
|
#: pkg/expenses.go:150 pkg/expenses.go:326
|
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Contact"
|
|
|
|
|
msgstr "Contacto"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/expenses.go:156
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Invoice number"
|
|
|
|
|
msgstr "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/expenses.go:161 pkg/invoices.go:646
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Invoice Date"
|
|
|
|
|
msgstr "Fecha de factura"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/expenses.go:173
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Amount"
|
|
|
|
|
msgstr "Importe"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/expenses.go:183
|
2023-05-16 12:56:49 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "File"
|
|
|
|
|
msgstr "Archivo"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/expenses.go:211
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgid "Selected contact is not valid."
|
|
|
|
|
msgstr "Habéis escogido un contacto que no es válido."
|
|
|
|
|
|
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/expenses.go:212 pkg/invoices.go:701
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgid "Invoice date must be a valid date."
|
|
|
|
|
msgstr "La fecha de factura debe ser válida."
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/expenses.go:215
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgid "Amount can not be empty."
|
|
|
|
|
msgstr "No podéis dejar el importe en blanco."
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/expenses.go:216
|
2023-05-03 10:46:25 +00:00
|
|
|
|
msgid "Amount must be a number greater than zero."
|
|
|
|
|
msgstr "El importe tiene que ser un número mayor a cero."
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/expenses.go:327
|
2023-06-20 09:17:07 +00:00
|
|
|
|
msgid "All contacts"
|
|
|
|
|
msgstr "Todos los contactos"
|
|
|
|
|
|
2023-06-20 09:33:28 +00:00
|
|
|
|
#: pkg/expenses.go:332 pkg/invoices.go:159
|
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"
|
|
|
|
|
|
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/invoices.go:153 pkg/invoices.go:634
|
2023-05-11 21:32:21 +00:00
|
|
|
|
msgctxt "input"
|
|
|
|
|
msgid "Invoice Status"
|
|
|
|
|
msgstr "Estado de la 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/invoices.go:482
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgid "Select a customer to bill."
|
|
|
|
|
msgstr "Escoged un cliente a facturar."
|
|
|
|
|
|
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/invoices.go:583
|
2023-03-13 14:00:35 +00:00
|
|
|
|
msgid "invoices.zip"
|
|
|
|
|
msgstr "facturas.zip"
|
|
|
|
|
|
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/invoices.go:698
|
2023-03-13 14:00:35 +00:00
|
|
|
|
msgid "Selected invoice status is not valid."
|
|
|
|
|
msgstr "Habéis escogido un estado de factura que no es válido."
|
|
|
|
|
|
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/invoices.go:700
|
2023-02-12 20:06:48 +00:00
|
|
|
|
msgid "Invoice date can not be empty."
|
|
|
|
|
msgstr "No podéis dejar la fecha de la factura en blanco."
|
|
|
|
|
|
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/invoices.go:836
|
2023-06-10 18:46:03 +00:00
|
|
|
|
#, c-format
|
|
|
|
|
msgid "Re: quotation #%s of %s"
|
|
|
|
|
msgstr "Ref: presupuesto n.º %s del %s"
|
|
|
|
|
|
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/invoices.go:837
|
2023-06-10 18:46:03 +00:00
|
|
|
|
msgctxt "to_char"
|
|
|
|
|
msgid "MM/DD/YYYY"
|
|
|
|
|
msgstr "DD/MM/YYYY"
|
|
|
|
|
|
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/invoices.go:1000
|
2023-05-22 09:16:21 +00:00
|
|
|
|
msgid "Invoice product ID must be a number greater than zero."
|
|
|
|
|
msgstr "El ID de producto de factura tiene que ser un número mayor a cero."
|
|
|
|
|
|
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
|
|
|
|
#: pkg/contacts.go:278
|
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 "Necesito facturar este contacto"
|
2023-02-08 12:47:36 +00:00
|
|
|
|
|
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
|
|
|
|
#: pkg/contacts.go:338
|
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 "input"
|
|
|
|
|
msgid "IBAN"
|
|
|
|
|
msgstr "IBAN"
|
|
|
|
|
|
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
|
|
|
|
#: pkg/contacts.go:343
|
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"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: pkg/contacts.go:399
|
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 nombre debe contener como mínimo dos letras."
|
2023-02-03 12:29:10 +00:00
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: pkg/contacts.go:412
|
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 "Este valor no es un IBAN válido."
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: pkg/contacts.go:415
|
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 "Este valor no es un BIC válido."
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#: pkg/contacts.go:529
|
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 "Archivo Excel de Holded"
|
|
|
|
|
|
2023-07-06 09:49:36 +00:00
|
|
|
|
#~ msgctxt "expense"
|
|
|
|
|
#~ msgid "All"
|
|
|
|
|
#~ msgstr "Todos"
|
|
|
|
|
|
2023-05-26 11:38:04 +00:00
|
|
|
|
#~ msgctxt "action"
|
|
|
|
|
#~ msgid "Update contact"
|
|
|
|
|
#~ msgstr "Actualizar contacto"
|
|
|
|
|
|
|
|
|
|
#~ msgctxt "action"
|
|
|
|
|
#~ msgid "Update expense"
|
|
|
|
|
#~ msgstr "Actualizar gasto"
|
|
|
|
|
|
|
|
|
|
#~ msgctxt "action"
|
|
|
|
|
#~ msgid "Update product"
|
|
|
|
|
#~ msgstr "Actualizar producto"
|
|
|
|
|
|
2023-05-23 12:21:04 +00:00
|
|
|
|
#~ msgctxt "action"
|
|
|
|
|
#~ msgid "Edit invoice"
|
|
|
|
|
#~ msgstr "Editar factura"
|
|
|
|
|
|
|
|
|
|
#~ msgctxt "contact"
|
|
|
|
|
#~ msgid "All"
|
|
|
|
|
#~ msgstr "Todos"
|
|
|
|
|
|
2023-04-27 22:06:48 +00:00
|
|
|
|
#~ msgid "Product ID can not be empty."
|
|
|
|
|
#~ msgstr "No podéis dejar el identificador de producto en blanco."
|
|
|
|
|
|
2023-04-15 02:05:59 +00:00
|
|
|
|
#~ msgctxt "input"
|
|
|
|
|
#~ msgid "Number"
|
|
|
|
|
#~ msgstr "Número"
|
|
|
|
|
|
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 "Escoged un impuesto para este producto."
|
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 "Impuesto"
|
2023-02-04 10:32:39 +00:00
|
|
|
|
|
2023-02-01 09:14:26 +00:00
|
|
|
|
#~ msgctxt "title"
|
|
|
|
|
#~ msgid "Customers"
|
|
|
|
|
#~ msgstr "Clientes"
|
|
|
|
|
|
|
|
|
|
#~ msgid "No customers added yet."
|
|
|
|
|
#~ msgstr "No hay clientes."
|