numerus/po/ca.po

1790 lines
47 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
# Catalan translations for numerus package
# Traduccions al català del paquet «numerus».
# Copyright (C) 2023 jordi fita mas
# This file is distributed under the same license as the numerus package.
# jordi fita mas <jordi@tandem.blog>, 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: numerus\n"
"Report-Msgid-Bugs-To: jordi@tandem.blog\n"
"POT-Creation-Date: 2024-09-06 12:07+0200\n"
Add Catalan and Spanish translation with gotext[3] I had to choose between [1], [2], and [3]. As far as i could find, [1] is not easy to work with templates[4] and at the moment is not maintained[5]. Both [2] and [3] use the same approach to be used from within templates: you have to define a FuncMap with template functions that call the message catalog. Also, both libraries seems to be reasonably maintained, and have packages in Debian’s repository. However, [2] repeats the same mistakes that POSIX did with its catalogs—using identifiers that are not the strings in the source language—, however this time the catalogs are written in JSON or YAML! This, somehow, makes things worse…. [3], the one i settled with, is fine and decently maintained. There are some surprising things, such as to be able to use directly the PO file, and that it has higher priority over the corresponding MO, or that the order of parameters is reversed in respect to gettext. However, it uses a saner format, and is a lot easier to work with than [3]. The problem, of course, is that xgettext does not know how to find translatable strings inside the template. [3] includes a CLI tool similar to xgettext, but is not a drop-in replacement[6] and does not process templates. The proper way to handle this would be to add a parser to xgettext, but for now i found out that if i surround the call to the translation functions from within the template with parentheses, i can trick xgettext into believing it is parsing Scheme code, and extracts the strings successfully—at least, for what i have tried. Had to add the keyword for pgettext, because Schemed does not have it, but at least i can do that with command line parameters. For now i left only Spanish and Catalan as the two available languages, even though the source text is written in English, because that way i can make sure i do not leave strings untranslated. [1]: https://golang.org/x/text [2]: https://github.com/nicksnyder/go-i18n [3]: https://github.com/leonelquinteros/gotext [4]: https://github.com/golang/go/issues/39954 [5]: https://github.com/golang/go/issues/12750 [6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
"PO-Revision-Date: 2023-01-18 17:08+0100\n"
"Last-Translator: jordi fita mas <jordi@tandem.blog>\n"
"Language-Team: Catalan <ca@dodds.net>\n"
"Language: ca\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: web/template/invoices/products.gohtml:2
#: web/template/invoices/products.gohtml:23
msgctxt "title"
msgid "Add Products to Invoice"
msgstr "Afegeix productes a la factura"
#: web/template/invoices/products.gohtml:9 web/template/invoices/new.gohtml:9
#: 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/products/new.gohtml:9
#: web/template/products/index.gohtml:9 web/template/products/edit.gohtml:10
#: web/template/payments/new.gohtml:14 web/template/payments/index.gohtml:14
#: web/template/payments/methods/index.gohtml:10
#: web/template/payments/edit.gohtml:14
#: 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 "Inici"
#: 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
#: web/template/payments/new.gohtml:19 web/template/payments/index.gohtml:19
#: web/template/payments/edit.gohtml:19
msgctxt "title"
msgid "Invoices"
msgstr "Factures"
#: 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 "Nova factura"
#: web/template/invoices/products.gohtml:48
#: web/template/quotes/products.gohtml:48
msgctxt "product"
msgid "All"
msgstr "Tots"
#: 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 "Nom"
#: 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 "Preu"
#: 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 hi ha cap producte."
#: web/template/invoices/products.gohtml:72 web/template/invoices/new.gohtml:87
#: web/template/invoices/edit.gohtml:88 web/template/quotes/products.gohtml:72
#: web/template/quotes/new.gohtml:88 web/template/quotes/edit.gohtml:89
msgctxt "action"
msgid "Add products"
msgstr "Afegeix productes"
#: 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 "Sha esborrat el producte «%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 "Desfes"
#: web/template/invoices/new.gohtml:63 web/template/invoices/view.gohtml:71
#: web/template/invoices/edit.gohtml:64 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:73 web/template/invoices/view.gohtml:75
#: web/template/invoices/view.gohtml:115 web/template/invoices/edit.gohtml:74
#: web/template/quotes/new.gohtml:74 web/template/quotes/view.gohtml:82
#: web/template/quotes/view.gohtml:122 web/template/quotes/edit.gohtml:75
#: web/template/expenses/new.gohtml:46 web/template/expenses/index.gohtml:74
#: web/template/expenses/edit.gohtml:48 web/template/payments/index.gohtml:55
msgctxt "title"
msgid "Total"
msgstr "Total"
#: web/template/invoices/new.gohtml:91 web/template/invoices/edit.gohtml:92
#: web/template/quotes/new.gohtml:92 web/template/quotes/edit.gohtml:93
#: web/template/expenses/new.gohtml:56 web/template/expenses/edit.gohtml:58
#: web/template/payments/methods/edit.gohtml:17
#: web/template/payments/edit.gohtml:55
#: web/template/payments/accounts/edit.gohtml:38
msgctxt "action"
msgid "Update"
msgstr "Actualitza"
#: web/template/invoices/new.gohtml:94 web/template/invoices/edit.gohtml:95
#: 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
#: web/template/payments/new.gohtml:57
#: web/template/payments/accounts/new.gohtml:41
msgctxt "action"
msgid "Save"
msgstr "Desa"
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 "Descarrega factures"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:31 web/template/quotes/index.gohtml:31
#: web/template/expenses/index.gohtml:29
msgctxt "action"
msgid "Export list"
msgstr "Exporta llistat"
#: web/template/invoices/index.gohtml:33
msgctxt "action"
msgid "New invoice"
msgstr "Nova factura"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:57 web/template/dashboard.gohtml:23
#: web/template/quotes/index.gohtml:57 web/template/contacts/index.gohtml:38
#: web/template/expenses/index.gohtml:56 web/template/products/index.gohtml:36
msgctxt "action"
msgid "Filter"
msgstr "Filtra"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:60 web/template/quotes/index.gohtml:60
#: web/template/contacts/index.gohtml:41 web/template/expenses/index.gohtml:59
#: web/template/products/index.gohtml:39
msgctxt "action"
msgid "Reset"
msgstr "Restableix"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:66
msgctxt "invoice"
msgid "All"
msgstr "Totes"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:67 web/template/invoices/view.gohtml:38
#: web/template/quotes/index.gohtml:67 web/template/quotes/view.gohtml:37
msgctxt "title"
msgid "Date"
msgstr "Data"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:68
msgctxt "title"
msgid "Invoice Num."
msgstr "Núm. factura"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:69 web/template/quotes/index.gohtml:69
msgctxt "title"
msgid "Customer"
msgstr "Client"
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:53
msgctxt "title"
msgid "Status"
msgstr "Estat"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:71 web/template/quotes/index.gohtml:71
#: web/template/contacts/index.gohtml:50 web/template/expenses/index.gohtml:69
#: web/template/products/index.gohtml:46 web/template/payments/index.gohtml:54
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 "Import"
#: web/template/invoices/index.gohtml:73 web/template/payments/new.gohtml:24
#: web/template/payments/index.gohtml:4 web/template/payments/edit.gohtml:24
msgctxt "title"
msgid "Collections"
msgstr "Cobraments"
#: 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:57
msgctxt "title"
msgid "Actions"
msgstr "Accions"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/invoices/index.gohtml:81
msgctxt "action"
msgid "Select invoice %v"
msgstr "Selecciona factura %v"
#: web/template/invoices/index.gohtml:101
msgctxt "action"
msgid "Download invoice %s"
msgstr "Descarrega factura %s"
#: web/template/invoices/index.gohtml:112
msgid "Actions for invoice %s"
msgstr "Accions per la factura %s"
#: web/template/invoices/index.gohtml:120 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:108
msgctxt "action"
msgid "Edit"
msgstr "Edita"
#: web/template/invoices/index.gohtml:128 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 "Duplica"
#: web/template/invoices/index.gohtml:136 web/template/invoices/view.gohtml:22
msgctxt "action"
msgid "Download invoice"
msgstr "Descarrega factura"
#: web/template/invoices/index.gohtml:146
msgid "No invoices added yet."
msgstr "No hi ha cap factura."
#: web/template/invoices/index.gohtml:153 web/template/quotes/index.gohtml:170
#: web/template/expenses/index.gohtml:151
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:25
msgctxt "action"
msgid "Download invoice attachment"
msgstr "Descarrega ladjunt de la factura"
#: web/template/invoices/view.gohtml:65 web/template/quotes/view.gohtml:72
msgctxt "title"
msgid "Concept"
msgstr "Concepte"
#: web/template/invoices/view.gohtml:68 web/template/quotes/view.gohtml:75
msgctxt "title"
msgid "Discount"
msgstr "Descompte"
#: web/template/invoices/view.gohtml:70 web/template/quotes/view.gohtml:77
msgctxt "title"
msgid "Units"
msgstr "Unitats"
#: web/template/invoices/view.gohtml:105 web/template/quotes/view.gohtml:112
msgctxt "title"
msgid "Tax Base"
msgstr "Base imposable"
#: web/template/invoices/edit.gohtml:2 web/template/invoices/edit.gohtml:19
msgctxt "title"
msgid "Edit Invoice “%s”"
msgstr "Edició 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 "Codi"
#: web/template/web.gohtml:28 web/template/legal.gohtml:2
#: web/template/legal.gohtml:7
msgctxt "title"
msgid "Legal Disclaimer"
msgstr "Avís 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 privacitat"
#: 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 "Filtra"
#: 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 "Tauler"
Add Catalan and Spanish translation with gotext[3] I had to choose between [1], [2], and [3]. As far as i could find, [1] is not easy to work with templates[4] and at the moment is not maintained[5]. Both [2] and [3] use the same approach to be used from within templates: you have to define a FuncMap with template functions that call the message catalog. Also, both libraries seems to be reasonably maintained, and have packages in Debian’s repository. However, [2] repeats the same mistakes that POSIX did with its catalogs—using identifiers that are not the strings in the source language—, however this time the catalogs are written in JSON or YAML! This, somehow, makes things worse…. [3], the one i settled with, is fine and decently maintained. There are some surprising things, such as to be able to use directly the PO file, and that it has higher priority over the corresponding MO, or that the order of parameters is reversed in respect to gettext. However, it uses a saner format, and is a lot easier to work with than [3]. The problem, of course, is that xgettext does not know how to find translatable strings inside the template. [3] includes a CLI tool similar to xgettext, but is not a drop-in replacement[6] and does not process templates. The proper way to handle this would be to add a parser to xgettext, but for now i found out that if i surround the call to the translation functions from within the template with parentheses, i can trick xgettext into believing it is parsing Scheme code, and extracts the strings successfully—at least, for what i have tried. Had to add the keyword for pgettext, because Schemed does not have it, but at least i can do that with command line parameters. For now i left only Spanish and Catalan as the two available languages, even though the source text is written in English, because that way i can make sure i do not leave strings untranslated. [1]: https://golang.org/x/text [2]: https://github.com/nicksnyder/go-i18n [3]: https://github.com/leonelquinteros/gotext [4]: https://github.com/golang/go/issues/39954 [5]: https://github.com/golang/go/issues/12750 [6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
#: web/template/dashboard.gohtml:31
msgctxt "term"
msgid "Income"
msgstr "Ingressos"
#: web/template/dashboard.gohtml:35
msgctxt "term"
msgid "Expenses"
msgstr "Despeses"
#: 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 "Ingressos nets"
#: web/template/quotes/products.gohtml:2 web/template/quotes/products.gohtml:23
msgctxt "title"
msgid "Add Products to Quotation"
msgstr "Afegeix productes al pressupost"
#: web/template/quotes/products.gohtml:10 web/template/quotes/new.gohtml:10
#: web/template/quotes/index.gohtml:2 web/template/quotes/index.gohtml:10
#: web/template/quotes/view.gohtml:10 web/template/quotes/edit.gohtml:10
msgctxt "title"
msgid "Quotations"
msgstr "Pressuposts"
#: web/template/quotes/products.gohtml:12 web/template/quotes/new.gohtml:2
#: web/template/quotes/new.gohtml:11 web/template/quotes/new.gohtml:19
msgctxt "title"
msgid "New Quotation"
msgstr "Nou pressupost"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:28
msgctxt "action"
msgid "Download quotations"
msgstr "Descarrega pressuposts"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:33
msgctxt "action"
msgid "New quotation"
msgstr "Nou pressupost"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:66
msgctxt "quote"
msgid "All"
msgstr "Tots"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:68
msgctxt "title"
msgid "Quotation Num."
msgstr "Núm. pressupost"
#: web/template/quotes/index.gohtml:73 web/template/payments/index.gohtml:56
msgctxt "title"
msgid "Download"
msgstr "Descàrrega"
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 "Selecciona pressupost %v"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:129
msgid "Actions for quote %s"
msgstr "Accions pel pressupost %s"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:153 web/template/quotes/view.gohtml:16
msgctxt "action"
msgid "Create invoice"
msgstr "Crea factura"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/quotes/index.gohtml:163
msgid "No quotations added yet."
msgstr "No hi ha cap pressupost."
#: web/template/quotes/view.gohtml:2 web/template/quotes/view.gohtml:36
msgctxt "title"
msgid "Quotation %s"
msgstr "Pressupost %s"
#: web/template/quotes/view.gohtml:25
msgctxt "action"
msgid "Download quotation"
msgstr "Descarrega pressupost"
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
#: web/template/quotes/view.gohtml:65
msgid "Terms and Conditions:"
msgstr "Condicions dacceptació:"
#: web/template/quotes/edit.gohtml:2 web/template/quotes/edit.gohtml:19
msgctxt "title"
msgid "Edit Quotation “%s”"
msgstr "Edició del pressupost «%s»"
#: web/template/app.gohtml:20
msgctxt "nav"
msgid "Dashboard"
msgstr "Tauler"
#: web/template/app.gohtml:21
msgctxt "nav"
msgid "Quotations"
msgstr "Pressuposts"
#: web/template/app.gohtml:22
msgctxt "nav"
msgid "Invoices"
msgstr "Factures"
#: web/template/app.gohtml:23
msgctxt "nav"
msgid "Expenses"
msgstr "Despeses"
#: web/template/app.gohtml:24
msgctxt "nav"
msgid "Payments"
msgstr "Pagaments"
#: web/template/app.gohtml:25
msgctxt "nav"
msgid "Products"
msgstr "Productes"
#: web/template/app.gohtml:26
msgctxt "nav"
msgid "Contacts"
msgstr "Contactes"
#: web/template/app.gohtml:37
msgctxt "menu"
msgid "Account"
msgstr "Compte"
#: web/template/app.gohtml:43
msgctxt "menu"
msgid "Tax Details"
msgstr "Configuració fiscal"
#: web/template/app.gohtml:49 web/template/company/invoicing.gohtml:3
msgctxt "title"
msgid "Invoicing and Quoting"
msgstr "Facturació i pressuposts"
#: web/template/app.gohtml:55 web/template/company/taxes.gohtml:3
msgctxt "title"
msgid "Taxes"
msgstr "Imposts"
#: web/template/app.gohtml:61 web/template/payments/methods/index.gohtml:3
msgctxt "title"
msgid "Invoicing Methods"
msgstr "Mètodes de facturació"
#: web/template/app.gohtml:67 web/template/payments/accounts/new.gohtml:11
#: web/template/payments/accounts/index.gohtml:3
#: web/template/payments/accounts/index.gohtml:11
#: web/template/payments/accounts/edit.gohtml:11
msgctxt "title"
msgid "Payment Accounts"
msgstr "Comptes de pagament"
#: web/template/app.gohtml:73
msgctxt "menu"
msgid "Switch Company"
msgstr "Canvi dempresa"
#: web/template/app.gohtml:81
msgctxt "action"
msgid "Logout"
msgstr "Surt"
#: web/template/contacts/new.gohtml:2 web/template/contacts/new.gohtml:11
#: web/template/contacts/new.gohtml:19
msgctxt "title"
msgid "New Contact"
msgstr "Nou contacte"
#: 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 "Contactes"
#: 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 "Importa"
#: web/template/contacts/index.gohtml:17
msgctxt "action"
msgid "New contact"
msgstr "Nou contacte"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/contacts/index.gohtml:47 web/template/expenses/index.gohtml:65
msgctxt "title"
msgid "Contact"
msgstr "Contacte"
#: web/template/contacts/index.gohtml:48
msgctxt "title"
msgid "Email"
msgstr "Correu-e"
#: web/template/contacts/index.gohtml:49
msgctxt "title"
msgid "Phone"
msgstr "Telèfon"
#: web/template/contacts/index.gohtml:74
msgid "Actions for contact %s"
msgstr "Accions pel contacte %s"
#: web/template/contacts/index.gohtml:92
msgid "No contacts added yet."
msgstr "No hi ha cap contacte."
#: web/template/contacts/edit.gohtml:3 web/template/contacts/edit.gohtml:20
msgctxt "title"
msgid "Edit Contact “%s”"
msgstr "Edició del contacte «%s»"
Allow importing contacts from Holded This allows to import an Excel file exported from Holded, because it is our own user case. When we have more customers, we will give out an Excel template file to fill out. Why XLSX files instead of CSV, for instance? First, because this is the output from Holded, but even then we would have more trouble with CSV than with XLSX because of Microsoft: they royally fucked up interoperability when decided that CSV files, the files that only other applications or programmers see, should be “localized”, and use a comma or a **semicolon** to separate a **comma** separated file depending on the locale’s decimal separator. This is ridiculous because it means that CSV files created with an Excel in USA uses comma while the same Excel but with a French locale expects the fields to be separated by semicolon. And for no good reason, either. Since they fucked up so bad, decided to add a non-standard “meta” field to specify the separator, writing a `sep=,` in the first line, but this only works for reading, because saving the same file changes the separator back to the locale-dependent character and removes the “meta” field. And since everyone expects to open spreadsheet with Excel, i can not use CSV if i do not want a bunch of support tickets telling me that the template is all in a single line. I use an extremely old version of a xlsx reading library for golang[0] because it is already available in Debian repositories, and the only thing i want from it is to convert the convoluted XML file into a string array. Go is only responsible to read the file and dump its contents into a temporary table, so that it can execute the PL/pgSQL function that will actually move that data to the correct relations, much like add_contact does but in batch. In PostgreSQL version 16 they added a pg_input_is_valid function that i would use to test whether input values really conform to domains, but i will have to wait for Debian to pick up the new version. Meanwhile, i use a couple of temporary functions, in lieu of nested functions support in PostgreSQL. Part of #45 [0]: https://github.com/tealeg/xlsx
2023-07-02 22:05:47 +00:00
#: web/template/contacts/import.gohtml:2 web/template/contacts/import.gohtml:10
msgctxt "title"
msgid "Import Contacts"
msgstr "Importació de contactes"
#: 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 "Entra"
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ó usuari"
#: web/template/profile.gohtml:22
msgctxt "title"
msgid "User Access Data"
msgstr "Dades accés usuari"
#: web/template/profile.gohtml:28
msgctxt "title"
msgid "Password Change"
msgstr "Canvi contrasenya"
#: 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 "Desa canvis"
2023-05-03 10:46:25 +00:00
#: web/template/expenses/new.gohtml:3 web/template/expenses/new.gohtml:12
#: web/template/expenses/new.gohtml:20
msgctxt "title"
msgid "New Expense"
msgstr "Nova despesa"
#: web/template/expenses/new.gohtml:11 web/template/expenses/index.gohtml:3
#: web/template/expenses/index.gohtml:11 web/template/expenses/edit.gohtml:11
#: web/template/payments/new.gohtml:16 web/template/payments/index.gohtml:16
#: web/template/payments/edit.gohtml:16
2023-05-03 10:46:25 +00:00
msgctxt "title"
msgid "Expenses"
msgstr "Despeses"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/expenses/index.gohtml:32
2023-05-03 10:46:25 +00:00
msgctxt "action"
msgid "New expense"
msgstr "Nova despesa"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/expenses/index.gohtml:66
2023-05-03 10:46:25 +00:00
msgctxt "title"
msgid "Invoice Date"
msgstr "Data de factura"
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
#: web/template/expenses/index.gohtml:67
2023-05-03 10:46:25 +00:00
msgctxt "title"
msgid "Invoice Number"
msgstr "Número de factura"
#: web/template/expenses/index.gohtml:75 web/template/payments/new.gohtml:26
#: web/template/payments/index.gohtml:6 web/template/payments/edit.gohtml:26
msgctxt "title"
msgid "Payments"
msgstr "Pagaments"
#: web/template/expenses/index.gohtml:117
msgid "Actions for expense %s"
msgstr "Accions per la despesa %s"
#: web/template/expenses/index.gohtml:133
msgctxt "action"
msgid "Download expense attachment"
msgstr "Descarrega ladjunt de la despesa"
#: web/template/expenses/index.gohtml:144
2023-05-03 10:46:25 +00:00
msgid "No expenses added yet."
msgstr "No hi ha cap despesa."
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ó de la despesa «%s»"
#: web/template/company/taxes.gohtml:23
msgctxt "title"
msgid "Tax Name"
msgstr "Nom impost"
#: web/template/company/taxes.gohtml:24
msgctxt "title"
msgid "Rate (%)"
msgstr "Percentatge"
#: web/template/company/taxes.gohtml:25
msgctxt "title"
msgid "Class"
msgstr "Classe"
#: web/template/company/taxes.gohtml:29
#: web/template/payments/methods/index.gohtml:34
msgid "Are you sure?"
msgstr "Nesteu segur?"
#: web/template/company/taxes.gohtml:49
msgid "No taxes added yet."
msgstr "No hi ha cap impost."
#: web/template/company/taxes.gohtml:56
msgctxt "title"
msgid "New Tax"
msgstr "Nou impost"
#: web/template/company/taxes.gohtml:66
msgctxt "action"
msgid "Add new tax"
msgstr "Afegeix nou impost"
#: web/template/company/switch.gohtml:2
msgctxt "title"
msgid "Company Switch"
msgstr "Canvi dempresa"
#: web/template/company/switch.gohtml:30
msgctxt "action"
msgid "Switch"
msgstr "Canvia"
#: web/template/company/tax-details.gohtml:2
msgctxt "title"
msgid "Tax Details"
msgstr "Configuració fiscal"
#: web/template/products/new.gohtml:2 web/template/products/new.gohtml:11
#: web/template/products/new.gohtml:19
msgctxt "title"
msgid "New Product"
msgstr "Nou producte"
#: 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 "Productes"
#: web/template/products/search.gohtml:12
msgid "No products found."
msgstr "No sha trobat cap producte."
#: web/template/products/index.gohtml:15
msgctxt "action"
msgid "New product"
msgstr "Nou producte"
#: web/template/products/index.gohtml:70
msgid "Actions for product %s"
msgstr "Accions pel producte %s"
#: web/template/products/edit.gohtml:3 web/template/products/edit.gohtml:20
msgctxt "title"
msgid "Edit Product “%s”"
msgstr "Edició del producte «%s»"
#: web/template/payments/new.gohtml:4
msgctxt "title"
msgid "New Collection"
msgstr "Nou cobrament"
#: web/template/payments/new.gohtml:6
msgctxt "title"
msgid "New Payment"
msgstr "Nou pagament"
#: web/template/payments/index.gohtml:29
msgctxt "action"
msgid "New collection"
msgstr "Nou cobrament"
#: web/template/payments/index.gohtml:31
msgctxt "action"
msgid "New payment"
msgstr "Nou pagament"
#: web/template/payments/index.gohtml:44
msgctxt "title"
msgid "Collection Date"
msgstr "Data del cobrament"
#: web/template/payments/index.gohtml:46
msgctxt "title"
msgid "Payment Date"
msgstr "Data del pagament"
#: web/template/payments/index.gohtml:49
msgctxt "title"
msgid "Description"
msgstr "Descripció"
#: web/template/payments/index.gohtml:51
msgctxt "title"
msgid "Document"
msgstr "Document"
#: web/template/payments/index.gohtml:61
msgid "Are you sure you wish to delete this collection?"
msgstr "Esteu segur de voler esborrar aquest cobrament?"
#: web/template/payments/index.gohtml:61
msgid "Are you sure you wish to delete this payment?"
msgstr "Esteu segur de voler esborrar aquest pagament?"
#: web/template/payments/index.gohtml:100
msgid "Actions for payment %s"
msgstr "Accions pel pagament %s"
#: web/template/payments/index.gohtml:119
msgctxt "action"
msgid "Remove"
msgstr "Esborra"
#: web/template/payments/index.gohtml:131
msgid "No collections added yet."
msgstr "No hi ha cap cobrament."
#: web/template/payments/index.gohtml:133
msgid "No payments added yet."
msgstr "No hi ha cap pagament."
#: web/template/payments/methods/index.gohtml:23
msgctxt "title"
msgid "Default"
msgstr "Per defecte"
#: web/template/payments/methods/index.gohtml:24
msgctxt "title"
msgid "Invoicing Method"
msgstr "Mètode de facturació"
#: web/template/payments/methods/index.gohtml:25
msgctxt "title"
msgid "Instructions"
msgstr "Instruccions"
#: web/template/payments/methods/index.gohtml:72
msgid "No invoicing methods added yet."
msgstr "No hi ha cap mètode de facturació."
#: web/template/payments/methods/index.gohtml:90
msgctxt "action"
msgid "Set"
msgstr "Estableix"
#: web/template/payments/methods/index.gohtml:100
msgctxt "title"
msgid "New Invoicing Method"
msgstr "Nou mètode de facturació"
#: web/template/payments/methods/index.gohtml:109
msgctxt "action"
msgid "Add new invoicing method"
msgstr "Afegeix nou mètode de facturació"
#: web/template/payments/methods/edit.gohtml:18
msgctxt "action"
msgid "Cancel"
msgstr "Cancel·la"
#: web/template/payments/edit.gohtml:4
msgctxt "title"
msgid "Edit Payment “%s”"
msgstr "Edició del pagament «%s»"
#: web/template/payments/edit.gohtml:6
msgctxt "title"
msgid "Edit Collection “%s”"
msgstr "Edició del cobrament «%s»"
#: web/template/payments/accounts/new.gohtml:3
#: web/template/payments/accounts/new.gohtml:12
msgctxt "title"
msgid "New Payment Account"
msgstr "Nou compte de pagament"
#: web/template/payments/accounts/index.gohtml:16
msgctxt "action"
msgid "New payment account"
msgstr "Nou compte de pagament"
#: web/template/payments/accounts/index.gohtml:26
msgctxt "title"
msgid "Type"
msgstr "Tipus"
#: web/template/payments/accounts/index.gohtml:27
msgctxt "title"
msgid "Number"
msgstr "Número"
#: web/template/payments/accounts/index.gohtml:28
msgctxt "title"
msgid "Expiration Date"
msgstr "Data de caducitat"
#: web/template/payments/accounts/index.gohtml:51
msgid "No payment accounts added yet."
msgstr "No hi ha cap compte de pagament."
#: web/template/payments/accounts/edit.gohtml:3
msgctxt "title"
msgid "Edit Payment Account “%s”"
msgstr "Edició del compte de pagament «%s»"
#: pkg/ods.go:62 pkg/ods.go:106
msgctxt "title"
msgid "VAT number"
msgstr "DNI / NIF"
#: pkg/login.go:38 pkg/company.go:124 pkg/profile.go:40 pkg/contacts.go:274
2023-02-03 12:29:10 +00:00
msgctxt "input"
msgid "Email"
msgstr "Correu-e"
#: pkg/login.go:49 pkg/profile.go:49
msgctxt "input"
msgid "Password"
msgstr "Contrasenya"
#: pkg/login.go:76 pkg/company.go:240 pkg/profile.go:89
msgid "Email can not be empty."
msgstr "No podeu deixar el correu-e en blanc."
#: pkg/login.go:77 pkg/company.go:241 pkg/profile.go:90 pkg/contacts.go:418
msgid "This value is not a valid email. It should be like name@domain.com."
msgstr "Aquest valor no és un correu-e vàlid. Hauria de ser similar a nom@domini.cat."
#: pkg/login.go:79
msgid "Password can not be empty."
msgstr "No podeu deixar la contrasenya en blanc."
#: pkg/login.go:115
msgid "Invalid user or password."
msgstr "Nom dusuari o contrasenya incorrectes."
#: pkg/products.go:168 pkg/products.go:272 pkg/quote.go:899 pkg/accounts.go:140
#: pkg/invoices.go:1130 pkg/contacts.go:147 pkg/contacts.go:260
msgctxt "input"
msgid "Name"
msgstr "Nom"
#: pkg/products.go:173 pkg/products.go:299 pkg/tags.go:37 pkg/quote.go:174
#: pkg/quote.go:706 pkg/payments.go:420 pkg/expenses.go:335 pkg/expenses.go:483
#: pkg/invoices.go:177 pkg/invoices.go:866 pkg/contacts.go:152
#: pkg/contacts.go:360
msgctxt "input"
msgid "Tags"
msgstr "Etiquetes"
#: pkg/products.go:177 pkg/quote.go:178 pkg/expenses.go:493 pkg/invoices.go:181
#: pkg/contacts.go:156
msgctxt "input"
msgid "Tags Condition"
msgstr "Condició de les etiquetes"
#: pkg/products.go:181 pkg/quote.go:182 pkg/expenses.go:497 pkg/invoices.go:185
#: pkg/contacts.go:160
msgctxt "tag condition"
msgid "All"
msgstr "Totes"
#: pkg/products.go:182 pkg/expenses.go:498 pkg/invoices.go:186
#: pkg/contacts.go:161
msgid "Invoices must have all the specified labels."
msgstr "Les factures han de tenir totes les etiquetes."
#: pkg/products.go:186 pkg/quote.go:187 pkg/expenses.go:502 pkg/invoices.go:190
#: pkg/contacts.go:165
msgctxt "tag condition"
msgid "Any"
msgstr "Qualsevol"
#: pkg/products.go:187 pkg/expenses.go:503 pkg/invoices.go:191
#: pkg/contacts.go:166
msgid "Invoices must have at least one of the specified labels."
msgstr "Les factures han de tenir com a mínim una de les etiquetes."
#: pkg/products.go:278 pkg/quote.go:913 pkg/payments.go:387
#: pkg/invoices.go:1144
msgctxt "input"
msgid "Description"
msgstr "Descripció"
#: pkg/products.go:283 pkg/quote.go:917 pkg/invoices.go:1148
msgctxt "input"
msgid "Price"
msgstr "Preu"
#: pkg/products.go:293 pkg/quote.go:946 pkg/expenses.go:310
#: pkg/invoices.go:1177
msgctxt "input"
msgid "Taxes"
msgstr "Imposts"
#: pkg/products.go:318 pkg/quote.go:995 pkg/profile.go:92 pkg/invoices.go:1226
#: pkg/contacts.go:410
msgid "Name can not be empty."
msgstr "No podeu deixar el nom en blanc."
#: pkg/products.go:319 pkg/quote.go:996 pkg/invoices.go:1227
msgid "Price can not be empty."
msgstr "No podeu deixar el preu en blanc."
#: pkg/products.go:320 pkg/quote.go:997 pkg/invoices.go:1228
msgid "Price must be a number greater than zero."
msgstr "El preu ha de ser un número major a zero."
#: pkg/products.go:322 pkg/quote.go:1005 pkg/expenses.go:370
#: pkg/invoices.go:1236
msgid "Selected tax is not valid."
msgstr "Heu seleccionat un impost que no és vàlid."
#: pkg/products.go:323 pkg/quote.go:1006 pkg/expenses.go:371
#: pkg/invoices.go:1237
msgid "You can only select a tax of each class."
msgstr "Només podeu seleccionar un impost de cada classe."
#: pkg/company.go:110
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 "Nom comercial"
#: pkg/company.go:115 pkg/contacts.go:266
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgctxt "input"
msgid "Phone"
msgstr "Telèfon"
#: pkg/company.go:133 pkg/contacts.go:282
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgctxt "input"
msgid "Web"
msgstr "Web"
#: pkg/company.go:141 pkg/contacts.go:294
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgctxt "input"
msgid "Business name"
msgstr "Nom i cognoms"
#: pkg/company.go:151 pkg/contacts.go:304
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:157 pkg/contacts.go:310
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgctxt "input"
msgid "Address"
msgstr "Adreça"
#: pkg/company.go:166 pkg/contacts.go:319
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgctxt "input"
msgid "City"
msgstr "Població"
#: pkg/company.go:172 pkg/contacts.go:325
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgctxt "input"
msgid "Province"
msgstr "Província"
#: pkg/company.go:178 pkg/contacts.go:331
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgctxt "input"
msgid "Postal code"
msgstr "Codi postal"
#: pkg/company.go:187 pkg/contacts.go:340
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:197
2023-02-03 12:29:10 +00:00
msgctxt "input"
msgid "Currency"
msgstr "Moneda"
#: pkg/company.go:228 pkg/contacts.go:392
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "Selected country is not valid."
msgstr "Heu seleccionat un país que no és vàlid."
#: pkg/company.go:232 pkg/contacts.go:395
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "Business name can not be empty."
msgstr "No podeu deixar el nom i els cognoms en blanc."
#: pkg/company.go:233 pkg/contacts.go:396
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "Business name must have at least two letters."
msgstr "Nom i cognoms han de tenir com a mínim dues lletres."
#: pkg/company.go:234 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 "VAT number can not be empty."
msgstr "No podeu deixar el DNI o NIF en blanc."
#: pkg/company.go:235 pkg/contacts.go:399
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "This value is not a valid VAT number."
msgstr "Aquest valor no és un DNI o NIF vàlid."
#: pkg/company.go:237
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 podeu deixar el telèfon en blanc."
#: pkg/company.go:238 pkg/contacts.go:415
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "This value is not a valid phone number."
msgstr "Aquest valor no és un telèfon vàlid."
#: pkg/company.go:244 pkg/contacts.go:421
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "This value is not a valid web address. It should be like https://domain.com/."
msgstr "Aquest valor no és una adreça web vàlida. Hauria de ser similar a https://domini.cat/."
#: pkg/company.go:246 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 "Address can not be empty."
msgstr "No podeu deixar ladreça en blanc."
#: pkg/company.go:247 pkg/contacts.go:402
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "City can not be empty."
msgstr "No podeu deixar la població en blanc."
#: pkg/company.go:248 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 "Province can not be empty."
msgstr "No podeu deixar la província en blanc."
#: pkg/company.go:249 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 "Postal code can not be empty."
msgstr "No podeu deixar el codi postal en blanc."
#: pkg/company.go:250 pkg/contacts.go:406
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "This value is not a valid postal code."
msgstr "Aquest valor no és un codi postal vàlid."
#: pkg/company.go:252
2023-02-03 12:29:10 +00:00
msgid "Selected currency is not valid."
msgstr "Heu seleccionat una moneda que no és vàlida."
#: pkg/company.go:402
msgctxt "input"
msgid "Invoice number format"
msgstr "Format del número de factura"
#: pkg/company.go:408
msgctxt "input"
msgid "Next invoice number"
msgstr "Següent número de factura"
#: pkg/company.go:417
msgctxt "input"
msgid "Quotation number format"
msgstr "Format del número de pressupost"
#: pkg/company.go:423
msgctxt "input"
msgid "Next quotation number"
msgstr "Següent número de pressupost"
#: 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 podeu deixar el format del número de factura en blanc."
#: pkg/company.go:490
msgid "Next invoice number must be a number greater than zero."
msgstr "El següent número de factura ha de ser un número major a zero."
#: pkg/company.go:491
msgid "Quotation number format can not be empty."
msgstr "No podeu deixar el format del número de pressupost en blanc."
#: pkg/company.go:492
msgid "Next quotation number must be a number greater than zero."
msgstr "El següent número de pressupost ha de ser un número major a zero."
#: pkg/company.go:612
2023-02-03 12:29:10 +00:00
msgctxt "input"
msgid "Tax name"
msgstr "Nom impost"
#: pkg/company.go:618
msgctxt "input"
msgid "Tax Class"
msgstr "Classe dimpost"
#: pkg/company.go:621
msgid "Select a tax class"
msgstr "Escolliu una classe dimpost"
#: pkg/company.go:625
2023-02-03 12:29:10 +00:00
msgctxt "input"
msgid "Rate (%)"
msgstr "Percentatge"
#: pkg/company.go:648
2023-02-03 12:29:10 +00:00
msgid "Tax name can not be empty."
msgstr "No podeu deixar el nom de limpost en blanc."
#: pkg/company.go:649
msgid "Selected tax class is not valid."
msgstr "Heu seleccionat una classe dimpost que no és vàlida."
#: pkg/company.go:650
2023-02-03 12:29:10 +00:00
msgid "Tax rate can not be empty."
msgstr "No podeu deixar percentatge en blanc."
#: pkg/company.go:651
2023-02-03 12:29:10 +00:00
msgid "Tax rate must be an integer between -99 and 99."
msgstr "El percentatge ha de ser entre -99 i 99."
#: pkg/company.go:781
msgctxt "input"
msgid "Invoicing method name"
msgstr "Nom del mètode de facturació"
#: pkg/company.go:787
msgctxt "input"
msgid "Instructions"
msgstr "Instruccions"
#: pkg/company.go:824
msgid "Invoicing method name can not be empty."
msgstr "No podeu deixar el nom del mètode de facturació en blanc."
#: pkg/company.go:825
msgid "Payment instructions can not be empty."
msgstr "No podeu deixar les instruccions de pagament en blanc."
#: pkg/company.go:912
msgid "Selected payment method is not valid."
msgstr "Heu seleccionat un mètode de pagament que no és vàlid."
#: pkg/quote.go:147 pkg/quote.go:684 pkg/invoices.go:150 pkg/invoices.go:849
msgctxt "input"
msgid "Customer"
msgstr "Client"
#: pkg/quote.go:148 pkg/invoices.go:151
msgid "All customers"
msgstr "Tots els clients"
#: pkg/quote.go:153 pkg/quote.go:678
msgctxt "input"
msgid "Quotation Status"
msgstr "Estat del pressupost"
#: pkg/quote.go:154 pkg/expenses.go:488 pkg/invoices.go:157
msgid "All status"
msgstr "Tots els estats"
#: pkg/quote.go:159
msgctxt "input"
msgid "Quotation Number"
msgstr "Número de pressupost"
#: pkg/quote.go:164 pkg/expenses.go:473 pkg/invoices.go:167
msgctxt "input"
msgid "From Date"
msgstr "A partir de la data"
#: pkg/quote.go:169 pkg/expenses.go:478 pkg/invoices.go:172
msgctxt "input"
msgid "To Date"
msgstr "Fins la data"
#: pkg/quote.go:183
msgid "Quotations must have all the specified labels."
msgstr "Els pressuposts han de tenir totes les etiquetes."
#: pkg/quote.go:188
msgid "Quotations must have at least one of the specified labels."
msgstr "Els pressuposts han de tenir com a mínim una de les etiquetes."
#: pkg/quote.go:616
msgid "quotations.zip"
msgstr "pressuposts.zip"
#: pkg/quote.go:630
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 "quotations.ods"
msgstr "pressuposts.ods"
#: pkg/quote.go:632 pkg/quote.go:1172 pkg/quote.go:1180 pkg/expenses.go:641
#: pkg/expenses.go:671 pkg/invoices.go:681 pkg/invoices.go:1409
#: pkg/invoices.go:1417
msgid "Invalid action"
msgstr "Acció invàlida."
#: pkg/quote.go:685
msgid "Select a customer to quote."
msgstr "Escolliu un client a pressupostar."
#: pkg/quote.go:690
msgctxt "input"
msgid "Quotation Date"
msgstr "Data del pressupost"
#: pkg/quote.go:696
msgctxt "input"
msgid "Terms and conditions"
msgstr "Condicions dacceptació"
#: pkg/quote.go:701 pkg/invoices.go:861
msgctxt "input"
msgid "Notes"
msgstr "Notes"
#: pkg/quote.go:710 pkg/invoices.go:871
msgctxt "input"
msgid "Invoicing Method"
msgstr "Mètode de facturació"
#: pkg/quote.go:711
msgid "Select a invoicing method."
msgstr "Escolliu un mètode de facturació."
#: pkg/quote.go:747
msgid "Selected quotation status is not valid."
msgstr "Heu seleccionat un estat de pressupost que no és vàlid."
#: pkg/quote.go:749 pkg/invoices.go:924
msgid "Selected customer is not valid."
msgstr "Heu seleccionat un client que no és vàlid."
#: pkg/quote.go:751
msgid "Quotation date can not be empty."
msgstr "No podeu deixar la data del pressupost en blanc."
#: pkg/quote.go:752
msgid "Quotation date must be a valid date."
msgstr "La data del pressupost ha de ser vàlida."
#: pkg/quote.go:755 pkg/invoices.go:928
msgid "Selected invoicing method is not valid."
msgstr "Heu seleccionat un mètode de facturació que no és vàlid."
#: pkg/quote.go:889 pkg/quote.go:894 pkg/invoices.go:1120 pkg/invoices.go:1125
msgctxt "input"
msgid "Id"
msgstr "Identificador"
#: pkg/quote.go:927 pkg/invoices.go:1158
msgctxt "input"
msgid "Quantity"
msgstr "Quantitat"
#: pkg/quote.go:936 pkg/invoices.go:1167
msgctxt "input"
msgid "Discount (%)"
msgstr "Descompte (%)"
#: pkg/quote.go:990
msgid "Quotation product ID must be a number greater than zero."
msgstr "LID del producte de pressupost ha de ser un número major a zero."
#: pkg/quote.go:993 pkg/invoices.go:1224
msgid "Product ID must be a positive number or zero."
msgstr "LID del producte ha de ser un número positiu o zero."
#: pkg/quote.go:999 pkg/invoices.go:1230
msgid "Quantity can not be empty."
msgstr "No podeu deixar la quantitat en blanc."
#: pkg/quote.go:1000 pkg/invoices.go:1231
msgid "Quantity must be a number greater than zero."
msgstr "La quantitat ha de ser un número major a zero."
#: pkg/quote.go:1002 pkg/invoices.go:1233
msgid "Discount can not be empty."
msgstr "No podeu deixar el descompte en blanc."
#: pkg/quote.go:1003 pkg/invoices.go:1234
msgid "Discount must be a percentage between 0 and 100."
msgstr "El descompte ha de ser un percentatge entre 0 i 100."
2023-02-03 12:29:10 +00:00
#: pkg/profile.go:25
msgctxt "language option"
msgid "Automatic"
msgstr "Automàtic"
2023-02-03 12:29:10 +00:00
#: pkg/profile.go:31
msgctxt "input"
msgid "User name"
msgstr "Nom dusuari"
2023-02-03 12:29:10 +00:00
#: pkg/profile.go:57
msgctxt "input"
msgid "Password Confirmation"
msgstr "Confirmació contrasenya"
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ó no és igual a la contrasenya."
#: pkg/profile.go:94
msgid "Selected language is not valid."
msgstr "Heu seleccionat un idioma que no és vàlid."
#: pkg/payments.go:309
#, c-format
msgid "Payment of %s"
msgstr "Pagament de %s"
#: pkg/payments.go:339
#, c-format
msgid "Collection of %s"
msgstr "Cobrament de %s"
#: pkg/payments.go:378 pkg/accounts.go:131
msgctxt "input"
msgid "Type"
msgstr "Tipus"
#: pkg/payments.go:381
msgctxt "payment type"
msgid "Payment"
msgstr "Pagament"
#: pkg/payments.go:382
msgctxt "payment type"
msgid "Collection"
msgstr "Cobrament"
#: pkg/payments.go:393
msgctxt "input"
2024-08-15 23:58:59 +00:00
msgid "Payment Date"
msgstr "Data del pagament"
#: pkg/payments.go:399
msgctxt "input"
msgid "Account"
msgstr "Compte"
#: pkg/payments.go:405 pkg/expenses.go:319
msgctxt "input"
msgid "Amount"
msgstr "Import"
#: pkg/payments.go:415 pkg/expenses.go:330 pkg/invoices.go:877
2024-08-11 22:08:18 +00:00
msgctxt "input"
msgid "File"
msgstr "Fitxer"
#: pkg/payments.go:443
msgid "Select a type."
msgstr "Escolliu un tipus."
#: pkg/payments.go:444
msgid "Select an account."
msgstr "Escolliu un compte."
#: pkg/payments.go:508
msgid "Selected payment type is not valid."
msgstr "Heu seleccionat un tipus de pagament que no és vàlid."
#: pkg/payments.go:509
msgid "Description can not be empty."
msgstr "No podeu deixar la descripció en blanc."
#: pkg/payments.go:510
msgid "Selected payment account is not valid."
msgstr "Heu seleccionat un compte de pagament que no és vàlid."
#: pkg/payments.go:511
msgid "Payment date must be a valid date."
msgstr "La data de pagament ha de ser vàlida."
#: pkg/payments.go:512 pkg/expenses.go:372
msgid "Amount can not be empty."
msgstr "No podeu deixar limport en blanc."
#: pkg/payments.go:513 pkg/expenses.go:373
msgid "Amount must be a number greater than zero."
msgstr "Limport ha de ser un número major a zero."
#: pkg/accounts.go:146 pkg/contacts.go:350
msgctxt "input"
msgid "IBAN"
msgstr "IBAN"
#: pkg/accounts.go:152
msgctxt "input"
msgid "Cards last four digits"
msgstr "Els quatre darrers dígits de la targeta"
#: pkg/accounts.go:163
msgctxt "input"
msgid "Expiration date"
msgstr "Data de caducitat"
#: pkg/accounts.go:229
msgid "Selected payment account type is not valid."
msgstr "Heu seleccionat un tipus de compte de pagament que no és vàlid."
#: pkg/accounts.go:232
msgid "IBAN can not be empty."
msgstr "No podeu deixar lIBAN en blanc."
#: pkg/accounts.go:233
msgid "This value is not a valid IBAN."
msgstr "Aquest valor no és un IBAN vàlid."
#: pkg/accounts.go:236
msgid "Last four digits can not be empty."
msgstr "No podeu deixar el quatre darrers dígits en blanc."
#: pkg/accounts.go:237
msgid "You must enter the cards last four digits"
msgstr "Heu dentrar els quatre darrers dígits de la targeta"
#: pkg/accounts.go:238
msgid "Last four digits must be a number."
msgstr "El quatre darrera dígits han de ser un número."
#: pkg/accounts.go:241
msgid "Expiration date can not be empty."
msgstr "No podeu deixar la data de pagament en blanc."
#: pkg/accounts.go:243
msgid "Expiration date should be a valid date in format MM/YY (e.g., 08/24)."
msgstr "La data de caducitat has de ser vàlida i en format MM/AA (p. ex., 08/24)."
#: pkg/accounts.go:247
msgid "Payment account name can not be empty."
msgstr "No podeu deixar el nom del compte de pagament en blanc."
#: pkg/dashboard.go:138
msgctxt "input"
msgid "Period"
msgstr "Període"
#: 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 "Any"
#: pkg/dashboard.go:161
msgctxt "period option"
msgid "Previous year"
msgstr "Any anterior"
#: pkg/expenses.go:237
2023-05-03 10:46:25 +00:00
msgid "Select a contact."
msgstr "Escolliu un contacte."
#: pkg/expenses.go:293 pkg/expenses.go:462
msgctxt "input"
msgid "Contact"
msgstr "Contacte"
#: pkg/expenses.go:299
2023-05-03 10:46:25 +00:00
msgctxt "input"
msgid "Invoice number"
msgstr "Número de factura"
#: pkg/expenses.go:304 pkg/invoices.go:855
2024-08-15 23:58:59 +00:00
msgctxt "input"
msgid "Invoice Date"
msgstr "Data de factura"
#: pkg/expenses.go:368
2023-05-03 10:46:25 +00:00
msgid "Selected contact is not valid."
msgstr "Heu seleccionat un contacte que no és vàlid."
#: pkg/expenses.go:369 pkg/invoices.go:926
2023-05-03 10:46:25 +00:00
msgid "Invoice date must be a valid date."
msgstr "La data de facturació ha de ser vàlida."
#: pkg/expenses.go:463
msgid "All contacts"
msgstr "Tots els contactes"
#: pkg/expenses.go:468 pkg/invoices.go:162
msgctxt "input"
msgid "Invoice Number"
msgstr "Número de factura"
#: pkg/expenses.go:487
msgctxt "input"
msgid "Expense Status"
msgstr "Estat de la despesa"
#: pkg/expenses.go:669
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
msgid "expenses.ods"
msgstr "despeses.ods"
#: pkg/invoices.go:156
msgctxt "input"
msgid "Invoice Status"
msgstr "Estat de la factura"
#: pkg/invoices.go:559
msgid "Select a customer to bill."
msgstr "Escolliu un client a facturar."
#: pkg/invoices.go:661
msgid "invoices.zip"
msgstr "factures.zip"
#: pkg/invoices.go:679
Add option to export the list of quotes, invoices, and expenses to ODS This was requested by a potential user, as they want to be able to do whatever they want to do to these lists with a spreadsheet. In fact, they requested to be able to export to CSV, but, as always, using CSV is a minefield because of Microsoft: since their Excel product is fucking unable to write and read CSV from different locales, even if using the same exact Excel product, i can not also create a CSV file that is guaranteed to work on all locales. If i used the non-standard sep=; thing to tell Excel that it is a fucking stupid application, then proper applications would show that line as a row, which is the correct albeit undesirable behaviour. The solution is to use a spreadsheet file format that does not have this issue. As far as I know, by default Excel is able to read XLSX and ODS files, but i refuse to use the artificially complex, not the actually used in Excel, and lobbied standard that Microsoft somehow convinced ISO to publish, as i am using a different format because of the mess they made, and i do not want to bend over in front of them, so ODS it is. ODS is neither an elegant or good format by any means, but at least i can write them using simple strings, because there is no ODS library in Debian and i am not going to write yet another DEB package for an overengineered package to write a simple table—all i want is to say “here are these n columns, and these m columns; have a good day!”. Part of #51.
2023-07-18 11:29:36 +00:00
msgid "invoices.ods"
msgstr "factures.ods"
#: pkg/invoices.go:925
msgid "Invoice date can not be empty."
msgstr "No podeu deixar la data de la factura en blanc."
#: pkg/invoices.go:1057
#, c-format
msgid "Re: quotation #%s of %s"
msgstr "Ref: pressupost núm. %s del %s"
#: pkg/invoices.go:1058
msgctxt "to_char"
msgid "MM/DD/YYYY"
msgstr "DD/MM/YYYY"
#: pkg/invoices.go:1221
msgid "Invoice product ID must be a number greater than zero."
msgstr "LID del producte de factura ha de ser un número major a zero."
#: pkg/contacts.go:290
2023-02-03 12:29:10 +00:00
msgctxt "input"
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "Need to input tax details"
msgstr "Necessito poder facturar aquest contacte"
#: pkg/contacts.go:355
msgctxt "bic"
msgid "BIC"
msgstr "BIC"
#: pkg/contacts.go:411
Split contact relation into tax_details, phone, web, and email We need to have contacts with just a name: we need to assign freelancer’s quote as expense linked the government, but of course we do not have a phone or email for that “contact”, much less a VATIN or other tax details. It is also interesting for other expenses-only contacts to not have to input all tax details, as we may not need to invoice then, thus are useless for us, but sometimes it might be interesting to have them, “just in case”. Of course, i did not want to make nullable any of the tax details required to generate an invoice, otherwise we could allow illegal invoices. Therefore, that data had to go in a different relation, and invoice’s foreign key update to point to that relation, not just customer, or we would again be able to create invalid invoices. We replaced the contact’s trade name with just name, because we do not need _three_ names for a contact, but we _do_ need two: the one we use to refer to them and the business name for tax purposes. The new contact_phone, contact_web, and contact_email relations could be simply a nullable field, but i did not see the point, since there are not that many instances where i need any of this data. Now company.taxDetailsForm is no longer “the same as contactForm with some extra fields”, because i have to add a check whether the user needs to invoice the contact, to check that the required values are there. I have an additional problem with the contact form when not using JavaScript: i must set the required field to all tax details fields to avoid the “(optional)” suffix, and because they _are_ required when that checkbox is enabled, but i can not set them optional when the check is unchecked. My solution for now is to ignore the form validation, and later i will add some JavaScript that adds the validation again, so it will work in all cases.
2023-06-30 19:32:48 +00:00
msgid "Name must have at least two letters."
msgstr "El nom ha de tenir com a mínim dues lletres."
2023-02-03 12:29:10 +00:00
#: pkg/contacts.go:424
msgid "This values is not a valid IBAN."
msgstr "Aquest valor no és un IBAN vàlid."
#: pkg/contacts.go:427
msgid "This values is not a valid BIC."
msgstr "Aquest valor no és un BIC vàlid."
#: pkg/contacts.go:516
Allow importing contacts from Holded This allows to import an Excel file exported from Holded, because it is our own user case. When we have more customers, we will give out an Excel template file to fill out. Why XLSX files instead of CSV, for instance? First, because this is the output from Holded, but even then we would have more trouble with CSV than with XLSX because of Microsoft: they royally fucked up interoperability when decided that CSV files, the files that only other applications or programmers see, should be “localized”, and use a comma or a **semicolon** to separate a **comma** separated file depending on the locale’s decimal separator. This is ridiculous because it means that CSV files created with an Excel in USA uses comma while the same Excel but with a French locale expects the fields to be separated by semicolon. And for no good reason, either. Since they fucked up so bad, decided to add a non-standard “meta” field to specify the separator, writing a `sep=,` in the first line, but this only works for reading, because saving the same file changes the separator back to the locale-dependent character and removes the “meta” field. And since everyone expects to open spreadsheet with Excel, i can not use CSV if i do not want a bunch of support tickets telling me that the template is all in a single line. I use an extremely old version of a xlsx reading library for golang[0] because it is already available in Debian repositories, and the only thing i want from it is to convert the convoluted XML file into a string array. Go is only responsible to read the file and dump its contents into a temporary table, so that it can execute the PL/pgSQL function that will actually move that data to the correct relations, much like add_contact does but in batch. In PostgreSQL version 16 they added a pg_input_is_valid function that i would use to test whether input values really conform to domains, but i will have to wait for Debian to pick up the new version. Meanwhile, i use a couple of temporary functions, in lieu of nested functions support in PostgreSQL. Part of #45 [0]: https://github.com/tealeg/xlsx
2023-07-02 22:05:47 +00:00
msgctxt "input"
msgid "Holded Excel file"
msgstr "Fitxer Excel del Holded"
#~ msgctxt "input"
#~ msgid "Payment method name"
#~ msgstr "Nom del mètode de pagament"
#~ msgctxt "title"
#~ msgid "Payment Methods"
#~ msgstr "Mètodes de pagament"
#~ msgid "<a href=\"https://numerus.cat/\">Numerus</a> Version: %s"
#~ msgstr "<a href=\"https://numerus.cat/\">Numerus</a> versió: %s"
#~ msgctxt "title"
#~ msgid "Payment Method"
#~ msgstr "Mètode de pagament"
#~ msgid "No payment methods added yet."
#~ msgstr "No hi ha cap mètode de pagament."
#~ msgctxt "title"
#~ msgid "New Payment Method"
#~ msgstr "Nou mètode de pagament"
#~ msgctxt "input"
#~ msgid "Payment Method"
#~ msgstr "Mètode de pagament"
#~ msgid "Selected invoice status is not valid."
#~ msgstr "Heu seleccionat un estat de factura que no és vàlid."
#~ msgctxt "action"
#~ msgid "Payments"
#~ msgstr "Pagaments"
#~ msgctxt "title"
#~ msgid "Currency"
#~ msgstr "Moneda"
#~ msgctxt "title"
#~ msgid "New Line"
#~ msgstr "Nova línia"
#~ msgid "Selected expense status is not valid."
#~ msgstr "Heu seleccionat un estat de despesa que no és vàlid."
#~ msgctxt "link"
#~ msgid "login"
#~ msgstr "Entrada"
#~ msgid "If you want to sign in, just head to %sthe login page%s and enter your credentials in the form."
#~ msgstr "Si vols accedir al teu usuari només has d'anar a %sla pàgina dentrada%s i apuntar les teves credencials al seu lloc."
#~ msgid "manager"
#~ msgstr "gestor"
#~ msgid "Tool to simplify management for small business and freelancers"
#~ msgstr "Eina per simplificar la gestió dautònoms i petites empreses."
#~ msgid "Reduce management time, take control of your balance."
#~ msgstr "Redueix el temps de gestió, tingues controlats els teus números."
#~ msgid "application"
#~ msgstr "aplicació"
#~ msgctxt "term"
#~ msgid "Sales"
#~ msgstr "Vendes"
#~ msgctxt "title"
#~ msgid "Switch Company"
#~ msgstr "Canvi dempresa"
#~ msgctxt "expense"
#~ msgid "All"
#~ msgstr "Totes"
#~ msgctxt "action"
#~ msgid "Update contact"
#~ msgstr "Actualitza contacte"
#~ msgctxt "action"
#~ msgid "Update expense"
#~ msgstr "Actualitza despesa"
#~ msgctxt "action"
#~ msgid "Update product"
#~ msgstr "Actualitza producte"
#~ msgctxt "action"
#~ msgid "Edit invoice"
#~ msgstr "Edita factura"
#~ msgctxt "contact"
#~ msgid "All"
#~ msgstr "Tots"
#~ msgid "Product ID can not be empty."
#~ msgstr "No podeu deixar lidentificador del producte en blanc."
#~ msgctxt "title"
#~ msgid "Label"
#~ msgstr "Etiqueta"
#~ msgid "Select a tax for this product."
#~ msgstr "Escolliu un impost per aquest producte."
2023-02-03 12:29:10 +00:00
#~ msgctxt "input"
#~ msgid "Tax"
#~ msgstr "Impost"
#~ msgctxt "title"
#~ msgid "Customers"
#~ msgstr "Clients"
#~ msgid "No customers added yet."
#~ msgstr "No hi ha cap client."