tandem
/
numerus
2
0
Fork 0
Code Issues 39 Pull Requests Packages Projects 1 Releases 1 Wiki Activity
numerus/po/es.po

287 lines
6.4 KiB
Plaintext
Raw Normal View History

Add Catalan and Spanish translation with gotext[3] I had to choose between [1], [2], and [3]. As far as i could find, [1] is not easy to work with templates[4] and at the moment is not maintained[5]. Both [2] and [3] use the same approach to be used from within templates: you have to define a FuncMap with template functions that call the message catalog. Also, both libraries seems to be reasonably maintained, and have packages in Debian’s repository. However, [2] repeats the same mistakes that POSIX did with its catalogs—using identifiers that are not the strings in the source language—, however this time the catalogs are written in JSON or YAML! This, somehow, makes things worse…. [3], the one i settled with, is fine and decently maintained. There are some surprising things, such as to be able to use directly the PO file, and that it has higher priority over the corresponding MO, or that the order of parameters is reversed in respect to gettext. However, it uses a saner format, and is a lot easier to work with than [3]. The problem, of course, is that xgettext does not know how to find translatable strings inside the template. [3] includes a CLI tool similar to xgettext, but is not a drop-in replacement[6] and does not process templates. The proper way to handle this would be to add a parser to xgettext, but for now i found out that if i surround the call to the translation functions from within the template with parentheses, i can trick xgettext into believing it is parsing Scheme code, and extracts the strings successfully—at least, for what i have tried. Had to add the keyword for pgettext, because Schemed does not have it, but at least i can do that with command line parameters. For now i left only Spanish and Catalan as the two available languages, even though the source text is written in English, because that way i can make sure i do not leave strings untranslated. [1]: https://golang.org/x/text [2]: https://github.com/nicksnyder/go-i18n [3]: https://github.com/leonelquinteros/gotext [4]: https://github.com/golang/go/issues/39954 [5]: https://github.com/golang/go/issues/12750 [6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
# Spanish translations for numerus package.
# Copyright (C) 2023 jordi fita mas
# This file is distributed under the same license as the numerus package.
# jordi fita mas <jordi@tandem.blog>, 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: numerus\n"
"Report-Msgid-Bugs-To: jordi@tandem.blog\n"
Refactor form validation into a new type I was worried that i was repeating the AddInputErrors function for each form, because they were basically the same. I could create a Form type and make all forms embed it, but i realized that with a separate validator i would have cleaner validation functions and would not need the Valid field in the form that i am using only for that method.
2023-02-01 10:30:30 +00:00
"POT-Creation-Date: 2023-02-01 11:26+0100\n"
Add Catalan and Spanish translation with gotext[3] I had to choose between [1], [2], and [3]. As far as i could find, [1] is not easy to work with templates[4] and at the moment is not maintained[5]. Both [2] and [3] use the same approach to be used from within templates: you have to define a FuncMap with template functions that call the message catalog. Also, both libraries seems to be reasonably maintained, and have packages in Debian’s repository. However, [2] repeats the same mistakes that POSIX did with its catalogs—using identifiers that are not the strings in the source language—, however this time the catalogs are written in JSON or YAML! This, somehow, makes things worse…. [3], the one i settled with, is fine and decently maintained. There are some surprising things, such as to be able to use directly the PO file, and that it has higher priority over the corresponding MO, or that the order of parameters is reversed in respect to gettext. However, it uses a saner format, and is a lot easier to work with than [3]. The problem, of course, is that xgettext does not know how to find translatable strings inside the template. [3] includes a CLI tool similar to xgettext, but is not a drop-in replacement[6] and does not process templates. The proper way to handle this would be to add a parser to xgettext, but for now i found out that if i surround the call to the translation functions from within the template with parentheses, i can trick xgettext into believing it is parsing Scheme code, and extracts the strings successfully—at least, for what i have tried. Had to add the keyword for pgettext, because Schemed does not have it, but at least i can do that with command line parameters. For now i left only Spanish and Catalan as the two available languages, even though the source text is written in English, because that way i can make sure i do not leave strings untranslated. [1]: https://golang.org/x/text [2]: https://github.com/nicksnyder/go-i18n [3]: https://github.com/leonelquinteros/gotext [4]: https://github.com/golang/go/issues/39954 [5]: https://github.com/golang/go/issues/12750 [6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
"PO-Revision-Date: 2023-01-18 17:45+0100\n"
"Last-Translator: jordi fita mas <jordi@tandem.blog>\n"
"Language-Team: Spanish <es@tp.org.es>\n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/dashboard.gohtml:2
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"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
msgid "Dashboard"
msgstr "Panel"
Add Catalan and Spanish translation with gotext[3] I had to choose between [1], [2], and [3]. As far as i could find, [1] is not easy to work with templates[4] and at the moment is not maintained[5]. Both [2] and [3] use the same approach to be used from within templates: you have to define a FuncMap with template functions that call the message catalog. Also, both libraries seems to be reasonably maintained, and have packages in Debian’s repository. However, [2] repeats the same mistakes that POSIX did with its catalogs—using identifiers that are not the strings in the source language—, however this time the catalogs are written in JSON or YAML! This, somehow, makes things worse…. [3], the one i settled with, is fine and decently maintained. There are some surprising things, such as to be able to use directly the PO file, and that it has higher priority over the corresponding MO, or that the order of parameters is reversed in respect to gettext. However, it uses a saner format, and is a lot easier to work with than [3]. The problem, of course, is that xgettext does not know how to find translatable strings inside the template. [3] includes a CLI tool similar to xgettext, but is not a drop-in replacement[6] and does not process templates. The proper way to handle this would be to add a parser to xgettext, but for now i found out that if i surround the call to the translation functions from within the template with parentheses, i can trick xgettext into believing it is parsing Scheme code, and extracts the strings successfully—at least, for what i have tried. Had to add the keyword for pgettext, because Schemed does not have it, but at least i can do that with command line parameters. For now i left only Spanish and Catalan as the two available languages, even though the source text is written in English, because that way i can make sure i do not leave strings untranslated. [1]: https://golang.org/x/text [2]: https://github.com/nicksnyder/go-i18n [3]: https://github.com/leonelquinteros/gotext [4]: https://github.com/golang/go/issues/39954 [5]: https://github.com/golang/go/issues/12750 [6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
Rename extension of templates to .gohtml Apparently, there are tools that only know how to use that extensions when referring to Go templates.
2023-01-30 15:48:21 +00:00
#: web/template/app.gohtml:20
msgctxt "menu"
msgid "Account"
msgstr "Cuenta"
#: web/template/app.gohtml:26
msgctxt "menu"
msgid "Tax Details"
msgstr "Configuración fiscal"
#: web/template/app.gohtml:33
msgctxt "action"
msgid "Logout"
msgstr "Salir"
#: web/template/app.gohtml:42
msgctxt "nav"
Add nav link to dashboard
2023-01-31 12:29:56 +00:00
msgid "Dashboard"
msgstr "Panel"
#: web/template/app.gohtml:43
msgctxt "nav"
Rename Customer to Contact That section is intended for both customers and suppliers, collectively called “contacts”.
2023-02-01 09:14:26 +00:00
msgid "Contacts"
msgstr "Contactos"
Rename extension of templates to .gohtml Apparently, there are tools that only know how to use that extensions when referring to Go templates.
2023-01-30 15:48:21 +00:00
Use a “proper” struct for the login form Similar to the profile form, the login form now parses and validates itself, with the InputField structs that the templates expect. I realized that i was doing more work than necessary when parsing fields fro the profile form because i was repeating the operation and the field name, so now it is a function of InputField. This time i needed extra attributes for the login form. I am not sure that the Go source code needs to know about HTML attributes, but it was the easiest way to pass them to the template.
2023-02-01 10:02:32 +00:00
#: web/template/login.gohtml:2 web/template/login.gohtml:15
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
msgctxt "title"
msgid "Login"
msgstr "Entrada"
Use a “proper” struct for the login form Similar to the profile form, the login form now parses and validates itself, with the InputField structs that the templates expect. I realized that i was doing more work than necessary when parsing fields fro the profile form because i was repeating the operation and the field name, so now it is a function of InputField. This time i needed extra attributes for the login form. I am not sure that the Go source code needs to know about HTML attributes, but it was the easiest way to pass them to the template.
2023-02-01 10:02:32 +00:00
#: web/template/login.gohtml:19
Rename extension of templates to .gohtml Apparently, there are tools that only know how to use that extensions when referring to Go templates.
2023-01-30 15:48:21 +00:00
msgctxt "action"
msgid "Login"
msgstr "Entrar"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/profile.gohtml:2 web/template/profile.gohtml:7
Rename extension of templates to .gohtml Apparently, there are tools that only know how to use that extensions when referring to Go templates.
2023-01-30 15:48:21 +00:00
msgctxt "title"
msgid "User Settings"
msgstr "Configuración usuario"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/profile.gohtml:10
Rename extension of templates to .gohtml Apparently, there are tools that only know how to use that extensions when referring to Go templates.
2023-01-30 15:48:21 +00:00
msgctxt "title"
msgid "User Access Data"
msgstr "Datos acceso usuario"
Validate profile form and use templates for fields Let’s start first with a non-fancy validation method with just if conditionals instead of bringing yet another complicated library. I hope i do not regret it. I wanted to move all the input field to a template because all that gobbledygook with the .input div and repeating the label in the placeholder was starting to annoy me. Now with error messages was even more concerning. I did not know whether the label should be a part of the input fields or something that the template should do. At the end i decided that it makes more sense to be part of the input field because in the error messages i use that same label, thus the template does not have a say in that, and, besides, it was just easier to write the template. The same with the error messages: i’ve seen frameworks that have a map with the field’s id/name to the error slice, but then it would be a bit harder to write the template. I added AddError functions instead of just using append inside the validator function, and have a local variable for whether it all went OK, because i was worried that i would leave out the `ok = false` in some conditions. I had started writing “constructors” functions for InputField and SelectField, but then had to add other methods to change the required field and who knows what else, and in the end it was easier to just construct the field inline.
2023-01-31 14:40:12 +00:00
#: web/template/profile.gohtml:16
Rename extension of templates to .gohtml Apparently, there are tools that only know how to use that extensions when referring to Go templates.
2023-01-30 15:48:21 +00:00
msgctxt "title"
msgid "Password Change"
msgstr "Cambio de contraseña"
Validate profile form and use templates for fields Let’s start first with a non-fancy validation method with just if conditionals instead of bringing yet another complicated library. I hope i do not regret it. I wanted to move all the input field to a template because all that gobbledygook with the .input div and repeating the label in the placeholder was starting to annoy me. Now with error messages was even more concerning. I did not know whether the label should be a part of the input fields or something that the template should do. At the end i decided that it makes more sense to be part of the input field because in the error messages i use that same label, thus the template does not have a say in that, and, besides, it was just easier to write the template. The same with the error messages: i’ve seen frameworks that have a map with the field’s id/name to the error slice, but then it would be a bit harder to write the template. I added AddError functions instead of just using append inside the validator function, and have a local variable for whether it all went OK, because i was worried that i would leave out the `ok = false` in some conditions. I had started writing “constructors” functions for InputField and SelectField, but then had to add other methods to change the required field and who knows what else, and in the end it was easier to just construct the field inline.
2023-01-31 14:40:12 +00:00
#: web/template/profile.gohtml:23
msgctxt "title"
Rename extension of templates to .gohtml Apparently, there are tools that only know how to use that extensions when referring to Go templates.
2023-01-30 15:48:21 +00:00
msgid "Language"
msgstr "Idioma"
Validate profile form and use templates for fields Let’s start first with a non-fancy validation method with just if conditionals instead of bringing yet another complicated library. I hope i do not regret it. I wanted to move all the input field to a template because all that gobbledygook with the .input div and repeating the label in the placeholder was starting to annoy me. Now with error messages was even more concerning. I did not know whether the label should be a part of the input fields or something that the template should do. At the end i decided that it makes more sense to be part of the input field because in the error messages i use that same label, thus the template does not have a say in that, and, besides, it was just easier to write the template. The same with the error messages: i’ve seen frameworks that have a map with the field’s id/name to the error slice, but then it would be a bit harder to write the template. I added AddError functions instead of just using append inside the validator function, and have a local variable for whether it all went OK, because i was worried that i would leave out the `ok = false` in some conditions. I had started writing “constructors” functions for InputField and SelectField, but then had to add other methods to change the required field and who knows what else, and in the end it was easier to just construct the field inline.
2023-01-31 14:40:12 +00:00
#: web/template/profile.gohtml:27 web/template/tax-details.gohtml:133
Rename extension of templates to .gohtml Apparently, there are tools that only know how to use that extensions when referring to Go templates.
2023-01-30 15:48:21 +00:00
msgctxt "action"
msgid "Save changes"
msgstr "Guardar cambios"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/contacts-index.gohtml:2
msgctxt "title"
Rename Customer to Contact That section is intended for both customers and suppliers, collectively called “contacts”.
2023-02-01 09:14:26 +00:00
msgid "Contacts"
msgstr "Contactos"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/contacts-index.gohtml:6 web/template/contacts-new.gohtml:60
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
msgctxt "action"
msgid "New contact"
msgstr "Nuevo contacto"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/contacts-index.gohtml:11
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
msgctxt "contact"
msgid "All"
msgstr "Todos"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/contacts-index.gohtml:12
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
msgctxt "title"
msgid "Customer"
msgstr "Cliente"
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
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/contacts-index.gohtml:13
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
msgctxt "title"
msgid "Email"
msgstr "Correo-e"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/contacts-index.gohtml:14
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
msgctxt "title"
msgid "Phone"
msgstr "Teléfono"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/contacts-index.gohtml:29
Rename Customer to Contact That section is intended for both customers and suppliers, collectively called “contacts”.
2023-02-01 09:14:26 +00:00
msgid "No contacts added yet."
msgstr "No hay contactos."
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:2 web/template/tax-details.gohtml:7
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
msgctxt "title"
Rename extension of templates to .gohtml Apparently, there are tools that only know how to use that extensions when referring to Go templates.
2023-01-30 15:48:21 +00:00
msgid "Tax Details"
msgstr "Configuración fiscal"
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:11 web/template/contacts-new.gohtml:11
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
msgctxt "input"
msgid "Business name"
msgstr "Nombre y apellidos"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:15 web/template/contacts-new.gohtml:15
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
msgctxt "input"
msgid "VAT number"
msgstr "DNI / NIF"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:19 web/template/contacts-new.gohtml:19
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
msgctxt "input"
msgid "Trade name"
msgstr "Nombre comercial"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:23 web/template/contacts-new.gohtml:23
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
msgctxt "input"
msgid "Phone"
msgstr "Teléfono"
Use a “proper” struct for the login form Similar to the profile form, the login form now parses and validates itself, with the InputField structs that the templates expect. I realized that i was doing more work than necessary when parsing fields fro the profile form because i was repeating the operation and the field name, so now it is a function of InputField. This time i needed extra attributes for the login form. I am not sure that the Go source code needs to know about HTML attributes, but it was the easiest way to pass them to the template.
2023-02-01 10:02:32 +00:00
#: web/template/tax-details.gohtml:27 web/template/contacts-new.gohtml:27
Refactor form validation into a new type I was worried that i was repeating the AddInputErrors function for each form, because they were basically the same. I could create a Form type and make all forms embed it, but i realized that with a separate validator i would have cleaner validation functions and would not need the Valid field in the form that i am using only for that method.
2023-02-01 10:30:30 +00:00
#: pkg/login.go:33 pkg/profile.go:35
Use a “proper” struct for the login form Similar to the profile form, the login form now parses and validates itself, with the InputField structs that the templates expect. I realized that i was doing more work than necessary when parsing fields fro the profile form because i was repeating the operation and the field name, so now it is a function of InputField. This time i needed extra attributes for the login form. I am not sure that the Go source code needs to know about HTML attributes, but it was the easiest way to pass them to the template.
2023-02-01 10:02:32 +00:00
msgctxt "input"
msgid "Email"
msgstr "Correo-e"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:31 web/template/contacts-new.gohtml:31
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
msgctxt "input"
msgid "Web"
msgstr "Web"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:35 web/template/contacts-new.gohtml:35
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
msgctxt "input"
msgid "Address"
msgstr "Dirección"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:39 web/template/contacts-new.gohtml:39
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
msgctxt "input"
msgid "City"
msgstr "Población"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:43 web/template/contacts-new.gohtml:43
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
msgctxt "input"
msgid "Province"
msgstr "Provincia"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:47 web/template/contacts-new.gohtml:47
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
msgctxt "input"
msgid "Postal code"
msgstr "Código postal"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:56 web/template/contacts-new.gohtml:56
Add missing Catalan and Spanish translations
2023-01-30 09:52:22 +00:00
msgctxt "input"
msgid "Country"
msgstr "País"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:60
Add fieldset for currency in tax details page
2023-01-28 11:24:52 +00:00
msgctxt "input"
msgid "Currency"
msgstr "Moneda"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:78
Add the tax relation with very rough form and handler
2023-01-28 13:18:58 +00:00
msgctxt "title"
msgid "Tax Name"
msgstr "Nombre impuesto"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:79
Add the tax relation with very rough form and handler
2023-01-28 13:18:58 +00:00
msgctxt "title"
msgid "Rate (%)"
msgstr "Porcentage"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:100
Add the tax relation with very rough form and handler
2023-01-28 13:18:58 +00:00
msgid "No taxes added yet."
msgstr "No hay impuestos."
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:106
Add the tax relation with very rough form and handler
2023-01-28 13:18:58 +00:00
msgctxt "title"
msgid "New Line"
msgstr "Nueva línea"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:111
Add the tax relation with very rough form and handler
2023-01-28 13:18:58 +00:00
msgctxt "input"
msgid "Tax name"
msgstr "Nombre impuesto"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:118
Add the tax relation with very rough form and handler
2023-01-28 13:18:58 +00:00
msgctxt "input"
msgid "Rate (%)"
msgstr "Porcentage"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/tax-details.gohtml:125
Add the tax relation with very rough form and handler
2023-01-28 13:18:58 +00:00
msgctxt "action"
msgid "Add new tax"
msgstr "Añadir nuevo impuesto"
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
#: web/template/contacts-new.gohtml:2 web/template/contacts-new.gohtml:7
Rename extension of templates to .gohtml Apparently, there are tools that only know how to use that extensions when referring to Go templates.
2023-01-30 15:48:21 +00:00
msgctxt "title"
msgid "New Contact"
msgstr "Nuevo contacto"
Validate profile form and use templates for fields Let’s start first with a non-fancy validation method with just if conditionals instead of bringing yet another complicated library. I hope i do not regret it. I wanted to move all the input field to a template because all that gobbledygook with the .input div and repeating the label in the placeholder was starting to annoy me. Now with error messages was even more concerning. I did not know whether the label should be a part of the input fields or something that the template should do. At the end i decided that it makes more sense to be part of the input field because in the error messages i use that same label, thus the template does not have a say in that, and, besides, it was just easier to write the template. The same with the error messages: i’ve seen frameworks that have a map with the field’s id/name to the error slice, but then it would be a bit harder to write the template. I added AddError functions instead of just using append inside the validator function, and have a local variable for whether it all went OK, because i was worried that i would leave out the `ok = false` in some conditions. I had started writing “constructors” functions for InputField and SelectField, but then had to add other methods to change the required field and who knows what else, and in the end it was easier to just construct the field inline.
2023-01-31 14:40:12 +00:00
Refactor form validation into a new type I was worried that i was repeating the AddInputErrors function for each form, because they were basically the same. I could create a Form type and make all forms embed it, but i realized that with a separate validator i would have cleaner validation functions and would not need the Valid field in the form that i am using only for that method.
2023-02-01 10:30:30 +00:00
#: pkg/login.go:44 pkg/profile.go:41
Use a “proper” struct for the login form Similar to the profile form, the login form now parses and validates itself, with the InputField structs that the templates expect. I realized that i was doing more work than necessary when parsing fields fro the profile form because i was repeating the operation and the field name, so now it is a function of InputField. This time i needed extra attributes for the login form. I am not sure that the Go source code needs to know about HTML attributes, but it was the easiest way to pass them to the template.
2023-02-01 10:02:32 +00:00
msgctxt "input"
msgid "Password"
msgstr "Contraseña"
Refactor form validation into a new type I was worried that i was repeating the AddInputErrors function for each form, because they were basically the same. I could create a Form type and make all forms embed it, but i realized that with a separate validator i would have cleaner validation functions and would not need the Valid field in the form that i am using only for that method.
2023-02-01 10:30:30 +00:00
#: pkg/login.go:66 pkg/profile.go:71
Use a “proper” struct for the login form Similar to the profile form, the login form now parses and validates itself, with the InputField structs that the templates expect. I realized that i was doing more work than necessary when parsing fields fro the profile form because i was repeating the operation and the field name, so now it is a function of InputField. This time i needed extra attributes for the login form. I am not sure that the Go source code needs to know about HTML attributes, but it was the easiest way to pass them to the template.
2023-02-01 10:02:32 +00:00
msgid "Email can not be empty."
msgstr "No podéis dejar el correo-e en blanco."
Refactor form validation into a new type I was worried that i was repeating the AddInputErrors function for each form, because they were basically the same. I could create a Form type and make all forms embed it, but i realized that with a separate validator i would have cleaner validation functions and would not need the Valid field in the form that i am using only for that method.
2023-02-01 10:30:30 +00:00
#: pkg/login.go:67 pkg/profile.go:72
Use a “proper” struct for the login form Similar to the profile form, the login form now parses and validates itself, with the InputField structs that the templates expect. I realized that i was doing more work than necessary when parsing fields fro the profile form because i was repeating the operation and the field name, so now it is a function of InputField. This time i needed extra attributes for the login form. I am not sure that the Go source code needs to know about HTML attributes, but it was the easiest way to pass them to the template.
2023-02-01 10:02:32 +00:00
msgid "This value is not a valid email. It should be like name@domain.com."
msgstr "Este valor no es un correo-e válido. Tiene que ser parecido a nombre@dominio.es."
Refactor form validation into a new type I was worried that i was repeating the AddInputErrors function for each form, because they were basically the same. I could create a Form type and make all forms embed it, but i realized that with a separate validator i would have cleaner validation functions and would not need the Valid field in the form that i am using only for that method.
2023-02-01 10:30:30 +00:00
#: pkg/login.go:69
Use a “proper” struct for the login form Similar to the profile form, the login form now parses and validates itself, with the InputField structs that the templates expect. I realized that i was doing more work than necessary when parsing fields fro the profile form because i was repeating the operation and the field name, so now it is a function of InputField. This time i needed extra attributes for the login form. I am not sure that the Go source code needs to know about HTML attributes, but it was the easiest way to pass them to the template.
2023-02-01 10:02:32 +00:00
msgid "Password can not be empty."
msgstr "No podéis dejar la contaseña en blanco."
Refactor form validation into a new type I was worried that i was repeating the AddInputErrors function for each form, because they were basically the same. I could create a Form type and make all forms embed it, but i realized that with a separate validator i would have cleaner validation functions and would not need the Valid field in the form that i am using only for that method.
2023-02-01 10:30:30 +00:00
#: pkg/login.go:95
Use a “proper” struct for the login form Similar to the profile form, the login form now parses and validates itself, with the InputField structs that the templates expect. I realized that i was doing more work than necessary when parsing fields fro the profile form because i was repeating the operation and the field name, so now it is a function of InputField. This time i needed extra attributes for the login form. I am not sure that the Go source code needs to know about HTML attributes, but it was the easiest way to pass them to the template.
2023-02-01 10:02:32 +00:00
msgid "Invalid user or password."
msgstr "Nombre de usuario o contraseña inválido."
Refactor form validation into a new type I was worried that i was repeating the AddInputErrors function for each form, because they were basically the same. I could create a Form type and make all forms embed it, but i realized that with a separate validator i would have cleaner validation functions and would not need the Valid field in the form that i am using only for that method.
2023-02-01 10:30:30 +00:00
#: pkg/profile.go:23
Validate profile form and use templates for fields Let’s start first with a non-fancy validation method with just if conditionals instead of bringing yet another complicated library. I hope i do not regret it. I wanted to move all the input field to a template because all that gobbledygook with the .input div and repeating the label in the placeholder was starting to annoy me. Now with error messages was even more concerning. I did not know whether the label should be a part of the input fields or something that the template should do. At the end i decided that it makes more sense to be part of the input field because in the error messages i use that same label, thus the template does not have a say in that, and, besides, it was just easier to write the template. The same with the error messages: i’ve seen frameworks that have a map with the field’s id/name to the error slice, but then it would be a bit harder to write the template. I added AddError functions instead of just using append inside the validator function, and have a local variable for whether it all went OK, because i was worried that i would leave out the `ok = false` in some conditions. I had started writing “constructors” functions for InputField and SelectField, but then had to add other methods to change the required field and who knows what else, and in the end it was easier to just construct the field inline.
2023-01-31 14:40:12 +00:00
msgctxt "language option"
msgid "Automatic"
msgstr "Automático"
Refactor form validation into a new type I was worried that i was repeating the AddInputErrors function for each form, because they were basically the same. I could create a Form type and make all forms embed it, but i realized that with a separate validator i would have cleaner validation functions and would not need the Valid field in the form that i am using only for that method.
2023-02-01 10:30:30 +00:00
#: pkg/profile.go:29
Validate profile form and use templates for fields Let’s start first with a non-fancy validation method with just if conditionals instead of bringing yet another complicated library. I hope i do not regret it. I wanted to move all the input field to a template because all that gobbledygook with the .input div and repeating the label in the placeholder was starting to annoy me. Now with error messages was even more concerning. I did not know whether the label should be a part of the input fields or something that the template should do. At the end i decided that it makes more sense to be part of the input field because in the error messages i use that same label, thus the template does not have a say in that, and, besides, it was just easier to write the template. The same with the error messages: i’ve seen frameworks that have a map with the field’s id/name to the error slice, but then it would be a bit harder to write the template. I added AddError functions instead of just using append inside the validator function, and have a local variable for whether it all went OK, because i was worried that i would leave out the `ok = false` in some conditions. I had started writing “constructors” functions for InputField and SelectField, but then had to add other methods to change the required field and who knows what else, and in the end it was easier to just construct the field inline.
2023-01-31 14:40:12 +00:00
msgctxt "input"
msgid "User name"
msgstr "Nombre de usuario"
Refactor form validation into a new type I was worried that i was repeating the AddInputErrors function for each form, because they were basically the same. I could create a Form type and make all forms embed it, but i realized that with a separate validator i would have cleaner validation functions and would not need the Valid field in the form that i am using only for that method.
2023-02-01 10:30:30 +00:00
#: pkg/profile.go:46
Validate profile form and use templates for fields Let’s start first with a non-fancy validation method with just if conditionals instead of bringing yet another complicated library. I hope i do not regret it. I wanted to move all the input field to a template because all that gobbledygook with the .input div and repeating the label in the placeholder was starting to annoy me. Now with error messages was even more concerning. I did not know whether the label should be a part of the input fields or something that the template should do. At the end i decided that it makes more sense to be part of the input field because in the error messages i use that same label, thus the template does not have a say in that, and, besides, it was just easier to write the template. The same with the error messages: i’ve seen frameworks that have a map with the field’s id/name to the error slice, but then it would be a bit harder to write the template. I added AddError functions instead of just using append inside the validator function, and have a local variable for whether it all went OK, because i was worried that i would leave out the `ok = false` in some conditions. I had started writing “constructors” functions for InputField and SelectField, but then had to add other methods to change the required field and who knows what else, and in the end it was easier to just construct the field inline.
2023-01-31 14:40:12 +00:00
msgctxt "input"
msgid "Password Confirmation"
msgstr "Confirmación contrasenya"
Refactor form validation into a new type I was worried that i was repeating the AddInputErrors function for each form, because they were basically the same. I could create a Form type and make all forms embed it, but i realized that with a separate validator i would have cleaner validation functions and would not need the Valid field in the form that i am using only for that method.
2023-02-01 10:30:30 +00:00
#: pkg/profile.go:51
Validate profile form and use templates for fields Let’s start first with a non-fancy validation method with just if conditionals instead of bringing yet another complicated library. I hope i do not regret it. I wanted to move all the input field to a template because all that gobbledygook with the .input div and repeating the label in the placeholder was starting to annoy me. Now with error messages was even more concerning. I did not know whether the label should be a part of the input fields or something that the template should do. At the end i decided that it makes more sense to be part of the input field because in the error messages i use that same label, thus the template does not have a say in that, and, besides, it was just easier to write the template. The same with the error messages: i’ve seen frameworks that have a map with the field’s id/name to the error slice, but then it would be a bit harder to write the template. I added AddError functions instead of just using append inside the validator function, and have a local variable for whether it all went OK, because i was worried that i would leave out the `ok = false` in some conditions. I had started writing “constructors” functions for InputField and SelectField, but then had to add other methods to change the required field and who knows what else, and in the end it was easier to just construct the field inline.
2023-01-31 14:40:12 +00:00
msgctxt "input"
msgid "Language"
msgstr "Idioma"
Refactor form validation into a new type I was worried that i was repeating the AddInputErrors function for each form, because they were basically the same. I could create a Form type and make all forms embed it, but i realized that with a separate validator i would have cleaner validation functions and would not need the Valid field in the form that i am using only for that method.
2023-02-01 10:30:30 +00:00
#: pkg/profile.go:74
Validate profile form and use templates for fields Let’s start first with a non-fancy validation method with just if conditionals instead of bringing yet another complicated library. I hope i do not regret it. I wanted to move all the input field to a template because all that gobbledygook with the .input div and repeating the label in the placeholder was starting to annoy me. Now with error messages was even more concerning. I did not know whether the label should be a part of the input fields or something that the template should do. At the end i decided that it makes more sense to be part of the input field because in the error messages i use that same label, thus the template does not have a say in that, and, besides, it was just easier to write the template. The same with the error messages: i’ve seen frameworks that have a map with the field’s id/name to the error slice, but then it would be a bit harder to write the template. I added AddError functions instead of just using append inside the validator function, and have a local variable for whether it all went OK, because i was worried that i would leave out the `ok = false` in some conditions. I had started writing “constructors” functions for InputField and SelectField, but then had to add other methods to change the required field and who knows what else, and in the end it was easier to just construct the field inline.
2023-01-31 14:40:12 +00:00
msgid "Name can not be empty."
msgstr "No podéis dejar el nombre en blanco."
Refactor form validation into a new type I was worried that i was repeating the AddInputErrors function for each form, because they were basically the same. I could create a Form type and make all forms embed it, but i realized that with a separate validator i would have cleaner validation functions and would not need the Valid field in the form that i am using only for that method.
2023-02-01 10:30:30 +00:00
#: pkg/profile.go:75
Validate profile form and use templates for fields Let’s start first with a non-fancy validation method with just if conditionals instead of bringing yet another complicated library. I hope i do not regret it. I wanted to move all the input field to a template because all that gobbledygook with the .input div and repeating the label in the placeholder was starting to annoy me. Now with error messages was even more concerning. I did not know whether the label should be a part of the input fields or something that the template should do. At the end i decided that it makes more sense to be part of the input field because in the error messages i use that same label, thus the template does not have a say in that, and, besides, it was just easier to write the template. The same with the error messages: i’ve seen frameworks that have a map with the field’s id/name to the error slice, but then it would be a bit harder to write the template. I added AddError functions instead of just using append inside the validator function, and have a local variable for whether it all went OK, because i was worried that i would leave out the `ok = false` in some conditions. I had started writing “constructors” functions for InputField and SelectField, but then had to add other methods to change the required field and who knows what else, and in the end it was easier to just construct the field inline.
2023-01-31 14:40:12 +00:00
msgid "Confirmation does not match password."
msgstr "La confirmación no corresponde con la contraseña."
Refactor form validation into a new type I was worried that i was repeating the AddInputErrors function for each form, because they were basically the same. I could create a Form type and make all forms embed it, but i realized that with a separate validator i would have cleaner validation functions and would not need the Valid field in the form that i am using only for that method.
2023-02-01 10:30:30 +00:00
#: pkg/profile.go:76
Validate profile form and use templates for fields Let’s start first with a non-fancy validation method with just if conditionals instead of bringing yet another complicated library. I hope i do not regret it. I wanted to move all the input field to a template because all that gobbledygook with the .input div and repeating the label in the placeholder was starting to annoy me. Now with error messages was even more concerning. I did not know whether the label should be a part of the input fields or something that the template should do. At the end i decided that it makes more sense to be part of the input field because in the error messages i use that same label, thus the template does not have a say in that, and, besides, it was just easier to write the template. The same with the error messages: i’ve seen frameworks that have a map with the field’s id/name to the error slice, but then it would be a bit harder to write the template. I added AddError functions instead of just using append inside the validator function, and have a local variable for whether it all went OK, because i was worried that i would leave out the `ok = false` in some conditions. I had started writing “constructors” functions for InputField and SelectField, but then had to add other methods to change the required field and who knows what else, and in the end it was easier to just construct the field inline.
2023-01-31 14:40:12 +00:00
msgid "Selected language is not valid."
msgstr "Habéis escogido un idioma que no es válido."
Rename Customer to Contact That section is intended for both customers and suppliers, collectively called “contacts”.
2023-02-01 09:14:26 +00:00
#~ msgctxt "nav"
#~ msgid "Customers"
#~ msgstr "Clientes"
#~ msgctxt "title"
#~ msgid "Customers"
#~ msgstr "Clientes"
#~ msgid "No customers added yet."
#~ msgstr "No hay clientes."