numerus/po/es.po

1671 lines
44 KiB
Plaintext
Raw Normal View History

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"
2024-08-15 23:58:59 +00:00
"POT-Creation-Date: 2024-08-16 01:57+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"
#: web/template/invoices/products.gohtml:2
#: web/template/invoices/products.gohtml:23
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
#: web/template/invoices/index.gohtml:9 web/template/invoices/view.gohtml:9
#: 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
#: 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/company/taxes.gohtml:10
#: web/template/company/switch.gohtml:9
#: web/template/company/tax-details.gohtml:9
#: web/template/company/invoicing.gohtml:10
#: web/template/company/payment_methods.gohtml:10
#: web/template/products/new.gohtml:9 web/template/products/index.gohtml:9
#: web/template/products/edit.gohtml:10 web/template/payments/new.gohtml:10
#: web/template/payments/index.gohtml:10 web/template/payments/edit.gohtml:10
#: web/template/payments/accounts/new.gohtml:10
#: web/template/payments/accounts/index.gohtml:10
#: web/template/payments/accounts/edit.gohtml:10
msgctxt "title"
msgid "Home"
msgstr "Inicio"
#: web/template/invoices/products.gohtml:10 web/template/invoices/new.gohtml:10
#: web/template/invoices/index.gohtml:2 web/template/invoices/index.gohtml:10
#: web/template/invoices/view.gohtml:10 web/template/invoices/edit.gohtml:10
msgctxt "title"
msgid "Invoices"
msgstr "Facturas"
#: web/template/invoices/products.gohtml:12 web/template/invoices/new.gohtml:2
#: web/template/invoices/new.gohtml:11 web/template/invoices/new.gohtml:19
msgctxt "title"
msgid "New Invoice"
msgstr "Nueva factura"
#: web/template/invoices/products.gohtml:48
#: web/template/quotes/products.gohtml:48
msgctxt "product"
msgid "All"
msgstr "Todos"
#: web/template/invoices/products.gohtml:49
#: web/template/quotes/products.gohtml:49 web/template/company/switch.gohtml:22
#: web/template/products/index.gohtml:45
#: web/template/payments/accounts/index.gohtml:25
msgctxt "title"
msgid "Name"
msgstr "Nombre"
#: web/template/invoices/products.gohtml:50
#: web/template/invoices/view.gohtml:66 web/template/quotes/products.gohtml:50
#: web/template/quotes/view.gohtml:73 web/template/products/index.gohtml:47
msgctxt "title"
msgid "Price"
msgstr "Precio"
#: web/template/invoices/products.gohtml:64
#: web/template/quotes/products.gohtml:64 web/template/products/index.gohtml:88
msgid "No products added yet."
msgstr "No hay productos."
#: web/template/invoices/products.gohtml:72 web/template/invoices/new.gohtml:88
#: web/template/invoices/edit.gohtml:89 web/template/quotes/products.gohtml:72
#: web/template/quotes/new.gohtml:88 web/template/quotes/edit.gohtml:89
msgctxt "action"
msgid "Add products"
msgstr "Añadir productos"
#: 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»"
#: 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"
#: web/template/invoices/new.gohtml:64 web/template/invoices/view.gohtml:71
#: web/template/invoices/edit.gohtml:65 web/template/quotes/new.gohtml:64
#: web/template/quotes/view.gohtml:78 web/template/quotes/edit.gohtml:65
msgctxt "title"
msgid "Subtotal"
msgstr "Subtotal"
#: web/template/invoices/new.gohtml:74 web/template/invoices/view.gohtml:75
#: web/template/invoices/view.gohtml:115 web/template/invoices/edit.gohtml:75
#: web/template/quotes/new.gohtml:74 web/template/quotes/view.gohtml:82
#: web/template/quotes/view.gohtml:122 web/template/quotes/edit.gohtml:75
#: web/template/expenses/new.gohtml:46 web/template/expenses/index.gohtml:74
#: web/template/expenses/edit.gohtml:48 web/template/payments/index.gohtml:30
msgctxt "title"
msgid "Total"
msgstr "Total"
#: web/template/invoices/new.gohtml:92 web/template/invoices/edit.gohtml:93
#: web/template/quotes/new.gohtml:92 web/template/quotes/edit.gohtml:93
#: web/template/expenses/new.gohtml:56 web/template/expenses/edit.gohtml:58
2024-08-11 22:08:18 +00:00
#: web/template/payments/edit.gohtml:37
#: web/template/payments/accounts/edit.gohtml:38
msgctxt "action"
msgid "Update"
msgstr "Actualizar"
#: web/template/invoices/new.gohtml:95 web/template/invoices/edit.gohtml:96
#: web/template/quotes/new.gohtml:95 web/template/quotes/edit.gohtml:96
#: web/template/contacts/new.gohtml:49 web/template/contacts/edit.gohtml:53
#: web/template/expenses/new.gohtml:59 web/template/expenses/edit.gohtml:61
#: web/template/products/new.gohtml:30 web/template/products/edit.gohtml:36
2024-08-11 22:08:18 +00:00
#: web/template/payments/new.gohtml:35
#: web/template/payments/accounts/new.gohtml:41
msgctxt "action"
msgid "Save"
msgstr "Guardad"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:28
msgctxt "action"
msgid "Download invoices"
msgstr "Descargar facturas"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:31 web/template/quotes/index.gohtml:31
#: web/template/expenses/index.gohtml:29
msgctxt "action"
msgid "Export list"
msgstr "Exportar listado"
#: web/template/invoices/index.gohtml:33
msgctxt "action"
msgid "New invoice"
msgstr "Nueva factura"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:57 web/template/dashboard.gohtml:23
#: web/template/quotes/index.gohtml:57 web/template/contacts/index.gohtml:38
#: web/template/expenses/index.gohtml:56 web/template/products/index.gohtml:36
msgctxt "action"
msgid "Filter"
msgstr "Filtrar"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:60 web/template/quotes/index.gohtml:60
#: web/template/contacts/index.gohtml:41 web/template/expenses/index.gohtml:59
#: web/template/products/index.gohtml:39
msgctxt "action"
msgid "Reset"
msgstr "Restablecer"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:66
msgctxt "invoice"
msgid "All"
msgstr "Todas"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:67 web/template/invoices/view.gohtml:38
#: web/template/quotes/index.gohtml:67 web/template/quotes/view.gohtml:37
msgctxt "title"
msgid "Date"
msgstr "Fecha"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:68
msgctxt "title"
msgid "Invoice Num."
msgstr "N.º factura"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:69 web/template/quotes/index.gohtml:69
msgctxt "title"
msgid "Customer"
msgstr "Cliente"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:70 web/template/quotes/index.gohtml:70
#: web/template/expenses/index.gohtml:68 web/template/payments/index.gohtml:28
msgctxt "title"
msgid "Status"
msgstr "Estado"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:71 web/template/quotes/index.gohtml:71
#: web/template/contacts/index.gohtml:50 web/template/expenses/index.gohtml:69
#: web/template/products/index.gohtml:46 web/template/payments/index.gohtml:29
msgctxt "title"
msgid "Tags"
msgstr "Etiquetes"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:72 web/template/quotes/index.gohtml:72
#: web/template/expenses/index.gohtml:70
msgctxt "title"
msgid "Amount"
msgstr "Importe"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:73 web/template/quotes/index.gohtml:73
#: web/template/expenses/index.gohtml:75 web/template/payments/index.gohtml:31
msgctxt "title"
msgid "Download"
msgstr "Descargar"
#: web/template/invoices/index.gohtml:74 web/template/quotes/index.gohtml:74
#: web/template/contacts/index.gohtml:51 web/template/expenses/index.gohtml:76
#: web/template/company/switch.gohtml:23 web/template/products/index.gohtml:48
#: web/template/payments/index.gohtml:32
msgctxt "title"
msgid "Actions"
msgstr "Acciones"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:81
msgctxt "action"
msgid "Select invoice %v"
msgstr "Seleccionar factura %v"
#: web/template/invoices/index.gohtml:123
msgctxt "action"
msgid "Download invoice %s"
msgstr "Descargar factura %s"
#: web/template/invoices/index.gohtml:131
msgid "Actions for invoice %s"
msgstr "Acciones para la factura %s"
#: web/template/invoices/index.gohtml:139 web/template/invoices/view.gohtml:19
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:137 web/template/quotes/view.gohtml:22
2024-08-15 23:58:59 +00:00
#: web/template/contacts/index.gohtml:82 web/template/expenses/index.gohtml:125
#: web/template/products/index.gohtml:78 web/template/payments/index.gohtml:77
msgctxt "action"
msgid "Edit"
msgstr "Editar"
#: web/template/invoices/index.gohtml:147 web/template/invoices/view.gohtml:16
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:145 web/template/quotes/view.gohtml:19
msgctxt "action"
msgid "Duplicate"
msgstr "Duplicar"
#: web/template/invoices/index.gohtml:157
msgid "No invoices added yet."
msgstr "No hay facturas."
#: web/template/invoices/index.gohtml:164 web/template/quotes/index.gohtml:170
2024-08-15 23:58:59 +00:00
#: web/template/expenses/index.gohtml:142
msgid "Total"
msgstr "Total"
#: web/template/invoices/view.gohtml:2 web/template/invoices/view.gohtml:37
msgctxt "title"
msgid "Invoice %s"
msgstr "Factura %s"
#: 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"
#: web/template/invoices/view.gohtml:25
msgctxt "action"
msgid "Download invoice attachment"
msgstr "Descargar adjunto de factura"
#: web/template/invoices/view.gohtml:65 web/template/quotes/view.gohtml:72
msgctxt "title"
msgid "Concept"
msgstr "Concepto"
#: web/template/invoices/view.gohtml:68 web/template/quotes/view.gohtml:75
msgctxt "title"
msgid "Discount"
msgstr "Descuento"
#: web/template/invoices/view.gohtml:70 web/template/quotes/view.gohtml:77
msgctxt "title"
msgid "Units"
msgstr "Unidades"
#: web/template/invoices/view.gohtml:105 web/template/quotes/view.gohtml:112
msgctxt "title"
msgid "Tax Base"
msgstr "Base imponible"
#: web/template/invoices/edit.gohtml:2 web/template/invoices/edit.gohtml:19
msgctxt "title"
msgid "Edit Invoice “%s”"
2023-05-03 10:46:25 +00:00
msgstr "Edición de la factura «%s»"
#: web/template/web.gohtml:15
msgctxt "link"
msgid "Login"
msgstr "Entrada"
#: web/template/web.gohtml:16
msgctxt "link"
msgid "Demo"
msgstr "Demo"
#: web/template/web.gohtml:17
msgctxt "link"
msgid "Code"
msgstr "Código"
#: web/template/web.gohtml:28 web/template/legal.gohtml:2
#: web/template/legal.gohtml:7
msgctxt "title"
msgid "Legal Disclaimer"
msgstr "Aviso legal"
#: web/template/web.gohtml:29 web/template/privacy.gohtml:2
#: web/template/privacy.gohtml:7
msgctxt "title"
msgid "Privacy Policy"
msgstr "Política de privacidad"
#: web/template/web.gohtml:30 web/template/cookies.gohtml:2
#: web/template/cookies.gohtml:7
msgctxt "title"
msgid "Cookies Policy"
msgstr "Política de cookies"
#: web/template/form.gohtml:36
msgctxt "input"
msgid "(Max. %s)"
msgstr "(Máx. %s)"
#: web/template/form.gohtml:202
msgctxt "action"
msgid "Filters"
msgstr "Filtrar"
#: 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"
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
#: web/template/dashboard.gohtml:31
msgctxt "term"
msgid "Income"
msgstr "Ingresos"
#: web/template/dashboard.gohtml:35
msgctxt "term"
msgid "Expenses"
msgstr "Gastos"
#: web/template/dashboard.gohtml:39
msgctxt "term"
msgid "VAT"
msgstr "IVA"
#: web/template/dashboard.gohtml:43
msgctxt "term"
msgid "IRPF"
msgstr "IRPF"
#: web/template/dashboard.gohtml:47
msgctxt "term"
msgid "Net Income"
msgstr "Ingresos netos"
#: 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"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:28
msgctxt "action"
msgid "Download quotations"
msgstr "Descargar presupuestos"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:33
msgctxt "action"
msgid "New quotation"
msgstr "Nuevo presupuesto"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:66
msgctxt "quote"
msgid "All"
msgstr "Todos"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:68
msgctxt "title"
msgid "Quotation Num."
msgstr "N.º de presupuesto"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:81
msgctxt "action"
msgid "Select quotation %v"
msgstr "Seleccionar presupuesto %v"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:129
msgid "Actions for quote %s"
msgstr "Acciones para el presupuesto %s"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:153 web/template/quotes/view.gohtml:16
msgctxt "action"
msgid "Create invoice"
msgstr "Crear factura"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:163
msgid "No quotations added yet."
msgstr "No hay presupuestos."
#: web/template/quotes/view.gohtml:2 web/template/quotes/view.gohtml:36
msgctxt "title"
msgid "Quotation %s"
msgstr "Estado del presupuesto"
#: web/template/quotes/view.gohtml:25
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
msgid "Terms and Conditions:"
msgstr "Condiciones de aceptación:"
#: web/template/quotes/edit.gohtml:2 web/template/quotes/edit.gohtml:19
msgctxt "title"
msgid "Edit Quotation “%s”"
msgstr "Edición del presupuesto «%s»"
#: web/template/app.gohtml:24
msgctxt "menu"
msgid "Account"
msgstr "Cuenta"
#: web/template/app.gohtml:30
msgctxt "menu"
msgid "Tax Details"
msgstr "Configuración fiscal"
#: web/template/app.gohtml:36 web/template/company/invoicing.gohtml:3
msgctxt "title"
msgid "Invoicing and Quoting"
msgstr "Facturación y presupuestos"
#: web/template/app.gohtml:42 web/template/company/taxes.gohtml:3
msgctxt "title"
msgid "Taxes"
msgstr "Impuestos"
#: web/template/app.gohtml:48 web/template/company/payment_methods.gohtml:3
msgctxt "title"
msgid "Payment Methods"
msgstr "Métodos de pago"
#: web/template/app.gohtml:54 web/template/payments/accounts/new.gohtml:11
#: web/template/payments/accounts/index.gohtml:3
#: web/template/payments/accounts/index.gohtml:11
#: web/template/payments/accounts/edit.gohtml:11
msgctxt "title"
msgid "Payment Accounts"
msgstr "Cuenta de pago"
#: web/template/app.gohtml:60
msgctxt "menu"
msgid "Switch Company"
msgstr "Cambio de empresa"
#: web/template/app.gohtml:68
msgctxt "action"
msgid "Logout"
msgstr "Salir"
#: web/template/app.gohtml:77
msgctxt "nav"
2023-01-31 12:29:56 +00:00
msgid "Dashboard"
msgstr "Panel"
#: web/template/app.gohtml:78
2023-01-31 12:29:56 +00:00
msgctxt "nav"
msgid "Quotations"
msgstr "Presupuestos"
#: web/template/app.gohtml:79
msgctxt "nav"
msgid "Invoices"
msgstr "Facturas"
#: web/template/app.gohtml:80
msgctxt "nav"
2023-05-03 10:46:25 +00:00
msgid "Expenses"
msgstr "Gastos"
#: web/template/app.gohtml:81
2023-05-03 10:46:25 +00:00
msgctxt "nav"
msgid "Payments"
msgstr "Pagos"
#: web/template/app.gohtml:82
msgctxt "nav"
msgid "Products"
msgstr "Productos"
#: web/template/app.gohtml:83
msgctxt "nav"
msgid "Contacts"
msgstr "Contactos"
#: web/template/app.gohtml:91
msgid "<a href=\"https://numerus.cat/\">Numerus</a> Version: %s"
msgstr "<a href=\"https://numerus.cat/\">Numerus</a> versión: %s"
#: web/template/contacts/new.gohtml:2 web/template/contacts/new.gohtml:11
#: web/template/contacts/new.gohtml:19
msgctxt "title"
msgid "New Contact"
msgstr "Nuevo contacto"
#: web/template/contacts/new.gohtml:10 web/template/contacts/index.gohtml:2
#: 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
msgctxt "title"
msgid "Contacts"
msgstr "Contactos"
#: web/template/contacts/index.gohtml:15
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"
msgid "New contact"
msgstr "Nuevo contacto"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/contacts/index.gohtml:47 web/template/expenses/index.gohtml:65
msgctxt "title"
msgid "Contact"
msgstr "Contacto"
#: web/template/contacts/index.gohtml:48
msgctxt "title"
msgid "Email"
msgstr "Correo-e"
#: web/template/contacts/index.gohtml:49
msgctxt "title"
msgid "Phone"
msgstr "Teléfono"
#: web/template/contacts/index.gohtml:74
msgid "Actions for contact %s"
msgstr "Acciones para el contacto %s"
#: web/template/contacts/index.gohtml:92
msgid "No contacts added yet."
msgstr "No hay contactos."
#: web/template/contacts/edit.gohtml:3 web/template/contacts/edit.gohtml:20
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"
#: web/template/login.gohtml:2 web/template/login.gohtml:15
msgctxt "title"
msgid "Login"
msgstr "Entrada"
#: web/template/login.gohtml:19
msgctxt "action"
msgid "Login"
msgstr "Entrar"
2023-02-03 12:58:10 +00:00
#: web/template/profile.gohtml:2 web/template/profile.gohtml:10
#: web/template/profile.gohtml:18
msgctxt "title"
msgid "User Settings"
msgstr "Configuración usuario"
#: web/template/profile.gohtml:22
msgctxt "title"
msgid "User Access Data"
msgstr "Datos acceso usuario"
#: web/template/profile.gohtml:28
msgctxt "title"
msgid "Password Change"
msgstr "Cambio de contraseña"
#: web/template/profile.gohtml:35
msgctxt "title"
msgid "Language"
msgstr "Idioma"
#: web/template/profile.gohtml:39 web/template/company/tax-details.gohtml:36
#: web/template/company/invoicing.gohtml:31
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"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/expenses/index.gohtml:32
2023-05-03 10:46:25 +00:00
msgctxt "action"
msgid "New expense"
msgstr "Nuevo gasto"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/expenses/index.gohtml:66
2023-05-03 10:46:25 +00:00
msgctxt "title"
msgid "Invoice Date"
msgstr "Fecha de factura"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/expenses/index.gohtml:67
2023-05-03 10:46:25 +00:00
msgctxt "title"
msgid "Invoice Number"
msgstr "Número de factura"
2024-08-15 23:58:59 +00:00
#: web/template/expenses/index.gohtml:117
msgid "Actions for expense %s"
msgstr "Acciones para el gasto %s"
2024-08-15 23:58:59 +00:00
#: web/template/expenses/index.gohtml:135
2023-05-03 10:46:25 +00:00
msgid "No expenses added yet."
msgstr "No hay gastos."
2024-08-15 23:58:59 +00:00
#: web/template/expenses/edit.gohtml:3
2023-05-03 10:46:25 +00:00
msgctxt "title"
msgid "Edit Expense “%s”"
msgstr "Edición del gasto «%s»"
#: web/template/company/taxes.gohtml:23
msgctxt "title"
msgid "Tax Name"
msgstr "Nombre impuesto"
#: web/template/company/taxes.gohtml:24
msgctxt "title"
msgid "Rate (%)"
2023-02-03 12:29:10 +00:00
msgstr "Porcentaje"
#: web/template/company/taxes.gohtml:25
msgctxt "title"
msgid "Class"
msgstr "Clase"
#: web/template/company/taxes.gohtml:29
#: web/template/company/payment_methods.gohtml:28
msgid "Are you sure?"
msgstr "¿Estáis seguro?"
#: web/template/company/taxes.gohtml:49
msgid "No taxes added yet."
msgstr "No hay impuestos."
#: web/template/company/taxes.gohtml:56
msgctxt "title"
msgid "New Tax"
msgstr "Nuevo impuesto"
#: web/template/company/taxes.gohtml:66
msgctxt "action"
msgid "Add new tax"
msgstr "Añadir nuevo impuesto"
#: web/template/company/switch.gohtml:2
msgctxt "title"
msgid "Company Switch"
msgstr "Cambio de empresa"
#: web/template/company/switch.gohtml:30
msgctxt "action"
msgid "Switch"
msgstr "Cambiar"
#: web/template/company/tax-details.gohtml:2
msgctxt "title"
msgid "Tax Details"
msgstr "Configuración fiscal"
#: web/template/company/payment_methods.gohtml:23
msgctxt "title"
msgid "Payment Method"
msgstr "Método de pago"
#: web/template/company/payment_methods.gohtml:24
msgctxt "title"
msgid "Instructions"
msgstr "Instrucciones"
#: web/template/company/payment_methods.gohtml:48
msgid "No payment methods added yet."
msgstr "No hay métodos de pago."
#: web/template/company/payment_methods.gohtml:55
msgctxt "title"
msgid "New Payment Method"
msgstr "Nuevo método de pago"
#: web/template/company/payment_methods.gohtml:64
msgctxt "action"
msgid "Add new payment method"
msgstr "Añadir nuevo método de pago"
#: web/template/products/new.gohtml:2 web/template/products/new.gohtml:11
#: web/template/products/new.gohtml:19
msgctxt "title"
msgid "New Product"
msgstr "Nuevo producto"
#: web/template/products/new.gohtml:10 web/template/products/index.gohtml:2
#: web/template/products/index.gohtml:10 web/template/products/edit.gohtml:11
msgctxt "title"
msgid "Products"
msgstr "Productos"
#: web/template/products/search.gohtml:12
msgid "No products found."
msgstr "No se ha encontrado ningún producto."
#: web/template/products/index.gohtml:15
msgctxt "action"
msgid "New product"
msgstr "Nuevo producto"
#: web/template/products/index.gohtml:70
msgid "Actions for product %s"
msgstr "Acciones para el producto %s"
#: web/template/products/edit.gohtml:3 web/template/products/edit.gohtml:20
msgctxt "title"
msgid "Edit Product “%s”"
msgstr "Edición del producto «%s»"
#: web/template/payments/new.gohtml:3 web/template/payments/new.gohtml:12
msgctxt "title"
msgid "New Payment"
msgstr "Nuevo pago"
#: web/template/payments/new.gohtml:11 web/template/payments/index.gohtml:3
#: web/template/payments/index.gohtml:11 web/template/payments/edit.gohtml:11
msgctxt "title"
msgid "Payments"
msgstr "Pagos"
#: web/template/payments/index.gohtml:16
msgctxt "action"
msgid "New payment"
msgstr "Nuevo pago"
#: web/template/payments/index.gohtml:25
msgctxt "title"
msgid "Payment Date"
msgstr "Fecha del pago"
#: web/template/payments/index.gohtml:26
msgctxt "title"
msgid "Description"
msgstr "Descripción"
#: web/template/payments/index.gohtml:27
msgctxt "title"
msgid "Document"
msgstr "Documento"
#: web/template/payments/index.gohtml:37
msgid "Are you sure you wish to delete this payment?"
msgstr "¿Estáis seguro de querer borrar este pago?"
#: web/template/payments/index.gohtml:69
msgid "Actions for payment %s"
msgstr "Acciones para el pago %s"
#: web/template/payments/index.gohtml:88
msgctxt "action"
msgid "Remove"
msgstr "Borrar"
#: web/template/payments/index.gohtml:98
msgid "No payments added yet."
msgstr "No hay pagos."
#: web/template/payments/edit.gohtml:3
msgctxt "title"
msgid "Edit Payment “%s”"
msgstr "Edición del pago «%s»"
#: web/template/payments/accounts/new.gohtml:3
#: web/template/payments/accounts/new.gohtml:12
msgctxt "title"
msgid "New Payment Account"
msgstr "Nueva cuenta de pago"
#: web/template/payments/accounts/index.gohtml:16
msgctxt "action"
msgid "New payment account"
msgstr "Nuevo cuenta de pago"
#: web/template/payments/accounts/index.gohtml:26
msgctxt "title"
msgid "Type"
msgstr "Tipo"
#: web/template/payments/accounts/index.gohtml:27
msgctxt "title"
msgid "Number"
msgstr "Número"
#: web/template/payments/accounts/index.gohtml:28
msgctxt "title"
msgid "Expiration Date"
msgstr "Fecha de caducidad"
#: web/template/payments/accounts/index.gohtml:51
msgid "No payment accounts added yet."
msgstr "No hay cuentas de pago."
#: web/template/payments/accounts/edit.gohtml:3
msgctxt "title"
msgid "Edit Payment Account “%s”"
msgstr "Edición de la cuenta de pago «%s»"
#: pkg/ods.go:62 pkg/ods.go:106
msgctxt "title"
msgid "VAT number"
msgstr "DNI / NIF"
#: pkg/login.go:38 pkg/company.go:122 pkg/profile.go:40 pkg/contacts.go:276
2023-02-03 12:29:10 +00:00
msgctxt "input"
msgid "Email"
msgstr "Correo-e"
#: pkg/login.go:49 pkg/profile.go:49
msgctxt "input"
msgid "Password"
msgstr "Contraseña"
#: pkg/login.go:76 pkg/company.go:238 pkg/profile.go:89
msgid "Email can not be empty."
msgstr "No podéis dejar el correo-e en blanco."
#: pkg/login.go:77 pkg/company.go:239 pkg/profile.go:90 pkg/contacts.go:420
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."
#: pkg/login.go:79
msgid "Password can not be empty."
2023-02-03 12:29:10 +00:00
msgstr "No podéis dejar la contraseña en blanco."
#: pkg/login.go:115
msgid "Invalid user or password."
msgstr "Nombre de usuario o contraseña inválido."
#: pkg/products.go:172 pkg/products.go:276 pkg/quote.go:901 pkg/accounts.go:140
#: pkg/invoices.go:1147 pkg/contacts.go:149 pkg/contacts.go:262
msgctxt "input"
msgid "Name"
msgstr "Nombre"
2024-08-15 23:58:59 +00:00
#: pkg/products.go:177 pkg/products.go:303 pkg/tags.go:37 pkg/quote.go:174
#: pkg/quote.go:708 pkg/payments.go:162 pkg/expenses.go:335 pkg/expenses.go:485
#: pkg/invoices.go:177 pkg/invoices.go:877 pkg/contacts.go:154
#: pkg/contacts.go:362
msgctxt "input"
msgid "Tags"
msgstr "Etiquetes"
#: pkg/products.go:181 pkg/quote.go:178 pkg/expenses.go:495 pkg/invoices.go:181
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/contacts.go:158
msgctxt "input"
msgid "Tags Condition"
msgstr "Condición de las etiquetas"
#: pkg/products.go:185 pkg/quote.go:182 pkg/expenses.go:499 pkg/invoices.go:185
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/contacts.go:162
msgctxt "tag condition"
msgid "All"
msgstr "Todas"
#: pkg/products.go:186 pkg/expenses.go:500 pkg/invoices.go:186
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/contacts.go:163
msgid "Invoices must have all the specified labels."
msgstr "Las facturas deben tener todas las etiquetas."
#: pkg/products.go:190 pkg/quote.go:187 pkg/expenses.go:504 pkg/invoices.go:190
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/contacts.go:167
msgctxt "tag condition"
msgid "Any"
msgstr "Cualquiera"
#: pkg/products.go:191 pkg/expenses.go:505 pkg/invoices.go:191
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/contacts.go:168
msgid "Invoices must have at least one of the specified labels."
msgstr "Las facturas deben tener como mínimo una de las etiquetas."
#: pkg/products.go:282 pkg/quote.go:915 pkg/payments.go:129
#: pkg/invoices.go:1161
msgctxt "input"
msgid "Description"
msgstr "Descripción"
#: pkg/products.go:287 pkg/quote.go:919 pkg/invoices.go:1165
msgctxt "input"
msgid "Price"
msgstr "Precio"
#: pkg/products.go:297 pkg/quote.go:948 pkg/expenses.go:310
#: pkg/invoices.go:1194
msgctxt "input"
msgid "Taxes"
msgstr "Impuestos"
#: pkg/products.go:322 pkg/quote.go:997 pkg/profile.go:92 pkg/invoices.go:1243
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/contacts.go:412
msgid "Name can not be empty."
msgstr "No podéis dejar el nombre en blanco."
#: pkg/products.go:323 pkg/quote.go:998 pkg/invoices.go:1244
msgid "Price can not be empty."
msgstr "No podéis dejar el precio en blanco."
#: pkg/products.go:324 pkg/quote.go:999 pkg/invoices.go:1245
msgid "Price must be a number greater than zero."
msgstr "El precio tiene que ser un número mayor a cero."
#: pkg/products.go:326 pkg/quote.go:1007 pkg/expenses.go:370
#: pkg/invoices.go:1253
msgid "Selected tax is not valid."
msgstr "Habéis escogido un impuesto que no es válido."
#: pkg/products.go:327 pkg/quote.go:1008 pkg/expenses.go:371
#: pkg/invoices.go:1254
msgid "You can only select a tax of each class."
msgstr "Solo podéis escoger un impuesto de cada clase."
#: pkg/company.go:108
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 "Trade name"
msgstr "Nombre comercial"
#: pkg/company.go:113 pkg/contacts.go:268
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgctxt "input"
msgid "Phone"
msgstr "Teléfono"
#: pkg/company.go:131 pkg/contacts.go:284
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgctxt "input"
msgid "Web"
msgstr "Web"
#: pkg/company.go:139 pkg/contacts.go:296
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgctxt "input"
msgid "Business name"
msgstr "Nombre y apellidos"
#: pkg/company.go:149 pkg/contacts.go:306
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgctxt "input"
msgid "VAT number"
msgstr "DNI / NIF"
#: pkg/company.go:155 pkg/contacts.go:312
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgctxt "input"
msgid "Address"
msgstr "Dirección"
#: pkg/company.go:164 pkg/contacts.go:321
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgctxt "input"
msgid "City"
msgstr "Población"
#: pkg/company.go:170 pkg/contacts.go:327
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgctxt "input"
msgid "Province"
msgstr "Provincia"
#: pkg/company.go:176 pkg/contacts.go:333
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgctxt "input"
msgid "Postal code"
msgstr "Código postal"
#: pkg/company.go:185 pkg/contacts.go:342
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgctxt "input"
msgid "Country"
msgstr "País"
#: pkg/company.go:195
2023-02-03 12:29:10 +00:00
msgctxt "input"
msgid "Currency"
msgstr "Moneda"
#: pkg/company.go:226 pkg/contacts.go:394
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "Selected country is not valid."
msgstr "Habéis escogido un país que no es válido."
#: pkg/company.go:230 pkg/contacts.go:397
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "Business name can not be empty."
msgstr "No podéis dejar el nombre y los apellidos en blanco."
#: pkg/company.go:231 pkg/contacts.go:398
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "Business name must have at least two letters."
msgstr "El nombre y los apellidos deben contener como mínimo dos letras."
#: pkg/company.go:232 pkg/contacts.go:400
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "VAT number can not be empty."
msgstr "No podéis dejar el DNI o NIF en blanco."
#: pkg/company.go:233 pkg/contacts.go:401
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "This value is not a valid VAT number."
msgstr "Este valor no es un DNI o NIF válido."
#: pkg/company.go:235
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 "Phone can not be empty."
msgstr "No podéis dejar el teléfono en blanco."
#: pkg/company.go:236 pkg/contacts.go:417
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "This value is not a valid phone number."
msgstr "Este valor no es un teléfono válido."
#: pkg/company.go:242 pkg/contacts.go:423
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "This value is not a valid web address. It should be like https://domain.com/."
msgstr "Este valor no es una dirección web válida. Tiene que ser parecida a https://dominio.es/."
#: pkg/company.go:244 pkg/contacts.go:403
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "Address can not be empty."
msgstr "No podéis dejar la dirección en blanco."
#: pkg/company.go:245 pkg/contacts.go:404
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "City can not be empty."
msgstr "No podéis dejar la población en blanco."
#: pkg/company.go:246 pkg/contacts.go:405
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "Province can not be empty."
msgstr "No podéis dejar la provincia en blanco."
#: pkg/company.go:247 pkg/contacts.go:407
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "Postal code can not be empty."
msgstr "No podéis dejar el código postal en blanco."
#: pkg/company.go:248 pkg/contacts.go:408
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "This value is not a valid postal code."
msgstr "Este valor no es un código postal válido válido."
#: pkg/company.go:250
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."
#: pkg/company.go:402
msgctxt "input"
msgid "Invoice number format"
msgstr "Formato del número de factura"
#: pkg/company.go:408
msgctxt "input"
msgid "Next invoice number"
msgstr "Siguiente número de factura"
#: pkg/company.go:417
msgctxt "input"
msgid "Quotation number format"
msgstr "Formato del número de presupuesto"
#: pkg/company.go:423
msgctxt "input"
msgid "Next quotation number"
msgstr "Siguiente número de presupuesto"
#: pkg/company.go:432
msgctxt "input"
msgid "Legal disclaimer"
msgstr "Nota legal"
#: pkg/company.go:489
msgid "Invoice number format can not be empty."
msgstr "No podéis dejar el formato del número de factura en blanco."
#: pkg/company.go:490
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."
#: pkg/company.go:491
msgid "Quotation number format can not be empty."
msgstr "No podéis dejar el formato del número de presupuesto en blanco."
#: pkg/company.go:492
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."
#: pkg/company.go:614
2023-02-03 12:29:10 +00:00
msgctxt "input"
msgid "Tax name"
msgstr "Nombre impuesto"
#: pkg/company.go:620
msgctxt "input"
msgid "Tax Class"
msgstr "Clase de impuesto"
#: pkg/company.go:623
msgid "Select a tax class"
msgstr "Escoged una clase de impuesto"
#: pkg/company.go:627
2023-02-03 12:29:10 +00:00
msgctxt "input"
msgid "Rate (%)"
msgstr "Porcentaje"
#: pkg/company.go:650
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."
#: pkg/company.go:651
msgid "Selected tax class is not valid."
msgstr "Habéis escogido una clase impuesto que no es válida."
#: pkg/company.go:652
2023-02-03 12:29:10 +00:00
msgid "Tax rate can not be empty."
msgstr "No podéis dejar el porcentaje en blanco."
#: pkg/company.go:653
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."
#: pkg/company.go:762
msgctxt "input"
msgid "Payment method name"
msgstr "Nombre del método de pago"
#: pkg/company.go:768
msgctxt "input"
msgid "Instructions"
msgstr "Instrucciones"
#: pkg/company.go:786
msgid "Payment method name can not be empty."
msgstr "No podéis dejar el nombre del método de pago en blanco."
#: pkg/company.go:787
msgid "Payment instructions can not be empty."
msgstr "No podéis dejar las instrucciones de pago en blanco."
#: pkg/quote.go:147 pkg/quote.go:686 pkg/invoices.go:150 pkg/invoices.go:860
msgctxt "input"
msgid "Customer"
msgstr "Cliente"
#: pkg/quote.go:148 pkg/invoices.go:151
msgid "All customers"
msgstr "Todos los clientes"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/quote.go:153 pkg/quote.go:680
msgctxt "input"
msgid "Quotation Status"
msgstr "Estado del presupuesto"
#: pkg/quote.go:154 pkg/expenses.go:490 pkg/invoices.go:157
msgid "All status"
msgstr "Todos los estados"
#: pkg/quote.go:159
msgctxt "input"
msgid "Quotation Number"
msgstr "Número de presupuesto"
#: pkg/quote.go:164 pkg/expenses.go:475 pkg/invoices.go:167
msgctxt "input"
msgid "From Date"
msgstr "A partir de la fecha"
#: pkg/quote.go:169 pkg/expenses.go:480 pkg/invoices.go:172
msgctxt "input"
msgid "To Date"
msgstr "Hasta la fecha"
#: pkg/quote.go:183
msgid "Quotations must have all the specified labels."
msgstr "Los presupuestos deben tener todas las etiquetas."
#: pkg/quote.go:188
msgid "Quotations must have at least one of the specified labels."
msgstr "Los presupuestos deben tener como mínimo una de las etiquetas."
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/quote.go:618
msgid "quotations.zip"
msgstr "presupuestos.zip"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/quote.go:632
msgid "quotations.ods"
msgstr "presupuestos.ods"
2024-08-15 23:58:59 +00:00
#: pkg/quote.go:634 pkg/quote.go:1176 pkg/quote.go:1184 pkg/expenses.go:645
#: pkg/expenses.go:675 pkg/invoices.go:684 pkg/invoices.go:1437
#: pkg/invoices.go:1445
msgid "Invalid action"
msgstr "Acción inválida."
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/quote.go:687
msgid "Select a customer to quote."
msgstr "Escoged un cliente a presupuestar."
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/quote.go:692
msgctxt "input"
msgid "Quotation Date"
msgstr "Fecha del presupuesto"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/quote.go:698
msgctxt "input"
msgid "Terms and conditions"
msgstr "Condiciones de aceptación"
#: pkg/quote.go:703 pkg/invoices.go:872
msgctxt "input"
msgid "Notes"
msgstr "Notas"
#: pkg/quote.go:712 pkg/invoices.go:882
msgctxt "input"
msgid "Payment Method"
msgstr "Método de pago"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/quote.go:713
msgid "Select a payment method."
msgstr "Escoged un método e pago."
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/quote.go:749
msgid "Selected quotation status is not valid."
msgstr "Habéis escogido un estado de presupuesto que no es válido."
#: pkg/quote.go:751 pkg/invoices.go:937
msgid "Selected customer is not valid."
msgstr "Habéis escogido un cliente que no es válido."
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/quote.go:753
msgid "Quotation date can not be empty."
msgstr "No podéis dejar la fecha del presupuesto en blanco."
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/quote.go:754
msgid "Quotation date must be a valid date."
msgstr "La fecha de presupuesto debe ser válida."
#: pkg/quote.go:757 pkg/invoices.go:941
msgid "Selected payment method is not valid."
msgstr "Habéis escogido un método de pago que no es válido."
#: pkg/quote.go:891 pkg/quote.go:896 pkg/invoices.go:1137 pkg/invoices.go:1142
msgctxt "input"
msgid "Id"
msgstr "Identificador"
#: pkg/quote.go:929 pkg/invoices.go:1175
msgctxt "input"
msgid "Quantity"
msgstr "Cantidad"
#: pkg/quote.go:938 pkg/invoices.go:1184
msgctxt "input"
msgid "Discount (%)"
msgstr "Descuento (%)"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/quote.go:992
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."
#: pkg/quote.go:995 pkg/invoices.go:1241
msgid "Product ID must be a positive number or zero."
msgstr "El ID de producto tiene que ser un número positivo o cero."
#: pkg/quote.go:1001 pkg/invoices.go:1247
msgid "Quantity can not be empty."
msgstr "No podéis dejar la cantidad en blanco."
#: pkg/quote.go:1002 pkg/invoices.go:1248
msgid "Quantity must be a number greater than zero."
msgstr "La cantidad tiene que ser un número mayor a cero."
#: pkg/quote.go:1004 pkg/invoices.go:1250
msgid "Discount can not be empty."
msgstr "No podéis dejar el descuento en blanco."
#: pkg/quote.go:1005 pkg/invoices.go:1251
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
msgctxt "language option"
msgid "Automatic"
msgstr "Automático"
2023-02-03 12:29:10 +00:00
#: pkg/profile.go:31
msgctxt "input"
msgid "User name"
msgstr "Nombre de usuario"
2023-02-03 12:29:10 +00:00
#: pkg/profile.go:57
msgctxt "input"
msgid "Password Confirmation"
2023-02-03 12:29:10 +00:00
msgstr "Confirmación contraseña"
2023-02-03 12:29:10 +00:00
#: pkg/profile.go:65
msgctxt "input"
msgid "Language"
msgstr "Idioma"
#: pkg/profile.go:93
msgid "Confirmation does not match password."
msgstr "La confirmación no corresponde con la contraseña."
#: pkg/profile.go:94
msgid "Selected language is not valid."
msgstr "Habéis escogido un idioma que no es válido."
2024-08-15 23:58:59 +00:00
#: pkg/payments.go:135
msgctxt "input"
2024-08-15 23:58:59 +00:00
msgid "Payment Date"
msgstr "Fecha del pago"
#: pkg/payments.go:141
msgctxt "input"
msgid "Account"
msgstr "Cuenta"
#: pkg/payments.go:147 pkg/expenses.go:319
msgctxt "input"
msgid "Amount"
msgstr "Importe"
#: pkg/payments.go:157 pkg/expenses.go:330 pkg/invoices.go:888
2024-08-11 22:08:18 +00:00
msgctxt "input"
msgid "File"
msgstr "Archivo"
#: pkg/payments.go:169
msgid "Select an account."
msgstr "Escoged una cuenta."
#: pkg/payments.go:218
msgid "Description can not be empty."
msgstr "No podéis dejar la descripción en blanco."
#: pkg/payments.go:219
msgid "Selected payment account is not valid."
msgstr "Habéis escogido una cuenta de pago que no es válida."
#: pkg/payments.go:220
msgid "Payment date must be a valid date."
msgstr "La fecha de pago debe ser válida."
#: pkg/payments.go:221 pkg/expenses.go:372
msgid "Amount can not be empty."
msgstr "No podéis dejar el importe en blanco."
#: pkg/payments.go:222 pkg/expenses.go:373
msgid "Amount must be a number greater than zero."
msgstr "El importe tiene que ser un número mayor a cero."
#: pkg/accounts.go:131
msgctxt "input"
msgid "Type"
msgstr "Tipo"
#: pkg/accounts.go:146 pkg/contacts.go:352
msgctxt "input"
msgid "IBAN"
msgstr "IBAN"
#: pkg/accounts.go:152
msgctxt "input"
msgid "Cards last four digits"
msgstr "Últimos cuatro dígitos de la tarjeta"
#: pkg/accounts.go:163
msgctxt "input"
msgid "Expiration date"
msgstr "Fecha de caducidad"
#: pkg/accounts.go:229
msgid "Selected payment account type is not valid."
msgstr "Habéis escogido un tipo de cuenta de pago que no es válido."
#: pkg/accounts.go:232
msgid "IBAN can not be empty."
msgstr "No podéis dejar el IBAN en blanco."
#: pkg/accounts.go:233
msgid "This value is not a valid IBAN."
msgstr "Este valor no es un IBAN válido."
#: pkg/accounts.go:236
msgid "Last four digits can not be empty."
msgstr "No podéis dejar los cuatro últimos dígitos en blanco."
#: pkg/accounts.go:237
msgid "You must enter the cards last four digits"
msgstr "Debéis entrar los cuatro últimos dígitos de la tarjeta"
#: pkg/accounts.go:238
msgid "Last four digits must be a number."
msgstr "Los cuatro últimos dígitos tienen que ser un número."
#: pkg/accounts.go:241
msgid "Expiration date can not be empty."
msgstr "No podéis dejar la fecha de caducidad en blanco."
#: pkg/accounts.go:243
msgid "Expiration date should be a valid date in format MM/YY (e.g., 08/24)."
msgstr "La fecha de caducidad tiene que ser válida y en formato MM/AA (p. ej., 08/24)."
#: pkg/accounts.go:247
msgid "Payment account name can not be empty."
msgstr "No podéis dejar el nombre de la cuenta de pago en blanco."
#: pkg/dashboard.go:138
msgctxt "input"
msgid "Period"
msgstr "Periodo"
#: pkg/dashboard.go:141
msgctxt "period option"
msgid "Month"
msgstr "Mes"
#: pkg/dashboard.go:145
msgctxt "period option"
msgid "Previous month"
msgstr "Mes anterior"
#: pkg/dashboard.go:149
msgctxt "period option"
msgid "Quarter"
msgstr "Trimestre"
#: pkg/dashboard.go:153
msgctxt "period option"
msgid "Previous quarter"
msgstr "Trimestre anterior"
#: pkg/dashboard.go:157
msgctxt "period option"
msgid "Year"
msgstr "Año"
#: pkg/dashboard.go:161
msgctxt "period option"
msgid "Previous year"
msgstr "Año anterior"
#: pkg/expenses.go:237
2023-05-03 10:46:25 +00:00
msgid "Select a contact."
msgstr "Escoged un contacto"
#: pkg/expenses.go:293 pkg/expenses.go:464
msgctxt "input"
msgid "Contact"
msgstr "Contacto"
#: pkg/expenses.go:299
2023-05-03 10:46:25 +00:00
msgctxt "input"
msgid "Invoice number"
msgstr "Número de factura"
2024-08-15 23:58:59 +00:00
#: pkg/expenses.go:304 pkg/invoices.go:866
msgctxt "input"
msgid "Invoice Date"
msgstr "Fecha de factura"
#: pkg/expenses.go:368
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."
#: pkg/expenses.go:369 pkg/invoices.go:939
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."
#: pkg/expenses.go:465
msgid "All contacts"
msgstr "Todos los contactos"
#: pkg/expenses.go:470 pkg/invoices.go:162
msgctxt "input"
msgid "Invoice Number"
msgstr "Número de factura"
#: pkg/expenses.go:489
msgctxt "input"
msgid "Expense Status"
msgstr "Estado del gasto"
2024-08-15 23:58:59 +00:00
#: pkg/expenses.go:673
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
msgid "expenses.ods"
msgstr "gastos.ods"
#: pkg/invoices.go:156 pkg/invoices.go:854
msgctxt "input"
msgid "Invoice Status"
msgstr "Estado de la factura"
#: pkg/invoices.go:560
msgid "Select a customer to bill."
msgstr "Escoged un cliente a facturar."
#: pkg/invoices.go:664
msgid "invoices.zip"
msgstr "facturas.zip"
#: pkg/invoices.go:682
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
msgid "invoices.ods"
msgstr "facturas.ods"
#: pkg/invoices.go:936
msgid "Selected invoice status is not valid."
msgstr "Habéis escogido un estado de factura que no es válido."
#: pkg/invoices.go:938
msgid "Invoice date can not be empty."
msgstr "No podéis dejar la fecha de la factura en blanco."
#: pkg/invoices.go:1074
#, c-format
msgid "Re: quotation #%s of %s"
msgstr "Ref: presupuesto n.º %s del %s"
#: pkg/invoices.go:1075
msgctxt "to_char"
msgid "MM/DD/YYYY"
msgstr "DD/MM/YYYY"
#: pkg/invoices.go:1238
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."
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/contacts.go:292
2023-02-03 12:29:10 +00:00
msgctxt "input"
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "Need to input tax details"
msgstr "Necesito facturar este contacto"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/contacts.go:357
msgctxt "bic"
msgid "BIC"
msgstr "BIC"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/contacts.go:413
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "Name must have at least two letters."
msgstr "El nombre debe contener como mínimo dos letras."
2023-02-03 12:29:10 +00:00
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/contacts.go:426
msgid "This values is not a valid IBAN."
msgstr "Este valor no es un IBAN válido."
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: pkg/contacts.go:429
msgid "This values is not a valid BIC."
msgstr "Este valor no es un BIC válido."
2024-08-15 23:58:59 +00:00
#: pkg/contacts.go:518
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"
#~ msgctxt "title"
#~ msgid "Currency"
#~ msgstr "Moneda"
#~ msgctxt "title"
#~ msgid "New Line"
#~ msgstr "Nueva línea"
#~ msgid "Selected expense status is not valid."
#~ msgstr "Habéis escogido un estado de gasto que no es válido."
#~ 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."
#~ msgid "manager"
#~ msgstr "gestor"
#~ msgid "Tool to simplify management for small business and freelancers"
#~ msgstr "Herramienta para simplificar la gestión de autónomos y pequeñas empresas."
#~ msgid "Reduce management time, take control of your balance."
#~ msgstr "Reduce el tiempo de gestión, ten controlados tus números."
#~ msgid "application"
#~ msgstr "aplicación"
#~ msgctxt "term"
#~ msgid "Sales"
#~ msgstr "Ventas"
#~ msgctxt "title"
#~ msgid "Switch Company"
#~ msgstr "Cambio de empresa"
#~ msgctxt "expense"
#~ msgid "All"
#~ msgstr "Todos"
#~ msgctxt "action"
#~ msgid "Update contact"
#~ msgstr "Actualizar contacto"
#~ msgctxt "action"
#~ msgid "Update expense"
#~ msgstr "Actualizar gasto"
#~ msgctxt "action"
#~ msgid "Update product"
#~ msgstr "Actualizar producto"
#~ msgctxt "action"
#~ msgid "Edit invoice"
#~ msgstr "Editar factura"
#~ msgctxt "contact"
#~ msgid "All"
#~ msgstr "Todos"
#~ msgid "Product ID can not be empty."
#~ msgstr "No podéis dejar el identificador de producto en blanco."
#~ msgctxt "title"
#~ msgid "Label"
#~ msgstr "Etiqueta"
#~ msgid "Select a tax for this product."
#~ msgstr "Escoged un impuesto para este producto."
2023-02-03 12:29:10 +00:00
#~ msgctxt "input"
#~ msgid "Tax"
#~ msgstr "Impuesto"
#~ msgctxt "title"
#~ msgid "Customers"
#~ msgstr "Clientes"
#~ msgid "No customers added yet."
#~ msgstr "No hay clientes."