2023-12-13 22:55:43 +00:00
# French translations for camper package
# Traductions françaises du paquet camper.
# Copyright (C) 2023 THE camper'S COPYRIGHT HOLDER
# This file is distributed under the same license as the camper package.
# jordi fita mas <jordi@tandem.blog>, 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: camper\n"
"Report-Msgid-Bugs-To: jordi@tandem.blog\n"
2024-02-13 04:20:35 +00:00
"POT-Creation-Date: 2024-02-13 05:02+0100\n"
2024-02-06 09:55:29 +00:00
"PO-Revision-Date: 2024-02-06 10:05+0100\n"
2023-12-20 12:01:52 +00:00
"Last-Translator: Oriol Carbonell <info@oriolcarbonell.cat>\n"
2023-12-13 22:55:43 +00:00
"Language-Team: French <traduc@traduc.org>\n"
"Language: fr\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"
2024-02-06 09:55:29 +00:00
"X-Generator: Poedit 3.4.2\n"
2023-12-13 22:55:43 +00:00
2024-01-31 14:12:11 +00:00
#: web/templates/campground_map.svg:1598
msgctxt "title"
msgid "Zones"
msgstr "Zones"
#: web/templates/campground_map.svg:1599
msgctxt "tooltip"
msgid "Zone 7"
msgstr "Zone 7"
#: web/templates/campground_map.svg:1600
msgctxt "tooltip"
msgid "Zone 6"
msgstr "Zone 6"
#: web/templates/campground_map.svg:1601
msgctxt "tooltip"
msgid "Zone 5"
msgstr "Zone 5"
#: web/templates/campground_map.svg:1602
msgctxt "tooltip"
msgid "Zone 4"
msgstr "Zone 4"
#: web/templates/campground_map.svg:1603
msgctxt "tooltip"
msgid "Zone 3"
msgstr "Zone 3"
#: web/templates/campground_map.svg:1604
msgctxt "tooltip"
msgid "Zone 2"
msgstr "Zone 2"
#: web/templates/campground_map.svg:1605
msgctxt "tooltip"
msgid "Zone 1"
msgstr "Zone 1"
2024-02-13 04:20:35 +00:00
#: web/templates/mail/payment/body.gohtml:6
msgctxt "title"
msgid "Booking Payment Notification"
msgstr "Notification de paiement de réservation"
#: web/templates/mail/payment/body.gohtml:33
#: web/templates/mail/payment/body.gotxt:1
msgid "Hi %s,"
msgstr "Salut %s,"
#: web/templates/mail/payment/body.gohtml:35
#: web/templates/mail/payment/body.gotxt:3
msgid "We have successfully received the payment for the booking with the following details:"
msgstr "Nous avons reçu avec succès le paiement de la réservation avec les détails suivants :"
#: web/templates/mail/payment/body.gohtml:37
msgid "Payment reference: <strong>%s</strong>"
msgstr "Référence de paiement : <strong>%s</strong>."
#: web/templates/mail/payment/body.gohtml:39
msgid "Accommodation: <strong>%s</strong>"
msgstr "Hébergement : < strong>%s</strong>"
#: web/templates/mail/payment/body.gohtml:41
msgid "Arrival Date: <strong>%s</strong>"
msgstr "Date d’ arrivée : <strong>%s</strong>"
#: web/templates/mail/payment/body.gohtml:43
msgid "Departure Date: <strong>%s</strong>"
msgstr "Date de depart : <strong>%s</strong>"
#: web/templates/mail/payment/body.gohtml:45
msgid "Total: <strong>%s</strong>"
msgstr "Totale : <strong>%s</strong>"
#: web/templates/mail/payment/body.gohtml:48
#: web/templates/mail/payment/body.gotxt:11
msgid "Thank you for your booking, and see you soon!"
msgstr "Merci pour votre réservation et à bientôt !"
#: web/templates/mail/payment/body.gotxt:5
msgid "Payment reference: **%s**"
msgstr "Référence de paiement : **%s**"
#: web/templates/mail/payment/body.gotxt:6
msgid "Accommodation: **%s**"
msgstr "Hébergement : **%s**"
#: web/templates/mail/payment/body.gotxt:7
msgid "Arrival Date: **%s**"
msgstr "Date d’ arrivée : **%s**"
#: web/templates/mail/payment/body.gotxt:8
msgid "Departure Date: **%s**"
msgstr "Date de depart : **%s**"
#: web/templates/mail/payment/body.gotxt:9
msgid "Total: **%s**"
msgstr "Totale : **%s**"
2023-12-13 22:55:43 +00:00
#: web/templates/public/payment/success.gohtml:6
msgctxt "title"
msgid "Payment Successful"
2023-12-20 12:01:52 +00:00
msgstr "Paiement réussi"
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: web/templates/public/payment/success.gohtml:12
msgid "We have received the payment. Thank you."
msgstr "Nous avons reçu le paiement. Merci."
2023-12-13 22:55:43 +00:00
#: web/templates/public/payment/request.gohtml:6
msgctxt "title"
2024-02-12 17:06:17 +00:00
msgid "Booking Payment"
msgstr "Paiement de la réservation"
#: web/templates/public/payment/request.gohtml:18
msgid "Thank you for your booking. Please, click the button below to pay with a credit card via Servired/Redsys."
msgstr "Merci pour votre réservation. Veuillez cliquer sur le bouton ci-dessous pour payer avec une carte de crédit via Servired/Redsys."
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: web/templates/public/payment/request.gohtml:27
2023-12-13 22:55:43 +00:00
msgctxt "action"
2024-02-12 17:06:17 +00:00
msgid "Pay with credit card"
msgstr "Payez avec une carte de crédit"
#: web/templates/public/payment/request.gohtml:30
msgid "Please, wait until we redirect you to the payment page."
msgstr "Veuillez attendre que nous vous redirigeons vers la page de paiement."
2023-12-13 22:55:43 +00:00
#: web/templates/public/payment/failure.gohtml:6
msgctxt "title"
msgid "Payment Failed"
2023-12-20 12:01:52 +00:00
msgstr "Le paiement a échoué"
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: web/templates/public/payment/failure.gohtml:12
msgid "We could not process the payment. Please, contact us for support."
msgstr "Nous n’ avons pas pu traiter le paiement. S’ il vous plaît, contactez-nous pour obtenir de l’ aide."
#: web/templates/public/payment/details.gohtml:4
msgctxt "title"
msgid "Order Number"
msgstr "Numéro de commande"
#: web/templates/public/payment/details.gohtml:8
msgctxt "title"
msgid "Date"
msgstr "Date"
#: web/templates/public/payment/details.gohtml:12
msgctxt "title"
msgid "Total"
msgstr "Totale"
Add home’s cover carousel
This is a separate carousel from the one displayed at the bottom with
location info; it is, i suppose, a carousel for the hero image.
For the database, it works exactly as the home carousel, but on the
front had to use AlpineJS instead of Slick because it needs to show a
text popping up from the bottom when the slide is show, something i do
not know how to do in Slick.
It now makes no sense to have the carousel inside the “nature” section,
because the heading is no longer in there, and moved it out into a new
“hero” div.
Since i now have two carousels in home, i had to add additional
attributes to carousel.AdminHandler to know which URL to point to when
POSTing, PUTting, or redirecting.
2024-01-16 20:05:52 +00:00
#: web/templates/public/services.gohtml:7
#: web/templates/public/services.gohtml:16
#: web/templates/public/layout.gohtml:67 web/templates/public/layout.gohtml:95
2024-01-21 21:44:04 +00:00
#: web/templates/admin/services/index.gohtml:59
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Services"
2023-12-20 12:01:52 +00:00
msgstr "Services"
2023-12-13 22:55:43 +00:00
Add home’s cover carousel
This is a separate carousel from the one displayed at the bottom with
location info; it is, i suppose, a carousel for the hero image.
For the database, it works exactly as the home carousel, but on the
front had to use AlpineJS instead of Slick because it needs to show a
text popping up from the bottom when the slide is show, something i do
not know how to do in Slick.
It now makes no sense to have the carousel inside the “nature” section,
because the heading is no longer in there, and moved it out into a new
“hero” div.
Since i now have two carousels in home, i had to add additional
attributes to carousel.AdminHandler to know which URL to point to when
POSTing, PUTting, or redirecting.
2024-01-16 20:05:52 +00:00
#: web/templates/public/services.gohtml:19
2023-12-13 22:55:43 +00:00
msgid "The campsite offers many different services."
2023-12-20 12:01:52 +00:00
msgstr "Le camping propose de nombreux services différents."
2023-12-13 22:55:43 +00:00
2024-01-27 21:51:41 +00:00
#: web/templates/public/amenity.gohtml:39
2024-02-11 20:45:00 +00:00
#: web/templates/public/campsite/type.gohtml:114
2024-01-27 21:51:41 +00:00
#: web/templates/public/campsite/page.gohtml:39
msgctxt "title"
msgid "Features"
msgstr "Caractéristiques"
Add home’s cover carousel
This is a separate carousel from the one displayed at the bottom with
location info; it is, i suppose, a carousel for the hero image.
For the database, it works exactly as the home carousel, but on the
front had to use AlpineJS instead of Slick because it needs to show a
text popping up from the bottom when the slide is show, something i do
not know how to do in Slick.
It now makes no sense to have the carousel inside the “nature” section,
because the heading is no longer in there, and moved it out into a new
“hero” div.
Since i now have two carousels in home, i had to add additional
attributes to carousel.AdminHandler to know which URL to point to when
POSTing, PUTting, or redirecting.
2024-01-16 20:05:52 +00:00
#: web/templates/public/location.gohtml:7
#: web/templates/public/location.gohtml:13
#: web/templates/public/layout.gohtml:69 web/templates/public/layout.gohtml:97
2024-01-27 21:51:41 +00:00
#: web/templates/admin/layout.gohtml:64
2023-12-21 20:17:04 +00:00
msgctxt "title"
msgid "Location"
msgstr "Comment nous rejoindre"
Add home’s cover carousel
This is a separate carousel from the one displayed at the bottom with
location info; it is, i suppose, a carousel for the hero image.
For the database, it works exactly as the home carousel, but on the
front had to use AlpineJS instead of Slick because it needs to show a
text popping up from the bottom when the slide is show, something i do
not know how to do in Slick.
It now makes no sense to have the carousel inside the “nature” section,
because the heading is no longer in there, and moved it out into a new
“hero” div.
Since i now have two carousels in home, i had to add additional
attributes to carousel.AdminHandler to know which URL to point to when
POSTing, PUTting, or redirecting.
2024-01-16 20:05:52 +00:00
#: web/templates/public/home.gohtml:7 web/templates/public/layout.gohtml:53
#: web/templates/public/layout.gohtml:93
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Home"
2023-12-20 12:01:52 +00:00
msgstr "Accueil"
2023-12-13 22:55:43 +00:00
Add admin page to list the users
There is no way, for now, to add, edit or remove users, because
currently we only need to list users.
I can not give admins access to the user table, for security
permissions, so i had to create a new view. I could name it also ‘user’
in ‘camper’ scheme, but then i was afraid i would have problems with
unit tests and their search_path, so instead i called it
‘company_user_profile’, which is like ‘user_profile’ but for all users
in ‘company_user’.
I created a new Go package for it, rather than add the admin handler in
‘auth’, because ‘template’ depends on ‘auth’, and rendering from ‘auth’
would cause a dependency loop.
I needed to have the roles in gettext to translate them, but there is
no obvious place where to put the call to PgettextNoop. For now, there
are in ‘NewAdminHandler’ because it is called once in the application’s
lifetime and they actually do not matter much.
2024-01-17 18:42:47 +00:00
#: web/templates/public/home.gohtml:25
2023-12-13 22:55:43 +00:00
msgctxt "link"
msgid "Booking"
2023-12-20 12:01:52 +00:00
msgstr "Réservation"
2023-12-13 22:55:43 +00:00
Add admin page to list the users
There is no way, for now, to add, edit or remove users, because
currently we only need to list users.
I can not give admins access to the user table, for security
permissions, so i had to create a new view. I could name it also ‘user’
in ‘camper’ scheme, but then i was afraid i would have problems with
unit tests and their search_path, so instead i called it
‘company_user_profile’, which is like ‘user_profile’ but for all users
in ‘company_user’.
I created a new Go package for it, rather than add the admin handler in
‘auth’, because ‘template’ depends on ‘auth’, and rendering from ‘auth’
would cause a dependency loop.
I needed to have the roles in gettext to translate them, but there is
no obvious place where to put the call to PgettextNoop. For now, there
are in ‘NewAdminHandler’ because it is called once in the application’s
lifetime and they actually do not matter much.
2024-01-17 18:42:47 +00:00
#: web/templates/public/home.gohtml:28
Add home’s cover carousel
This is a separate carousel from the one displayed at the bottom with
location info; it is, i suppose, a carousel for the hero image.
For the database, it works exactly as the home carousel, but on the
front had to use AlpineJS instead of Slick because it needs to show a
text popping up from the bottom when the slide is show, something i do
not know how to do in Slick.
It now makes no sense to have the carousel inside the “nature” section,
because the heading is no longer in there, and moved it out into a new
“hero” div.
Since i now have two carousels in home, i had to add additional
attributes to carousel.AdminHandler to know which URL to point to when
POSTing, PUTting, or redirecting.
2024-01-16 20:05:52 +00:00
msgid "The pleasure of camping in the middle of nature…"
msgstr "Le plaisir de camper en pleine nature…"
Add admin page to list the users
There is no way, for now, to add, edit or remove users, because
currently we only need to list users.
I can not give admins access to the user table, for security
permissions, so i had to create a new view. I could name it also ‘user’
in ‘camper’ scheme, but then i was afraid i would have problems with
unit tests and their search_path, so instead i called it
‘company_user_profile’, which is like ‘user_profile’ but for all users
in ‘company_user’.
I created a new Go package for it, rather than add the admin handler in
‘auth’, because ‘template’ depends on ‘auth’, and rendering from ‘auth’
would cause a dependency loop.
I needed to have the roles in gettext to translate them, but there is
no obvious place where to put the call to PgettextNoop. For now, there
are in ‘NewAdminHandler’ because it is called once in the application’s
lifetime and they actually do not matter much.
2024-01-17 18:42:47 +00:00
#: web/templates/public/home.gohtml:40
2023-12-13 22:55:43 +00:00
msgid "Our services"
2023-12-20 12:01:52 +00:00
msgstr "Nos services"
2023-12-13 22:55:43 +00:00
Add admin page to list the users
There is no way, for now, to add, edit or remove users, because
currently we only need to list users.
I can not give admins access to the user table, for security
permissions, so i had to create a new view. I could name it also ‘user’
in ‘camper’ scheme, but then i was afraid i would have problems with
unit tests and their search_path, so instead i called it
‘company_user_profile’, which is like ‘user_profile’ but for all users
in ‘company_user’.
I created a new Go package for it, rather than add the admin handler in
‘auth’, because ‘template’ depends on ‘auth’, and rendering from ‘auth’
would cause a dependency loop.
I needed to have the roles in gettext to translate them, but there is
no obvious place where to put the call to PgettextNoop. For now, there
are in ‘NewAdminHandler’ because it is called once in the application’s
lifetime and they actually do not matter much.
2024-01-17 18:42:47 +00:00
#: web/templates/public/home.gohtml:44
Add home’s cover carousel
This is a separate carousel from the one displayed at the bottom with
location info; it is, i suppose, a carousel for the hero image.
For the database, it works exactly as the home carousel, but on the
front had to use AlpineJS instead of Slick because it needs to show a
text popping up from the bottom when the slide is show, something i do
not know how to do in Slick.
It now makes no sense to have the carousel inside the “nature” section,
because the heading is no longer in there, and moved it out into a new
“hero” div.
Since i now have two carousels in home, i had to add additional
attributes to carousel.AdminHandler to know which URL to point to when
POSTing, PUTting, or redirecting.
2024-01-16 20:05:52 +00:00
#: web/templates/public/surroundings.gohtml:7
#: web/templates/public/surroundings.gohtml:12
#: web/templates/public/layout.gohtml:68 web/templates/public/layout.gohtml:96
2024-01-21 21:44:04 +00:00
#: web/templates/admin/surroundings/form.gohtml:15
2024-01-27 21:51:41 +00:00
#: web/templates/admin/layout.gohtml:67
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Surroundings"
2023-12-20 12:01:52 +00:00
msgstr "Entourage"
2023-12-13 22:55:43 +00:00
Add admin page to list the users
There is no way, for now, to add, edit or remove users, because
currently we only need to list users.
I can not give admins access to the user table, for security
permissions, so i had to create a new view. I could name it also ‘user’
in ‘camper’ scheme, but then i was afraid i would have problems with
unit tests and their search_path, so instead i called it
‘company_user_profile’, which is like ‘user_profile’ but for all users
in ‘company_user’.
I created a new Go package for it, rather than add the admin handler in
‘auth’, because ‘template’ depends on ‘auth’, and rendering from ‘auth’
would cause a dependency loop.
I needed to have the roles in gettext to translate them, but there is
no obvious place where to put the call to PgettextNoop. For now, there
are in ‘NewAdminHandler’ because it is called once in the application’s
lifetime and they actually do not matter much.
2024-01-17 18:42:47 +00:00
#: web/templates/public/home.gohtml:47
2023-12-18 20:23:03 +00:00
msgid "Located in <strong>Alta Garrotxa</strong>, between the <strong>Pyrenees</strong> and the <strong>Costa Brava</strong>."
msgstr "Situé dans <strong>l’ Alta Garrotxa</strong>, entre les <strong>Pyrénées</strong> et la <strong>Costa Brava</strong>."
2023-12-13 22:55:43 +00:00
Add admin page to list the users
There is no way, for now, to add, edit or remove users, because
currently we only need to list users.
I can not give admins access to the user table, for security
permissions, so i had to create a new view. I could name it also ‘user’
in ‘camper’ scheme, but then i was afraid i would have problems with
unit tests and their search_path, so instead i called it
‘company_user_profile’, which is like ‘user_profile’ but for all users
in ‘company_user’.
I created a new Go package for it, rather than add the admin handler in
‘auth’, because ‘template’ depends on ‘auth’, and rendering from ‘auth’
would cause a dependency loop.
I needed to have the roles in gettext to translate them, but there is
no obvious place where to put the call to PgettextNoop. For now, there
are in ‘NewAdminHandler’ because it is called once in the application’s
lifetime and they actually do not matter much.
2024-01-17 18:42:47 +00:00
#: web/templates/public/home.gohtml:48
2023-12-18 20:23:03 +00:00
msgid "Nearby there are the <strong>gorges of Sadernes</strong>, <strong>volcanoes</strong>, <strong>La Fageda d’ en Jordà</strong>, the Jewish quarter of <strong>Besalú</strong>, the basaltic cliff of <strong>Castellfollit de la Roca</strong>… much to see and much to do."
msgstr "A proximité il y a les <strong>gorges de Sadernes</strong>, les <strong>volcans</strong>, <strong>La Fageda dâen Jordã </strong>, le quartier juif de <strong>Besalú</strong>, la falaise basaltique de <strong>Castellfollit de la Roca</strong>… beaucoup à voir et beaucoup à faire."
2023-12-13 22:55:43 +00:00
Add admin page to list the users
There is no way, for now, to add, edit or remove users, because
currently we only need to list users.
I can not give admins access to the user table, for security
permissions, so i had to create a new view. I could name it also ‘user’
in ‘camper’ scheme, but then i was afraid i would have problems with
unit tests and their search_path, so instead i called it
‘company_user_profile’, which is like ‘user_profile’ but for all users
in ‘company_user’.
I created a new Go package for it, rather than add the admin handler in
‘auth’, because ‘template’ depends on ‘auth’, and rendering from ‘auth’
would cause a dependency loop.
I needed to have the roles in gettext to translate them, but there is
no obvious place where to put the call to PgettextNoop. For now, there
are in ‘NewAdminHandler’ because it is called once in the application’s
lifetime and they actually do not matter much.
2024-01-17 18:42:47 +00:00
#: web/templates/public/home.gohtml:49
2023-12-18 20:23:03 +00:00
msgid "Less than an hour from <strong>Girona</strong>, one from <strong>La Bisbal d’ Empordà</strong>, and two from <strong>Barcelona</strong>."
msgstr "À moins d’ une heure de <strong>Gérone</strong>, un de <strong>La Bisbal d’ Empordà</strong>et deux de <strong>Barcelone</strong>."
2023-12-13 22:55:43 +00:00
Add admin page to list the users
There is no way, for now, to add, edit or remove users, because
currently we only need to list users.
I can not give admins access to the user table, for security
permissions, so i had to create a new view. I could name it also ‘user’
in ‘camper’ scheme, but then i was afraid i would have problems with
unit tests and their search_path, so instead i called it
‘company_user_profile’, which is like ‘user_profile’ but for all users
in ‘company_user’.
I created a new Go package for it, rather than add the admin handler in
‘auth’, because ‘template’ depends on ‘auth’, and rendering from ‘auth’
would cause a dependency loop.
I needed to have the roles in gettext to translate them, but there is
no obvious place where to put the call to PgettextNoop. For now, there
are in ‘NewAdminHandler’ because it is called once in the application’s
lifetime and they actually do not matter much.
2024-01-17 18:42:47 +00:00
#: web/templates/public/home.gohtml:50
2024-02-06 09:55:29 +00:00
msgid "Discover"
msgstr "Découvrir"
2023-12-13 22:55:43 +00:00
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
#: web/templates/public/campsite/type.gohtml:49
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:245
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Book"
2023-12-20 12:01:52 +00:00
msgstr "Réserver"
2023-12-13 22:55:43 +00:00
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
#: web/templates/public/campsite/type.gohtml:57
2024-01-21 21:44:04 +00:00
#: web/templates/admin/season/index.gohtml:54
2023-12-22 02:32:40 +00:00
msgctxt "title"
msgid "Calendar"
msgstr "Calendrier"
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
#: web/templates/public/campsite/type.gohtml:68
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:153
2024-02-11 21:06:00 +00:00
#: web/templates/admin/campsite/type/option/form.gohtml:70
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Prices"
2023-12-20 12:01:52 +00:00
msgstr "Prix"
2023-12-13 22:55:43 +00:00
2024-02-11 20:45:00 +00:00
#: web/templates/public/campsite/type.gohtml:82
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "%s: %s/night"
msgstr "%s : %s/nuit"
2023-12-22 02:32:40 +00:00
2024-02-11 20:45:00 +00:00
#: web/templates/public/campsite/type.gohtml:84
msgid "%s: %s"
msgstr "%s : %s"
#: web/templates/public/campsite/type.gohtml:88
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "%s/night"
msgstr "%s/nuit"
2024-01-14 01:09:17 +00:00
2024-02-11 20:45:00 +00:00
#: web/templates/public/campsite/type.gohtml:96
2023-12-18 20:23:03 +00:00
msgid "*Minimum %d nights per stay"
msgstr "*Minimum %d nuits par séjour"
2023-12-13 22:55:43 +00:00
2024-02-11 20:45:00 +00:00
#: web/templates/public/campsite/type.gohtml:101
2024-01-15 00:45:58 +00:00
msgid "10 % VAT included."
msgstr "10 % TVA incluse."
2024-02-11 20:45:00 +00:00
#: web/templates/public/campsite/type.gohtml:102
2024-01-18 14:27:46 +00:00
msgid "Tourist tax: %s/night per person aged 17 or older."
msgstr "Taxe touristique: %s/nuit par personne de plus de 16 ans."
2024-01-15 00:45:58 +00:00
2024-02-11 20:45:00 +00:00
#: web/templates/public/campsite/type.gohtml:104
2024-01-15 01:07:32 +00:00
msgid "Dogs: %s/night, tied, accompanied, and minimal barking."
msgstr "Chiens : %s/nuit, attachés, accompagnés et aboiements minimes."
2024-02-11 20:45:00 +00:00
#: web/templates/public/campsite/type.gohtml:106
2024-01-15 01:07:32 +00:00
msgid "No dogs allowed."
msgstr "Chiens interdits."
2024-02-11 20:45:00 +00:00
#: web/templates/public/campsite/type.gohtml:125
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Info"
2023-12-20 12:01:52 +00:00
msgstr "Info"
2023-12-13 22:55:43 +00:00
2024-02-11 20:45:00 +00:00
#: web/templates/public/campsite/type.gohtml:129
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Facilities"
2023-12-20 12:01:52 +00:00
msgstr "Installations"
2023-12-13 22:55:43 +00:00
2024-02-11 20:45:00 +00:00
#: web/templates/public/campsite/type.gohtml:133
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Description"
2023-12-20 12:01:52 +00:00
msgstr "Description"
2023-12-13 22:55:43 +00:00
2024-02-11 20:45:00 +00:00
#: web/templates/public/campsite/type.gohtml:137
2024-01-14 23:28:34 +00:00
msgctxt "title"
msgid "Additional Information"
msgstr "Informations Complémentaires"
2024-02-11 20:45:00 +00:00
#: web/templates/public/campsite/type.gohtml:140
2024-01-15 00:02:50 +00:00
msgctxt "time"
2024-01-22 19:19:19 +00:00
msgid "Check-in"
2024-01-15 00:02:50 +00:00
msgstr "Arrivée"
2024-02-11 20:45:00 +00:00
#: web/templates/public/campsite/type.gohtml:144
2024-01-15 00:02:50 +00:00
msgctxt "time"
2024-01-22 19:19:19 +00:00
msgid "Check-out"
2024-01-15 00:02:50 +00:00
msgstr "Départ"
2023-12-13 22:55:43 +00:00
#: web/templates/public/campsite/calendar.gohtml:18
#: web/templates/admin/season/calendar.gohtml:16
msgctxt "day"
msgid "Mon"
2023-12-20 12:01:52 +00:00
msgstr "Lun"
2023-12-13 22:55:43 +00:00
#: web/templates/public/campsite/calendar.gohtml:19
#: web/templates/admin/season/calendar.gohtml:17
msgctxt "day"
msgid "Tue"
2023-12-20 12:01:52 +00:00
msgstr "Mar."
2023-12-13 22:55:43 +00:00
#: web/templates/public/campsite/calendar.gohtml:20
#: web/templates/admin/season/calendar.gohtml:18
msgctxt "day"
msgid "Wed"
2023-12-20 12:01:52 +00:00
msgstr "Mer."
2023-12-13 22:55:43 +00:00
#: web/templates/public/campsite/calendar.gohtml:21
#: web/templates/admin/season/calendar.gohtml:19
msgctxt "day"
msgid "Thu"
2023-12-20 12:01:52 +00:00
msgstr "Jeu."
2023-12-13 22:55:43 +00:00
#: web/templates/public/campsite/calendar.gohtml:22
#: web/templates/admin/season/calendar.gohtml:20
msgctxt "day"
msgid "Fri"
2023-12-20 12:01:52 +00:00
msgstr "Ven."
2023-12-13 22:55:43 +00:00
#: web/templates/public/campsite/calendar.gohtml:23
#: web/templates/admin/season/calendar.gohtml:21
msgctxt "day"
msgid "Sat"
2023-12-20 12:01:52 +00:00
msgstr "Sam."
2023-12-13 22:55:43 +00:00
#: web/templates/public/campsite/calendar.gohtml:24
#: web/templates/admin/season/calendar.gohtml:22
msgctxt "day"
msgid "Sun"
2023-12-20 12:01:52 +00:00
msgstr "Dim."
2023-12-13 22:55:43 +00:00
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
#: web/templates/public/campsite/dates.gohtml:4
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:28
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
msgctxt "input"
msgid "Arrival date"
msgstr "Date d’ arrivée"
#: web/templates/public/campsite/dates.gohtml:15
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:39
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
msgctxt "input"
msgid "Departure date"
msgstr "Date de depart"
2024-01-23 13:53:15 +00:00
#: web/templates/public/surroundings.gohtml:30
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "What to Do Outside the Campsite?"
2023-12-20 12:01:52 +00:00
msgstr "Que faire à l’ extérieur du camping ?"
2023-12-13 22:55:43 +00:00
2024-01-23 13:53:15 +00:00
#: web/templates/public/surroundings.gohtml:50
2023-12-13 22:55:43 +00:00
msgctxt "title"
2023-12-18 20:23:03 +00:00
msgid "Once at the Campsite, We Can Inform You about What Activities are Available"
msgstr "Une fois au camping, nous pourrons vous informer sur les activités disponibles"
2023-12-13 22:55:43 +00:00
2024-01-23 13:53:15 +00:00
#: web/templates/public/surroundings.gohtml:53
2023-12-13 22:55:43 +00:00
msgid "Cycle routes"
2023-12-20 12:01:52 +00:00
msgstr "Pistes cyclables"
2023-12-13 22:55:43 +00:00
2024-01-23 13:53:15 +00:00
#: web/templates/public/surroundings.gohtml:54
2023-12-13 22:55:43 +00:00
msgid "There are many bicycle rental companies in Olot."
2023-12-20 12:01:52 +00:00
msgstr "Il existe de nombreuses sociétés de location de vélos à Olot."
2023-12-13 22:55:43 +00:00
2024-01-23 13:53:15 +00:00
#: web/templates/public/surroundings.gohtml:58
2023-12-13 22:55:43 +00:00
msgid "Routes"
2023-12-20 12:01:52 +00:00
msgstr "Itinéraires"
2023-12-13 22:55:43 +00:00
2024-01-23 13:53:15 +00:00
#: web/templates/public/surroundings.gohtml:59
2023-12-13 22:55:43 +00:00
msgid "Routes of all kinds, climbing, mountain passes, for all levels."
2023-12-18 20:23:03 +00:00
msgstr "Itinéraires de toutes sortes, escalade, cols de montagne, pour tous les niveaux."
2023-12-13 22:55:43 +00:00
2024-01-23 13:53:15 +00:00
#: web/templates/public/surroundings.gohtml:63
2023-12-13 22:55:43 +00:00
msgid "Family outing"
2023-12-20 12:01:52 +00:00
msgstr "Sortie en famille"
2023-12-13 22:55:43 +00:00
2024-01-23 13:53:15 +00:00
#: web/templates/public/surroundings.gohtml:64
2023-12-13 22:55:43 +00:00
msgid "Many outing possibilities, for all ages."
2023-12-20 12:01:52 +00:00
msgstr "Nombreuses possibilités de sorties, pour tous les âges."
2023-12-13 22:55:43 +00:00
2024-01-23 13:53:15 +00:00
#: web/templates/public/surroundings.gohtml:68
2023-12-13 22:55:43 +00:00
msgid "Kayak"
2023-12-20 12:01:52 +00:00
msgstr "Kayak"
2023-12-13 22:55:43 +00:00
2024-01-23 13:53:15 +00:00
#: web/templates/public/surroundings.gohtml:69
2023-12-18 20:23:03 +00:00
msgid "There are several points where you can go by kayak, from sections of the Ter river as well as on the coast…."
msgstr "Il y a plusieurs points où vous pouvez aller en kayak, à partir de sections de la rivière Ter ainsi que sur la côte…."
2023-12-13 22:55:43 +00:00
Add home’s cover carousel
This is a separate carousel from the one displayed at the bottom with
location info; it is, i suppose, a carousel for the hero image.
For the database, it works exactly as the home carousel, but on the
front had to use AlpineJS instead of Slick because it needs to show a
text popping up from the bottom when the slide is show, something i do
not know how to do in Slick.
It now makes no sense to have the carousel inside the “nature” section,
because the heading is no longer in there, and moved it out into a new
“hero” div.
Since i now have two carousels in home, i had to add additional
attributes to carousel.AdminHandler to know which URL to point to when
POSTing, PUTting, or redirecting.
2024-01-16 20:05:52 +00:00
#: web/templates/public/campground.gohtml:7
#: web/templates/public/campground.gohtml:16
#: web/templates/public/layout.gohtml:54 web/templates/public/layout.gohtml:94
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Campground"
2023-12-20 12:01:52 +00:00
msgstr "Camping"
2023-12-13 22:55:43 +00:00
2024-01-29 13:37:27 +00:00
#: web/templates/public/campground.gohtml:20
msgctxt "title"
msgid "Legend"
msgstr "Légende"
#: web/templates/public/campground.gohtml:21
msgctxt "title"
msgid "Entrance"
msgstr "Entrée"
#: web/templates/public/campground.gohtml:23
msgctxt "legend"
msgid "Information"
msgstr "Information"
#: web/templates/public/campground.gohtml:24
msgctxt "legend"
msgid "Shop"
msgstr "Boutique"
#: web/templates/public/campground.gohtml:25
msgctxt "legend"
msgid "Restaurant"
msgstr "Restaurant"
#: web/templates/public/campground.gohtml:26
msgctxt "legend"
msgid "Bar"
msgstr "Bar"
#: web/templates/public/campground.gohtml:27
msgctxt "legend"
msgid "TV room"
msgstr "Salle de télévision"
#: web/templates/public/campground.gohtml:28
msgctxt "legend"
msgid "Game room"
msgstr "Salle de jeux"
#: web/templates/public/campground.gohtml:29
msgctxt "legend"
msgid "Recycling"
msgstr "Recyclage"
#: web/templates/public/campground.gohtml:30
msgctxt "legend"
msgid "Waste"
msgstr "Poubelle"
#: web/templates/public/campground.gohtml:31
msgctxt "legend"
msgid "Service station"
msgstr "Station-service"
#: web/templates/public/campground.gohtml:33
msgctxt "title"
msgid "Playtime"
msgstr "Récréation"
#: web/templates/public/campground.gohtml:35
msgctxt "legend"
msgid "Pool"
msgstr "Piscine"
#: web/templates/public/campground.gohtml:36
msgctxt "legend"
msgid "Playground"
msgstr "Cour de récréation"
#: web/templates/public/campground.gohtml:37
msgctxt "legend"
msgid "Sports field"
msgstr "Terrain de sport"
#: web/templates/public/campground.gohtml:39
msgctxt "title"
msgid "Accomodations"
msgstr "Hébergement"
#: web/templates/public/campground.gohtml:41
msgctxt "legend"
msgid "Wooden lodge"
msgstr "Chalet"
#: web/templates/public/campground.gohtml:42
msgctxt "legend"
msgid "Bungalow"
msgstr "Bungalow"
#: web/templates/public/campground.gohtml:43
msgctxt "legend"
msgid "Safari tent"
msgstr "Safari tent"
#: web/templates/public/campground.gohtml:45
msgctxt "title"
msgid "Main Building"
msgstr "Bâtiment principal"
#: web/templates/public/campground.gohtml:47
msgctxt "legend"
msgid "Restroom"
msgstr "Toilettes"
#: web/templates/public/campground.gohtml:48
msgctxt "legend"
msgid "Shower"
msgstr "Douche"
#: web/templates/public/campground.gohtml:49
msgctxt "legend"
msgid "Baby bath"
msgstr "Bain pour bébé"
#: web/templates/public/campground.gohtml:50
msgctxt "legend"
msgid "Washing machine"
msgstr "Machine à laver"
#: web/templates/public/campground.gohtml:51
msgctxt "legend"
msgid "Clothesline"
msgstr "Corde à linge"
#: web/templates/public/campground.gohtml:52
msgctxt "legend"
msgid "Barbecue"
msgstr "Barbecue"
#: web/templates/public/campground.gohtml:53
msgctxt "legend"
msgid "Chemical waste disposal"
msgstr "Élimination des déchets chimiques"
#: web/templates/public/campground.gohtml:55
msgctxt "title"
msgid "Throughout the Campground"
msgstr "Dans tout le camping"
#: web/templates/public/campground.gohtml:57
msgctxt "legend"
msgid "Fire extinguisher"
msgstr "Extincteur d’ incendie"
#: web/templates/public/campground.gohtml:58
msgctxt "legend"
msgid "Faucet"
msgstr "Robinet"
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
#: web/templates/public/layout.gohtml:12 web/templates/public/layout.gohtml:48
msgid "Campsite Montagut"
msgstr "Camping Montagut"
#: web/templates/public/layout.gohtml:24 web/templates/admin/layout.gohtml:21
msgid "Skip to main content"
msgstr "Passer au contenu principal"
#: web/templates/public/layout.gohtml:50
msgid "Menu"
msgstr "Menu"
#: web/templates/public/layout.gohtml:58 web/templates/public/layout.gohtml:104
#: web/templates/admin/campsite/feature/form.gohtml:16
#: web/templates/admin/campsite/feature/index.gohtml:10
#: web/templates/admin/campsite/carousel/form.gohtml:16
#: web/templates/admin/campsite/carousel/index.gohtml:10
#: web/templates/admin/campsite/form.gohtml:15
#: web/templates/admin/campsite/index.gohtml:6
#: web/templates/admin/campsite/index.gohtml:15
#: web/templates/admin/campsite/type/feature/form.gohtml:16
#: web/templates/admin/campsite/type/feature/index.gohtml:10
#: web/templates/admin/campsite/type/carousel/form.gohtml:16
#: web/templates/admin/campsite/type/carousel/index.gohtml:10
#: web/templates/admin/campsite/type/form.gohtml:15
#: web/templates/admin/campsite/type/option/form.gohtml:16
#: web/templates/admin/campsite/type/option/index.gohtml:10
#: web/templates/admin/campsite/type/index.gohtml:10
#: web/templates/admin/layout.gohtml:46 web/templates/admin/layout.gohtml:95
msgctxt "title"
msgid "Campsites"
msgstr "Locatifs"
Add home’s cover carousel
This is a separate carousel from the one displayed at the bottom with
location info; it is, i suppose, a carousel for the hero image.
For the database, it works exactly as the home carousel, but on the
front had to use AlpineJS instead of Slick because it needs to show a
text popping up from the bottom when the slide is show, something i do
not know how to do in Slick.
It now makes no sense to have the carousel inside the “nature” section,
because the heading is no longer in there, and moved it out into a new
“hero” div.
Since i now have two carousels in home, i had to add additional
attributes to carousel.AdminHandler to know which URL to point to when
POSTing, PUTting, or redirecting.
2024-01-16 20:05:52 +00:00
#: web/templates/public/layout.gohtml:70
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
#: web/templates/public/booking/page.gohtml:7
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Booking"
2024-01-18 20:05:30 +00:00
msgstr "Réservation"
2023-12-13 22:55:43 +00:00
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
#: web/templates/public/layout.gohtml:91
msgctxt "title"
msgid "Sections"
msgstr "Sections"
#: web/templates/public/layout.gohtml:115
msgctxt "title"
msgid "Opening"
msgstr "Ouverture"
#: web/templates/public/layout.gohtml:122
msgid "<abbr title=\"Catalonia Tourism Registry\">RTC</abbr> <abbr title=\"Number\">#</abbr>%s"
msgstr "<abbr title=\"Registre du tourisme de Catalogne\"># RTC</abbr> %s"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:15
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "title"
msgid "Accommodation"
msgstr "Hébergement"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:25
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "title"
msgid "Booking Period"
msgstr "Période de réservation"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:52
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "title"
msgid "Guests"
msgstr "Personnes logeant"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:56
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "input"
msgid "Adults aged 17 or older"
msgstr "Adultes âgés 17 ans ou plus"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:67
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "input"
msgid "Teenagers from 11 to 16 years old"
msgstr "Adolescents de 11 à 16 ans"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:78
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "input"
msgid "Children from 2 to 10 years old"
msgstr "Enfants de 2 à 10 ans"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:88
2024-02-11 21:06:00 +00:00
msgid "Note: Due to guest capacity, we have added more accomodations to the booking, but we <strong>cannot</strong> guarantee that they will be next to each other."
msgstr "Remarque : En raison de la capacité d’ accueils, nous avons ajouté d’ autres hébergements à la réservation, mais nous <strong>ne pouvons</strong> garantir qu’ ils seront côte à côte."
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:96
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "input"
msgid "Dogs"
msgstr "Chiens"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:105
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
msgid "Note: This accommodation does <strong>not</strong> allow dogs."
2024-02-11 21:06:00 +00:00
msgstr "Remarque : Dans cet hébergement les chiens <strong>ne</strong> sont pas acceptés."
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:115
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "input"
msgid "Area preferences (optional)"
msgstr "Préférences de zone (facultatif)"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:117
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Campground map"
msgstr "Plan du camping"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:140
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Customer Details"
msgstr "Détails du client"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:143
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Full name"
msgstr "Nom et prénom"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:152
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Address (optional)"
2023-12-20 16:51:01 +00:00
msgstr "Adresse (Facultatif)"
2023-12-13 22:55:43 +00:00
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:161
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Postcode (optional)"
2023-12-20 16:51:01 +00:00
msgstr "Code postal (Facultatif)"
2023-12-13 22:55:43 +00:00
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:170
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Town or village (optional)"
2023-12-20 16:51:01 +00:00
msgstr "Ville (Facultatif)"
2023-12-13 22:55:43 +00:00
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:179
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:101
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Country"
msgstr "Pays"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:182
2023-12-13 22:55:43 +00:00
msgid "Choose a country"
msgstr "Choisissez un pays"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:190
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
#: web/templates/admin/login.gohtml:27 web/templates/admin/profile.gohtml:38
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:53
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Email"
msgstr "E-mail"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:199
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:45
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Phone"
msgstr "Téléphone"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:210
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "ACSI card? (optional)"
2023-12-20 12:01:52 +00:00
msgstr "Carte ACSI ? (Facultatif)"
2023-12-13 22:55:43 +00:00
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:217
2023-12-13 22:55:43 +00:00
msgctxt "input"
2024-01-22 02:41:54 +00:00
msgid "I have read and I accept %[1]sthe reservation conditions%[2]s"
msgstr "J’ ai lu et j’ accepte %[1]sles conditions de réservation%[2]s"
2023-12-13 22:55:43 +00:00
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: web/templates/public/booking/fields.gohtml:234
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "cart"
msgid "Total"
msgstr "Totale"
2023-12-13 22:55:43 +00:00
2023-12-22 01:23:18 +00:00
#: web/templates/admin/legal/form.gohtml:8
2024-01-21 21:44:04 +00:00
#: web/templates/admin/legal/form.gohtml:29
2023-12-13 22:55:43 +00:00
msgctxt "title"
2023-12-22 01:23:18 +00:00
msgid "Edit Legal Text"
2024-01-10 18:41:57 +00:00
msgstr "Modifier le texte juridique"
2023-12-13 22:55:43 +00:00
2023-12-22 01:23:18 +00:00
#: web/templates/admin/legal/form.gohtml:10
2024-01-21 21:44:04 +00:00
#: web/templates/admin/legal/form.gohtml:31
2023-12-13 22:55:43 +00:00
msgctxt "title"
2023-12-22 01:23:18 +00:00
msgid "New Legal Text"
2024-01-10 18:41:57 +00:00
msgstr "Nouveau texte juridique"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/legal/form.gohtml:15
#: web/templates/admin/legal/index.gohtml:6
#: web/templates/admin/legal/index.gohtml:15
2024-01-27 21:51:41 +00:00
#: web/templates/admin/layout.gohtml:70
2024-01-21 21:44:04 +00:00
msgctxt "title"
msgid "Legal Texts"
msgstr "Textes juridiques"
#: web/templates/admin/legal/form.gohtml:41
2023-12-13 22:55:43 +00:00
msgctxt "input"
2023-12-22 01:23:18 +00:00
msgid "Slug"
2024-01-10 18:41:57 +00:00
msgstr "Slug"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/legal/form.gohtml:50
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/feature/form.gohtml:50
#: web/templates/admin/campsite/type/feature/form.gohtml:59
2024-01-21 21:44:04 +00:00
#: web/templates/admin/campsite/type/form.gohtml:51
2024-02-11 21:06:00 +00:00
#: web/templates/admin/campsite/type/option/form.gohtml:41
2024-01-21 21:44:04 +00:00
#: web/templates/admin/season/form.gohtml:50
2024-01-24 10:13:39 +00:00
#: web/templates/admin/services/form.gohtml:53
2024-01-21 21:44:04 +00:00
#: web/templates/admin/profile.gohtml:29
#: web/templates/admin/surroundings/form.gohtml:41
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/feature/form.gohtml:50
#: web/templates/admin/amenity/form.gohtml:50
2023-12-22 01:23:18 +00:00
msgctxt "input"
msgid "Name"
msgstr "Nom"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/legal/form.gohtml:68
2023-12-22 01:23:18 +00:00
msgctxt "input"
msgid "Content"
2024-01-10 18:41:57 +00:00
msgstr "Contenu"
2023-12-22 01:23:18 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/legal/form.gohtml:88
#: web/templates/admin/carousel/form.gohtml:55
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/feature/form.gohtml:65
#: web/templates/admin/campsite/carousel/form.gohtml:50
#: web/templates/admin/campsite/form.gohtml:92
#: web/templates/admin/campsite/type/feature/form.gohtml:74
#: web/templates/admin/campsite/type/carousel/form.gohtml:59
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:287
2024-02-11 21:06:00 +00:00
#: web/templates/admin/campsite/type/option/form.gohtml:98
2024-01-21 21:44:04 +00:00
#: web/templates/admin/season/form.gohtml:73
2024-01-24 10:13:39 +00:00
#: web/templates/admin/services/form.gohtml:81
2024-01-21 21:44:04 +00:00
#: web/templates/admin/surroundings/form.gohtml:69
2024-01-23 13:53:15 +00:00
#: web/templates/admin/surroundings/index.gohtml:58
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/feature/form.gohtml:65
#: web/templates/admin/amenity/carousel/form.gohtml:50
#: web/templates/admin/amenity/form.gohtml:91
2024-01-23 10:52:39 +00:00
#: web/templates/admin/home/index.gohtml:34
2024-01-21 21:44:04 +00:00
#: web/templates/admin/media/form.gohtml:39
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Update"
2023-12-20 12:01:52 +00:00
msgstr "Mettre à jour"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/legal/form.gohtml:90
#: web/templates/admin/carousel/form.gohtml:57
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/feature/form.gohtml:67
#: web/templates/admin/campsite/carousel/form.gohtml:52
#: web/templates/admin/campsite/form.gohtml:94
#: web/templates/admin/campsite/type/feature/form.gohtml:76
#: web/templates/admin/campsite/type/carousel/form.gohtml:61
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:289
2024-02-11 21:06:00 +00:00
#: web/templates/admin/campsite/type/option/form.gohtml:100
2024-01-21 21:44:04 +00:00
#: web/templates/admin/season/form.gohtml:75
2024-01-24 10:13:39 +00:00
#: web/templates/admin/services/form.gohtml:83
2024-01-21 21:44:04 +00:00
#: web/templates/admin/surroundings/form.gohtml:71
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/feature/form.gohtml:67
#: web/templates/admin/amenity/carousel/form.gohtml:52
#: web/templates/admin/amenity/form.gohtml:93
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Add"
2023-12-20 12:01:52 +00:00
msgstr "Ajouter"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/legal/index.gohtml:14
2023-12-22 01:23:18 +00:00
msgctxt "action"
msgid "Add Legal Text"
2024-01-10 18:41:57 +00:00
msgstr "Ajouter un texte juridique"
2023-12-22 01:23:18 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/legal/index.gohtml:20
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/feature/index.gohtml:30
#: web/templates/admin/campsite/type/feature/index.gohtml:31
#: web/templates/admin/campsite/type/option/index.gohtml:30
2024-01-21 21:44:04 +00:00
#: web/templates/admin/campsite/type/index.gohtml:29
#: web/templates/admin/season/index.gohtml:29
#: web/templates/admin/user/index.gohtml:20
2024-01-23 13:53:15 +00:00
#: web/templates/admin/surroundings/index.gohtml:83
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/feature/index.gohtml:30
#: web/templates/admin/amenity/index.gohtml:21
2023-12-22 01:23:18 +00:00
msgctxt "header"
msgid "Name"
msgstr "Nom"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/legal/index.gohtml:32
2023-12-22 01:23:18 +00:00
msgid "No legal texts added yet."
2024-01-10 18:41:57 +00:00
msgstr "Aucune texte juridique n’ a encore été ajoutée."
2023-12-22 01:23:18 +00:00
#: web/templates/admin/carousel/form.gohtml:8
2024-01-21 21:44:04 +00:00
#: web/templates/admin/carousel/form.gohtml:28
2023-12-22 01:23:18 +00:00
msgctxt "title"
msgid "Edit Carousel Slide"
msgstr "Modifier la diapositive du carrousel"
#: web/templates/admin/carousel/form.gohtml:10
2024-01-21 21:44:04 +00:00
#: web/templates/admin/carousel/form.gohtml:30
2023-12-22 01:23:18 +00:00
msgctxt "title"
msgid "New Carousel Slide"
2024-01-27 21:51:41 +00:00
msgstr "Nouveau diapositive carrousel"
2023-12-22 01:23:18 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/carousel/form.gohtml:40
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/carousel/form.gohtml:35
#: web/templates/admin/campsite/type/carousel/form.gohtml:44
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/carousel/form.gohtml:35
2023-12-22 01:23:18 +00:00
msgctxt "input"
msgid "Caption"
msgstr "Légende"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/location.gohtml:6 web/templates/admin/location.gohtml:15
2023-12-21 20:17:04 +00:00
msgctxt "title"
msgid "Location Settings"
msgstr "Paramètres de comment nous rejoindre"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/location.gohtml:20
2023-12-21 20:17:04 +00:00
msgctxt "input"
msgid "Directions"
msgstr "Directions"
2024-01-24 10:13:39 +00:00
#: web/templates/admin/location.gohtml:33
2023-12-21 20:17:04 +00:00
msgctxt "input"
msgid "Opening Dates"
msgstr "Dates d’ ouverture"
2024-01-24 10:13:39 +00:00
#: web/templates/admin/location.gohtml:46
2023-12-21 20:17:04 +00:00
msgctxt "input"
msgid "Map Embed"
msgstr "Carte intégrée"
2024-01-24 10:13:39 +00:00
#: web/templates/admin/location.gohtml:53 web/templates/admin/profile.gohtml:78
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:170
#: web/templates/admin/booking/payment.gohtml:65
2023-12-21 20:17:04 +00:00
msgctxt "action"
msgid "Save changes"
msgstr "Enregistrer les changements"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/campsite/feature/form.gohtml:8
msgctxt "title"
2024-01-26 21:27:54 +00:00
msgid "Edit Campsite Feature"
msgstr "Modifier l’ entité de camping"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/campsite/feature/form.gohtml:10
msgctxt "title"
2024-01-26 21:27:54 +00:00
msgid "New Campsite Feature"
2024-01-26 21:54:19 +00:00
msgstr "Nouvelle caractéristique de camping"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/campsite/feature/form.gohtml:17
2023-12-13 22:55:43 +00:00
#: web/templates/admin/campsite/feature/index.gohtml:6
msgctxt "title"
2024-01-26 21:27:54 +00:00
msgid "Campsite Features"
msgstr "Caractéristiques de camping"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/feature/form.gohtml:32
#: web/templates/admin/campsite/type/feature/form.gohtml:41
2024-01-24 10:13:39 +00:00
#: web/templates/admin/services/form.gohtml:35
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/feature/form.gohtml:32
2024-01-21 21:44:04 +00:00
msgctxt "input"
msgid "Icon"
msgstr "Icône"
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/feature/index.gohtml:15
#: web/templates/admin/campsite/type/feature/index.gohtml:16
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/feature/index.gohtml:15
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Add Feature"
2024-01-26 21:54:19 +00:00
msgstr "Ajouter une caractéristique"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/feature/index.gohtml:31
#: web/templates/admin/campsite/carousel/index.gohtml:31
2024-01-26 21:54:19 +00:00
#: web/templates/admin/campsite/type/feature/index.gohtml:32
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/type/carousel/index.gohtml:32
#: web/templates/admin/campsite/type/option/index.gohtml:31
#: web/templates/admin/services/index.gohtml:30
#: web/templates/admin/services/index.gohtml:75
#: web/templates/admin/user/index.gohtml:23
#: web/templates/admin/surroundings/index.gohtml:84
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/feature/index.gohtml:31
#: web/templates/admin/amenity/carousel/index.gohtml:31
2024-01-29 02:38:11 +00:00
#: web/templates/admin/amenity/index.gohtml:25
2024-01-26 21:27:54 +00:00
#: web/templates/admin/home/index.gohtml:54
#: web/templates/admin/home/index.gohtml:99
msgctxt "header"
msgid "Actions"
msgstr "Actions"
#: web/templates/admin/campsite/feature/index.gohtml:35
2024-01-26 21:54:19 +00:00
#: web/templates/admin/campsite/type/feature/index.gohtml:36
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/feature/index.gohtml:35
2024-01-26 21:54:19 +00:00
msgid "Are you sure you wish to delete this feature?"
msgstr "Êtes-vous sûr de vouloir supprimer cette caractéristique ?"
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/feature/index.gohtml:47
#: web/templates/admin/campsite/carousel/index.gohtml:49
2024-01-26 21:54:19 +00:00
#: web/templates/admin/campsite/type/feature/index.gohtml:48
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/type/carousel/index.gohtml:50
#: web/templates/admin/campsite/type/option/index.gohtml:47
#: web/templates/admin/services/index.gohtml:47
#: web/templates/admin/services/index.gohtml:91
#: web/templates/admin/user/index.gohtml:37
#: web/templates/admin/surroundings/index.gohtml:63
#: web/templates/admin/surroundings/index.gohtml:101
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/feature/index.gohtml:47
#: web/templates/admin/amenity/carousel/index.gohtml:49
2024-01-29 02:38:11 +00:00
#: web/templates/admin/amenity/index.gohtml:45
2024-01-26 21:27:54 +00:00
#: web/templates/admin/home/index.gohtml:71
#: web/templates/admin/home/index.gohtml:116
msgctxt "action"
msgid "Delete"
msgstr "Supprimer"
#: web/templates/admin/campsite/feature/index.gohtml:56
msgid "No campsite features added yet."
2024-01-26 21:54:19 +00:00
msgstr "Aucune caractéristique de camping n’ a encore été ajoutée."
2023-12-13 22:55:43 +00:00
#: web/templates/admin/campsite/carousel/form.gohtml:8
msgctxt "title"
2024-01-26 21:27:54 +00:00
msgid "Edit Campsite Carousel Slide"
msgstr "Modifier la diapositive du carrousel de camping"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/campsite/carousel/form.gohtml:10
msgctxt "title"
2024-01-26 21:27:54 +00:00
msgid "New Campsite Carousel Slide"
2024-01-27 21:51:41 +00:00
msgstr "Nouveau diapositive de carrousel de camping"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/carousel/form.gohtml:17
2023-12-13 22:55:43 +00:00
#: web/templates/admin/campsite/carousel/index.gohtml:6
msgctxt "title"
2024-01-26 21:27:54 +00:00
msgid "Campsite Carousel"
msgstr "Camping Carrousel"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/carousel/index.gohtml:16
#: web/templates/admin/campsite/type/carousel/index.gohtml:17
2024-01-21 21:44:04 +00:00
#: web/templates/admin/services/index.gohtml:15
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/carousel/index.gohtml:16
2024-01-23 10:52:39 +00:00
#: web/templates/admin/home/index.gohtml:84
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Add slide"
2023-12-20 12:01:52 +00:00
msgstr "Ajouter la diapositive"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/carousel/index.gohtml:29
#: web/templates/admin/campsite/type/carousel/index.gohtml:30
2024-01-21 21:44:04 +00:00
#: web/templates/admin/services/index.gohtml:28
2024-01-23 13:53:15 +00:00
#: web/templates/admin/surroundings/index.gohtml:82
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/carousel/index.gohtml:29
2024-01-23 10:52:39 +00:00
#: web/templates/admin/home/index.gohtml:52
#: web/templates/admin/home/index.gohtml:97
2023-12-13 22:55:43 +00:00
msgctxt "header"
msgid "Image"
2023-12-20 12:01:52 +00:00
msgstr "Image"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/carousel/index.gohtml:30
#: web/templates/admin/campsite/type/carousel/index.gohtml:31
2024-01-21 21:44:04 +00:00
#: web/templates/admin/services/index.gohtml:29
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/carousel/index.gohtml:30
2024-01-23 10:52:39 +00:00
#: web/templates/admin/home/index.gohtml:53
#: web/templates/admin/home/index.gohtml:98
2023-12-13 22:55:43 +00:00
msgctxt "header"
msgid "Caption"
2023-12-20 12:01:52 +00:00
msgstr "Légende"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/carousel/index.gohtml:35
#: web/templates/admin/campsite/type/carousel/index.gohtml:36
2024-01-21 21:44:04 +00:00
#: web/templates/admin/services/index.gohtml:34
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/carousel/index.gohtml:35
2024-01-23 10:52:39 +00:00
#: web/templates/admin/home/index.gohtml:103
2023-12-13 22:55:43 +00:00
msgid "Are you sure you wish to delete this slide?"
2023-12-20 12:01:52 +00:00
msgstr "Êtes-vous sûr de vouloir supprimer cette diapositive ?"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/carousel/index.gohtml:58
#: web/templates/admin/campsite/type/carousel/index.gohtml:59
2024-01-21 21:44:04 +00:00
#: web/templates/admin/services/index.gohtml:56
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/carousel/index.gohtml:58
2024-01-23 10:52:39 +00:00
#: web/templates/admin/home/index.gohtml:125
2023-12-13 22:55:43 +00:00
msgid "No slides added yet."
2023-12-20 12:01:52 +00:00
msgstr "Aucune diapositive n’ a encore été ajoutée."
2023-12-13 22:55:43 +00:00
#: web/templates/admin/campsite/form.gohtml:8
msgctxt "title"
msgid "Edit Campsite"
2023-12-20 12:01:52 +00:00
msgstr "Modifier le camping"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/campsite/form.gohtml:10
msgctxt "title"
msgid "New Campsite"
2023-12-20 12:01:52 +00:00
msgstr "Nouveau camping"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/form.gohtml:33
#: web/templates/admin/campsite/index.gohtml:27
2023-12-13 22:55:43 +00:00
msgctxt "campsite"
msgid "Active"
2023-12-20 12:01:52 +00:00
msgstr "Actif"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/form.gohtml:42
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Campsite Type"
2023-12-20 12:01:52 +00:00
msgstr "Type d’ emplacement de camping"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/form.gohtml:47
2023-12-13 22:55:43 +00:00
msgid "Select campsite type"
2023-12-20 12:01:52 +00:00
msgstr "Sélectionnez le type d’ emplacement"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/form.gohtml:56
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/form.gohtml:42
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Label"
2023-12-20 12:01:52 +00:00
msgstr "Label"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/form.gohtml:64
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/form.gohtml:63
2023-12-13 22:55:43 +00:00
msgctxt "input"
2024-01-26 21:27:54 +00:00
msgid "Info (First Column)"
msgstr "Info (première colonne)"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/form.gohtml:77
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/form.gohtml:76
2023-12-13 22:55:43 +00:00
msgctxt "input"
2024-01-26 21:27:54 +00:00
msgid "Info (Second Column)"
msgstr "Info (deuxième colonne)"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/campsite/index.gohtml:14
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Add Campsite"
2023-12-20 12:01:52 +00:00
msgstr "Ajouter un camping"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/index.gohtml:23
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/index.gohtml:20
2023-12-13 22:55:43 +00:00
msgctxt "header"
msgid "Label"
2023-12-20 12:01:52 +00:00
msgstr "Label"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/index.gohtml:24
2023-12-13 22:55:43 +00:00
msgctxt "header"
msgid "Type"
2023-12-20 12:01:52 +00:00
msgstr "Type"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/index.gohtml:25
#: web/templates/admin/campsite/type/index.gohtml:30
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/index.gohtml:22
2024-01-26 21:27:54 +00:00
msgctxt "header"
msgid "Features"
msgstr "Caractéristiques"
#: web/templates/admin/campsite/index.gohtml:26
#: web/templates/admin/campsite/type/index.gohtml:32
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/index.gohtml:23
2024-01-26 21:27:54 +00:00
msgctxt "header"
msgid "Carousel"
msgstr "Carrousel"
#: web/templates/admin/campsite/index.gohtml:36
#: web/templates/admin/campsite/type/index.gohtml:45
2024-01-29 02:38:11 +00:00
#: web/templates/admin/amenity/index.gohtml:35
2024-01-26 21:27:54 +00:00
msgctxt "action"
msgid "Edit Features"
2024-01-26 21:54:19 +00:00
msgstr "Edit caractéristiques"
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/index.gohtml:39
#: web/templates/admin/campsite/type/index.gohtml:51
2024-01-29 02:38:11 +00:00
#: web/templates/admin/amenity/index.gohtml:38
2024-01-26 21:27:54 +00:00
msgctxt "action"
msgid "Edit Carousel"
msgstr "Modifier le carrousel"
#: web/templates/admin/campsite/index.gohtml:41
2024-01-21 21:44:04 +00:00
#: web/templates/admin/campsite/type/index.gohtml:53
#: web/templates/admin/season/index.gohtml:44
#: web/templates/admin/user/login-attempts.gohtml:31
2024-01-29 02:38:11 +00:00
#: web/templates/admin/amenity/index.gohtml:40
2023-12-13 22:55:43 +00:00
msgid "Yes"
2023-12-20 12:01:52 +00:00
msgstr "Oui"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/index.gohtml:41
2024-01-21 21:44:04 +00:00
#: web/templates/admin/campsite/type/index.gohtml:53
#: web/templates/admin/season/index.gohtml:44
#: web/templates/admin/user/login-attempts.gohtml:31
2024-01-29 02:38:11 +00:00
#: web/templates/admin/amenity/index.gohtml:40
2023-12-13 22:55:43 +00:00
msgid "No"
2023-12-20 12:01:52 +00:00
msgstr "Non"
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/index.gohtml:47
2023-12-13 22:55:43 +00:00
msgid "No campsites added yet."
2023-12-20 12:01:52 +00:00
msgstr "Aucun camping n’ a encore été ajouté."
2023-12-13 22:55:43 +00:00
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/type/feature/form.gohtml:8
#: web/templates/admin/campsite/type/feature/form.gohtml:32
msgctxt "title"
msgid "Edit Campsite Type Feature"
2024-01-26 21:54:19 +00:00
msgstr "Modifier la caractéristique de type de camping"
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/type/feature/form.gohtml:10
#: web/templates/admin/campsite/type/feature/form.gohtml:34
msgctxt "title"
msgid "New Campsite Type Feature"
2024-01-26 21:54:19 +00:00
msgstr "Nouvelle caractéristique de type de camping"
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/type/feature/form.gohtml:17
#: web/templates/admin/campsite/type/feature/index.gohtml:11
#: web/templates/admin/campsite/type/carousel/form.gohtml:17
#: web/templates/admin/campsite/type/carousel/index.gohtml:11
#: web/templates/admin/campsite/type/form.gohtml:16
#: web/templates/admin/campsite/type/option/form.gohtml:17
#: web/templates/admin/campsite/type/option/index.gohtml:11
#: web/templates/admin/campsite/type/index.gohtml:6
#: web/templates/admin/campsite/type/index.gohtml:16
#: web/templates/admin/layout.gohtml:43
msgctxt "title"
msgid "Campsite Types"
msgstr "Types d’ emplacements de camping"
#: web/templates/admin/campsite/type/feature/form.gohtml:18
#: web/templates/admin/campsite/type/feature/index.gohtml:6
#: web/templates/admin/campsite/type/feature/index.gohtml:17
msgctxt "title"
msgid "Campsite Type Features"
msgstr "Caractéristiques du type d’ emplacement de camping"
2024-01-26 21:54:19 +00:00
#: web/templates/admin/campsite/type/feature/index.gohtml:57
2024-01-26 21:27:54 +00:00
msgid "No campsite type features added yet."
2024-01-26 21:54:19 +00:00
msgstr "Aucune caractéristique de type camping n’ a encore été ajoutée."
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/type/carousel/form.gohtml:8
#: web/templates/admin/campsite/type/carousel/form.gohtml:32
msgctxt "title"
msgid "Edit Campsite Type Carousel Slide"
msgstr "Modifier la diapositive du carrousel de type camping"
#: web/templates/admin/campsite/type/carousel/form.gohtml:10
#: web/templates/admin/campsite/type/carousel/form.gohtml:34
msgctxt "title"
msgid "New Campsite Type Carousel Slide"
2024-01-27 21:51:41 +00:00
msgstr "Nouveau diapositive de carrousel de type camping"
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/type/carousel/form.gohtml:18
#: web/templates/admin/campsite/type/carousel/index.gohtml:6
#: web/templates/admin/campsite/type/carousel/index.gohtml:16
msgctxt "title"
msgid "Campsite Type Carousel"
msgstr "Type de camping Carrousel"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/campsite/type/form.gohtml:8
2024-01-21 21:44:04 +00:00
#: web/templates/admin/campsite/type/form.gohtml:30
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Edit Campsite Type"
2023-12-20 12:01:52 +00:00
msgstr "Modifier le type d’ emplacement"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/campsite/type/form.gohtml:10
2024-01-21 21:44:04 +00:00
#: web/templates/admin/campsite/type/form.gohtml:32
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "New Campsite Type"
2023-12-20 12:01:52 +00:00
msgstr "Nouveau type d’ emplacement de camping"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/campsite/type/form.gohtml:42
#: web/templates/admin/campsite/type/index.gohtml:33
2023-12-13 22:55:43 +00:00
msgctxt "campsite type"
msgid "Active"
2023-12-20 12:01:52 +00:00
msgstr "Actif"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/campsite/type/form.gohtml:67
2023-12-13 22:55:43 +00:00
msgctxt "input"
2024-01-22 19:19:19 +00:00
msgid "Check-in"
msgstr "Arrivée"
#: web/templates/admin/campsite/type/form.gohtml:80
msgctxt "input"
msgid "Check-out"
msgstr "Départ"
2024-01-31 22:06:45 +00:00
#: web/templates/admin/campsite/type/form.gohtml:93
msgctxt "input"
msgid "Minimum number of nights"
msgstr "Nombre minimum de nuits"
#: web/templates/admin/campsite/type/form.gohtml:101
msgctxt "input"
msgid "Maximum number of nights"
msgstr "Nombre maximale de nuits"
#: web/templates/admin/campsite/type/form.gohtml:110
2024-01-22 19:19:19 +00:00
msgctxt "input"
2023-12-13 22:55:43 +00:00
msgid "Maximum number of campers"
2024-01-29 02:38:11 +00:00
msgstr "Nombre maximum de personnes"
2023-12-13 22:55:43 +00:00
2024-01-31 22:06:45 +00:00
#: web/templates/admin/campsite/type/form.gohtml:120
2024-01-29 02:38:11 +00:00
msgctxt "input"
msgid "Allow overflowing guests to neighbouring campsites"
msgstr "Autoriser la réservation d’ un hébergement voisin si le nombre maximum de personnes est dépassé"
2024-01-31 22:06:45 +00:00
#: web/templates/admin/campsite/type/form.gohtml:129
2024-01-29 02:38:11 +00:00
msgctxt "input"
msgid "Ask for zone preferences when booking"
msgstr "Demandez la préférence de zone lors de la réservation"
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:139
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Dogs allowed"
2023-12-20 12:01:52 +00:00
msgstr "Chiens acceptés"
2023-12-13 22:55:43 +00:00
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:144
msgctxt "input"
msgid "Dogs price"
msgstr "Prix des chiens"
#: web/templates/admin/campsite/type/form.gohtml:157
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "header"
msgid "Season"
msgstr "Saison"
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:158
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "header"
msgid "Price per night"
msgstr "Prix par nuit"
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:159
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "header"
msgid "Price per adult (> 16)"
msgstr "Prix per adulte (> 16)"
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:160
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "header"
msgid "Price per teenager (11– 16)"
msgstr "Prix per adolescent (11– 16)"
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:161
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "header"
msgid "Price per child (2– 10)"
msgstr "Prix per enfant (2– 10)"
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:171
2024-01-26 21:27:54 +00:00
msgctxt "input"
msgid "Price per night"
msgstr "Prix par nuit"
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:182
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "input"
msgid "Price per adult (> 16)"
msgstr "Prix per adulte (> 16)"
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:193
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "input"
msgid "Price per teenager (11– 16)"
msgstr "Prix per adolescent (11– 16)"
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:204
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "input"
msgid "Price per child (2– 10)"
msgstr "Prix per enfant (2– 10)"
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:220
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Spiel"
2023-12-20 12:01:52 +00:00
msgstr "Boniment"
2023-12-13 22:55:43 +00:00
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:233
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Info"
2023-12-20 12:01:52 +00:00
msgstr "Info"
2023-12-13 22:55:43 +00:00
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:246
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Facilities"
2023-12-20 12:01:52 +00:00
msgstr "Installations"
2023-12-13 22:55:43 +00:00
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:259
2024-01-24 10:13:39 +00:00
#: web/templates/admin/services/form.gohtml:66
2024-01-21 21:44:04 +00:00
#: web/templates/admin/surroundings/form.gohtml:54
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Description"
2023-12-20 12:01:52 +00:00
msgstr "Description"
2023-12-13 22:55:43 +00:00
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: web/templates/admin/campsite/type/form.gohtml:272
2024-01-14 23:28:34 +00:00
msgctxt "input"
msgid "Additional Information"
msgstr "Informations Complémentaires"
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/type/option/form.gohtml:8
2024-02-11 21:06:00 +00:00
#: web/templates/admin/campsite/type/option/form.gohtml:32
2024-01-26 21:27:54 +00:00
msgctxt "title"
msgid "Edit Campsite Type Option"
msgstr "Modifier l’ option Type d’ emplacement de camping"
#: web/templates/admin/campsite/type/option/form.gohtml:10
2024-02-11 21:06:00 +00:00
#: web/templates/admin/campsite/type/option/form.gohtml:34
2024-01-26 21:27:54 +00:00
msgctxt "title"
msgid "New Campsite Type Option"
msgstr "Nouvelle option de type d’ emplacement de camping"
#: web/templates/admin/campsite/type/option/form.gohtml:18
#: web/templates/admin/campsite/type/option/index.gohtml:6
#: web/templates/admin/campsite/type/option/index.gohtml:17
msgctxt "title"
msgid "Campsite Type Options"
msgstr "Options de type d’ emplacement de camping"
2024-02-11 21:06:00 +00:00
#: web/templates/admin/campsite/type/option/form.gohtml:54
2024-01-26 21:27:54 +00:00
msgctxt "input"
msgid "Minimum"
msgstr "Minimum"
2024-02-11 21:06:00 +00:00
#: web/templates/admin/campsite/type/option/form.gohtml:62
2024-01-26 21:27:54 +00:00
msgctxt "input"
msgid "Maximum"
msgstr "Maximum"
2024-02-11 21:06:00 +00:00
#: web/templates/admin/campsite/type/option/form.gohtml:75
2024-02-11 20:45:00 +00:00
msgctxt "campsite type"
msgid "Per night"
msgstr "Par nuit"
2024-02-11 21:06:00 +00:00
#: web/templates/admin/campsite/type/option/form.gohtml:84
2024-02-11 20:45:00 +00:00
msgctxt "input"
msgid "Price"
msgstr "Prix"
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/type/option/index.gohtml:16
msgctxt "action"
msgid "Add Option"
msgstr "Ajouter une option"
2024-01-26 21:54:19 +00:00
#: web/templates/admin/campsite/type/option/index.gohtml:35
msgid "Are you sure you wish to delete this option?"
msgstr "Êtes-vous sûr de vouloir supprimer cette option ?"
2024-01-26 21:27:54 +00:00
#: web/templates/admin/campsite/type/option/index.gohtml:56
msgid "No campsite type options added yet."
msgstr "Aucune option de type de camping n’ a encore été ajoutée."
2024-01-21 21:44:04 +00:00
#: web/templates/admin/campsite/type/index.gohtml:15
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Add Type"
2023-12-20 12:01:52 +00:00
msgstr "Ajouter un type"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/campsite/type/index.gohtml:31
2023-12-13 22:55:43 +00:00
msgctxt "header"
msgid "Options"
2023-12-20 12:01:52 +00:00
msgstr "Options"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/campsite/type/index.gohtml:48
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Edit Options"
2023-12-20 12:01:52 +00:00
msgstr "Modifier les options"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/campsite/type/index.gohtml:60
2023-12-13 22:55:43 +00:00
msgid "No campsite types added yet."
2023-12-20 12:01:52 +00:00
msgstr "Aucun type d’ emplacement n’ a encore été ajouté."
2023-12-13 22:55:43 +00:00
#: web/templates/admin/season/form.gohtml:8
2024-01-21 21:44:04 +00:00
#: web/templates/admin/season/form.gohtml:29
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Edit Season"
2023-12-20 12:01:52 +00:00
msgstr "Éditer la saison"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/season/form.gohtml:10
2024-01-21 21:44:04 +00:00
#: web/templates/admin/season/form.gohtml:31
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "New Season"
2023-12-20 12:01:52 +00:00
msgstr "Nouvelle saison"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/season/form.gohtml:15
2024-01-22 02:41:54 +00:00
#: web/templates/admin/season/index.gohtml:6
#: web/templates/admin/season/index.gohtml:15
2024-01-27 21:51:41 +00:00
#: web/templates/admin/layout.gohtml:52
2024-01-21 21:44:04 +00:00
msgctxt "title"
2024-01-22 02:41:54 +00:00
msgid "Seasons"
2024-01-21 21:44:04 +00:00
msgstr "Saisons"
#: web/templates/admin/season/form.gohtml:41
#: web/templates/admin/season/index.gohtml:30
2023-12-13 22:55:43 +00:00
msgctxt "season"
msgid "Active"
2023-12-20 12:01:52 +00:00
msgstr "Actif"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/season/form.gohtml:63
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Color"
2023-12-20 12:01:52 +00:00
msgstr "Couleur"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/season/index.gohtml:14
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Add Season"
2023-12-20 12:01:52 +00:00
msgstr "Ajouter une saison"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/season/index.gohtml:28
2023-12-13 22:55:43 +00:00
msgctxt "header"
msgid "Color"
2023-12-20 12:01:52 +00:00
msgstr "Couleur"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/season/index.gohtml:51
2023-12-13 22:55:43 +00:00
msgid "No seasons added yet."
2023-12-20 12:01:52 +00:00
msgstr "Aucune saison n’ a encore été ajoutée."
2023-12-13 22:55:43 +00:00
#: web/templates/admin/season/calendar.gohtml:49
#: web/templates/admin/media/picker.gohtml:61
msgctxt "action"
msgid "Cancel"
2023-12-20 12:01:52 +00:00
msgstr "Annuler"
2023-12-13 22:55:43 +00:00
2023-12-18 20:23:03 +00:00
#: web/templates/admin/dashboard.gohtml:6
2024-01-27 21:51:41 +00:00
#: web/templates/admin/dashboard.gohtml:13 web/templates/admin/layout.gohtml:89
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Dashboard"
2023-12-20 12:01:52 +00:00
msgstr "Tableau de bord"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/login.gohtml:6 web/templates/admin/login.gohtml:18
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Login"
2023-12-20 12:01:52 +00:00
msgstr "Connexion"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/login.gohtml:36 web/templates/admin/profile.gohtml:49
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Password"
2023-12-20 12:01:52 +00:00
msgstr "Mot de passe"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/login.gohtml:45
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Login"
2023-12-20 12:01:52 +00:00
msgstr "Connexion"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/services/form.gohtml:8
2024-01-24 10:13:39 +00:00
#: web/templates/admin/services/form.gohtml:26
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Edit Service"
2023-12-20 12:01:52 +00:00
msgstr "Modifier le service"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/services/form.gohtml:10
2024-01-24 10:13:39 +00:00
#: web/templates/admin/services/form.gohtml:28
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "New Service"
2023-12-20 12:01:52 +00:00
msgstr "Nouveau service"
2023-12-13 22:55:43 +00:00
2024-01-24 10:13:39 +00:00
#: web/templates/admin/services/form.gohtml:15
2023-12-13 22:55:43 +00:00
#: web/templates/admin/services/index.gohtml:6
2024-01-27 21:51:41 +00:00
#: web/templates/admin/layout.gohtml:61
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Services Page"
2023-12-20 12:01:52 +00:00
msgstr "La page des services"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/services/index.gohtml:14
2024-01-23 10:52:39 +00:00
#: web/templates/admin/home/index.gohtml:83
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Carousel"
2023-12-20 12:01:52 +00:00
msgstr "Carrousel"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/services/index.gohtml:60
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Add service"
2023-12-20 12:01:52 +00:00
msgstr "Ajouter un service"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/services/index.gohtml:73
2024-01-13 00:15:24 +00:00
msgctxt "header"
msgid "Order"
msgstr "Ordre"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/services/index.gohtml:74
2023-12-13 22:55:43 +00:00
msgctxt "header"
msgid "Service"
2023-12-20 12:01:52 +00:00
msgstr "Service"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/services/index.gohtml:79
2023-12-13 22:55:43 +00:00
msgid "Are you sure you wish to delete this service?"
2023-12-20 12:01:52 +00:00
msgstr "Êtes-vous sûr de vouloir supprimer ce service ?"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/services/index.gohtml:100
2023-12-13 22:55:43 +00:00
msgid "No services added yet."
2023-12-20 12:01:52 +00:00
msgstr "Aucun service n’ a encore été ajouté."
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/profile.gohtml:6 web/templates/admin/profile.gohtml:15
2024-01-16 00:25:25 +00:00
#: web/templates/admin/layout.gohtml:33
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Profile"
2023-12-20 12:01:52 +00:00
msgstr "Profil"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/profile.gohtml:20
2023-12-13 22:55:43 +00:00
msgctxt "inut"
msgid "Profile Image"
2023-12-20 12:01:52 +00:00
msgstr "Image de profil"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/profile.gohtml:46
2023-12-13 22:55:43 +00:00
msgctxt "legend"
msgid "Change password"
2023-12-20 12:01:52 +00:00
msgstr "Changer le mot de passe"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/profile.gohtml:58
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Password Confirmation"
2023-12-20 12:01:52 +00:00
msgstr "Confirmation du mot de passe"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/profile.gohtml:68
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Language"
2023-12-20 12:01:52 +00:00
msgstr "Langue"
2023-12-13 22:55:43 +00:00
2024-01-17 19:28:42 +00:00
#: web/templates/admin/user/login-attempts.gohtml:6
2024-01-21 21:44:04 +00:00
#: web/templates/admin/user/login-attempts.gohtml:15
2024-01-17 19:28:42 +00:00
msgctxt "title"
msgid "Login Attempts"
msgstr "Tentatives de connexion"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/user/login-attempts.gohtml:10
#: web/templates/admin/user/index.gohtml:6
#: web/templates/admin/user/index.gohtml:16
2024-01-27 21:51:41 +00:00
#: web/templates/admin/layout.gohtml:73
2024-01-21 21:44:04 +00:00
msgctxt "title"
msgid "Users"
msgstr "Utilisateurs"
#: web/templates/admin/user/login-attempts.gohtml:19
2024-01-17 19:28:42 +00:00
msgctxt "header"
msgid "Date"
msgstr "Date"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/user/login-attempts.gohtml:20
#: web/templates/admin/user/index.gohtml:21
2024-01-17 19:28:42 +00:00
msgctxt "header"
msgid "Email"
msgstr "E-mail"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/user/login-attempts.gohtml:21
2024-01-17 19:28:42 +00:00
msgctxt "header"
msgid "IP Address"
msgstr "Adresse IP"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/user/login-attempts.gohtml:22
2024-01-17 19:28:42 +00:00
msgctxt "header"
msgid "Success"
msgstr "Succès"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/user/index.gohtml:14
Add admin page to list the users
There is no way, for now, to add, edit or remove users, because
currently we only need to list users.
I can not give admins access to the user table, for security
permissions, so i had to create a new view. I could name it also ‘user’
in ‘camper’ scheme, but then i was afraid i would have problems with
unit tests and their search_path, so instead i called it
‘company_user_profile’, which is like ‘user_profile’ but for all users
in ‘company_user’.
I created a new Go package for it, rather than add the admin handler in
‘auth’, because ‘template’ depends on ‘auth’, and rendering from ‘auth’
would cause a dependency loop.
I needed to have the roles in gettext to translate them, but there is
no obvious place where to put the call to PgettextNoop. For now, there
are in ‘NewAdminHandler’ because it is called once in the application’s
lifetime and they actually do not matter much.
2024-01-17 18:42:47 +00:00
msgctxt "action"
msgid "Add User"
msgstr "Ajouter un utilisateur"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/user/index.gohtml:15
2024-01-17 19:28:42 +00:00
msgctxt "action"
msgid "Logs"
msgstr "Journaux"
Add admin page to list the users
There is no way, for now, to add, edit or remove users, because
currently we only need to list users.
I can not give admins access to the user table, for security
permissions, so i had to create a new view. I could name it also ‘user’
in ‘camper’ scheme, but then i was afraid i would have problems with
unit tests and their search_path, so instead i called it
‘company_user_profile’, which is like ‘user_profile’ but for all users
in ‘company_user’.
I created a new Go package for it, rather than add the admin handler in
‘auth’, because ‘template’ depends on ‘auth’, and rendering from ‘auth’
would cause a dependency loop.
I needed to have the roles in gettext to translate them, but there is
no obvious place where to put the call to PgettextNoop. For now, there
are in ‘NewAdminHandler’ because it is called once in the application’s
lifetime and they actually do not matter much.
2024-01-17 18:42:47 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/user/index.gohtml:22
Add admin page to list the users
There is no way, for now, to add, edit or remove users, because
currently we only need to list users.
I can not give admins access to the user table, for security
permissions, so i had to create a new view. I could name it also ‘user’
in ‘camper’ scheme, but then i was afraid i would have problems with
unit tests and their search_path, so instead i called it
‘company_user_profile’, which is like ‘user_profile’ but for all users
in ‘company_user’.
I created a new Go package for it, rather than add the admin handler in
‘auth’, because ‘template’ depends on ‘auth’, and rendering from ‘auth’
would cause a dependency loop.
I needed to have the roles in gettext to translate them, but there is
no obvious place where to put the call to PgettextNoop. For now, there
are in ‘NewAdminHandler’ because it is called once in the application’s
lifetime and they actually do not matter much.
2024-01-17 18:42:47 +00:00
msgctxt "header"
msgid "Role"
msgstr "Rôle"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/user/index.gohtml:27
Add admin page to list the users
There is no way, for now, to add, edit or remove users, because
currently we only need to list users.
I can not give admins access to the user table, for security
permissions, so i had to create a new view. I could name it also ‘user’
in ‘camper’ scheme, but then i was afraid i would have problems with
unit tests and their search_path, so instead i called it
‘company_user_profile’, which is like ‘user_profile’ but for all users
in ‘company_user’.
I created a new Go package for it, rather than add the admin handler in
‘auth’, because ‘template’ depends on ‘auth’, and rendering from ‘auth’
would cause a dependency loop.
I needed to have the roles in gettext to translate them, but there is
no obvious place where to put the call to PgettextNoop. For now, there
are in ‘NewAdminHandler’ because it is called once in the application’s
lifetime and they actually do not matter much.
2024-01-17 18:42:47 +00:00
msgid "Are you sure you wish to delete this user?"
msgstr "Êtes-vous sûr de vouloir supprimer ce utilisateur ?"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/taxDetails.gohtml:6
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:15
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Tax Details"
2023-12-20 12:01:52 +00:00
msgstr "Détails de la taxe"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:20
#: web/templates/admin/taxDetails.gohtml:61
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Business Name"
2024-01-27 21:51:41 +00:00
msgstr "Nom de l’ entreprise"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:29
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "VAT Number"
2023-12-20 12:01:52 +00:00
msgstr "Numéro de TVA"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:37
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Trade Name"
2023-12-20 12:01:52 +00:00
msgstr "Nom commercial"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:69
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Address"
2023-12-20 12:01:52 +00:00
msgstr "Adresse"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:77
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "City"
2023-12-20 12:01:52 +00:00
msgstr "Ville"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:85
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Province"
2023-12-20 12:01:52 +00:00
msgstr "Province"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:93
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Postcode"
2023-12-20 12:01:52 +00:00
msgstr "Code Postal"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:111
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Currency"
2023-12-20 12:01:52 +00:00
msgstr "Devise"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:121
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Default Language"
2023-12-20 12:01:52 +00:00
msgstr "Langue par défaut"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:130
2024-01-14 01:09:17 +00:00
msgctxt "title"
msgid "Tourism"
msgstr "Tourisme"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:133
2024-01-14 01:09:17 +00:00
msgctxt "input"
msgid "RTC number"
msgstr "Numéro RTC"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:141
2024-01-14 01:09:17 +00:00
msgctxt "input"
msgid "Tourist Tax"
msgstr "Taxe touristique"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:150
2024-01-14 01:09:17 +00:00
msgctxt "title"
msgid "Invoicing"
msgstr "Facturation"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:153
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Invoice Number Format"
2023-12-20 12:01:52 +00:00
msgstr "Format de numéro de facture"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/taxDetails.gohtml:161
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Legal Disclaimer"
2023-12-20 12:01:52 +00:00
msgstr "Avertissement juridique"
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: web/templates/admin/surroundings/form.gohtml:8
2024-01-21 21:44:04 +00:00
#: web/templates/admin/surroundings/form.gohtml:29
2024-01-16 00:25:25 +00:00
msgctxt "title"
msgid "Edit Highlight"
msgstr "Modifier un point d’ intérêt"
#: web/templates/admin/surroundings/form.gohtml:10
2024-01-21 21:44:04 +00:00
#: web/templates/admin/surroundings/form.gohtml:31
2024-01-16 00:25:25 +00:00
msgctxt "title"
msgid "New Highlight"
msgstr "Nouveau point d’ intérêt"
#: web/templates/admin/surroundings/index.gohtml:6
msgctxt "title"
msgid "Surroundings Page"
msgstr "Page de l’ entourage"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/surroundings/index.gohtml:14
2024-01-16 00:25:25 +00:00
msgctxt "title"
2024-01-23 13:53:15 +00:00
msgid "Ad"
msgstr "Annonce"
#: web/templates/admin/surroundings/index.gohtml:21
msgctxt "input"
msgid "Title"
msgstr "Titre"
#: web/templates/admin/surroundings/index.gohtml:37
msgctxt "input"
msgid "Link Text"
msgstr "Texte du lien"
#: web/templates/admin/surroundings/index.gohtml:50
msgctxt "input"
msgid "Link URL"
msgstr "Address du lien"
#: web/templates/admin/surroundings/index.gohtml:59
msgid "Are you sure you wish to delete the ad?"
msgstr "Êtes-vous sûr de vouloir supprimer cette annonce ?"
#: web/templates/admin/surroundings/index.gohtml:68
msgctxt "title"
2024-01-16 00:25:25 +00:00
msgid "Highlights"
msgstr "Points d’ intérêt"
2024-01-23 13:53:15 +00:00
#: web/templates/admin/surroundings/index.gohtml:69
2024-01-16 00:25:25 +00:00
msgctxt "action"
msgid "Add highlight"
msgstr "Ajouter un point d’ intérêt"
2024-01-23 13:53:15 +00:00
#: web/templates/admin/surroundings/index.gohtml:88
2024-01-16 00:25:25 +00:00
msgid "Are you sure you wish to delete this highlight?"
msgstr "Êtes-vous sûr de vouloir supprimer cette point d’ intérêt ?"
2024-01-23 13:53:15 +00:00
#: web/templates/admin/surroundings/index.gohtml:110
2024-01-16 00:25:25 +00:00
msgid "No highlights added yet."
msgstr "Aucun point d’ intérêt n’ a encore été ajoutée."
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/feature/form.gohtml:8
msgctxt "title"
msgid "Edit Amenity Feature"
msgstr "Modifier l’ entité de installation"
#: web/templates/admin/amenity/feature/form.gohtml:10
msgctxt "title"
msgid "New Amenity Feature"
msgstr "Nouvelle caractéristique de installation"
#: web/templates/admin/amenity/feature/form.gohtml:16
#: web/templates/admin/amenity/feature/index.gohtml:10
#: web/templates/admin/amenity/carousel/form.gohtml:16
#: web/templates/admin/amenity/carousel/index.gohtml:10
#: web/templates/admin/amenity/form.gohtml:15
#: web/templates/admin/amenity/index.gohtml:6
#: web/templates/admin/layout.gohtml:49
msgctxt "title"
msgid "Amenities"
2024-01-29 13:37:27 +00:00
msgstr "Installations"
2024-01-27 21:51:41 +00:00
#: web/templates/admin/amenity/feature/form.gohtml:17
#: web/templates/admin/amenity/feature/index.gohtml:6
msgctxt "title"
msgid "Amenity Features"
msgstr "Caractéristiques de installation"
#: web/templates/admin/amenity/feature/index.gohtml:56
msgid "No amenity features added yet."
msgstr "Aucune caractéristique de installation n’ a encore été ajoutée."
#: web/templates/admin/amenity/carousel/form.gohtml:8
msgctxt "title"
msgid "Edit Amenity Carousel Slide"
msgstr "Modifier la diapositive du carrousel de installation"
#: web/templates/admin/amenity/carousel/form.gohtml:10
msgctxt "title"
msgid "New Amenity Carousel Slide"
msgstr "Nouveau diapositive de carrousel de installation"
#: web/templates/admin/amenity/carousel/form.gohtml:17
#: web/templates/admin/amenity/carousel/index.gohtml:6
msgctxt "title"
msgid "Amenity Carousel"
msgstr "Carrousel de installation"
#: web/templates/admin/amenity/form.gohtml:8
msgctxt "title"
msgid "Edit Amenity"
msgstr "Modifier l’ installation"
#: web/templates/admin/amenity/form.gohtml:10
msgctxt "title"
msgid "New Amenity"
msgstr "Nouveau installation"
#: web/templates/admin/amenity/form.gohtml:33
#: web/templates/admin/amenity/index.gohtml:24
msgctxt "amenity"
msgid "Active"
msgstr "Actif"
#: web/templates/admin/amenity/index.gohtml:14
msgctxt "action"
msgid "Add Amenity"
msgstr "Ajouter un installation"
2024-01-29 02:38:11 +00:00
#: web/templates/admin/amenity/index.gohtml:29
msgid "Are you sure you wish to delete this amenity?"
msgstr "Êtes-vous sûr de vouloir supprimer ce installation ?"
#: web/templates/admin/amenity/index.gohtml:53
2024-01-27 21:51:41 +00:00
msgid "No amenities added yet."
msgstr "Aucun installation n’ a encore été ajouté."
2024-01-16 00:25:25 +00:00
#: web/templates/admin/layout.gohtml:29
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "User Menu"
2023-12-20 12:01:52 +00:00
msgstr "Menu utilisateur"
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: web/templates/admin/layout.gohtml:37
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Company Settings"
2024-01-27 21:51:41 +00:00
msgstr "Paramètres de l’ entreprise"
2023-12-13 22:55:43 +00:00
2024-01-18 20:05:30 +00:00
#: web/templates/admin/layout.gohtml:40
#: web/templates/admin/booking/payment.gohtml:6
2024-01-21 21:44:04 +00:00
#: web/templates/admin/booking/payment.gohtml:15
2024-01-18 20:05:30 +00:00
msgctxt "title"
msgid "Payment Settings"
msgstr "Paramètres de paiement"
2024-01-27 21:51:41 +00:00
#: web/templates/admin/layout.gohtml:55
2024-01-21 21:44:04 +00:00
#: web/templates/admin/media/form.gohtml:10
2023-12-18 20:23:03 +00:00
#: web/templates/admin/media/index.gohtml:6
2024-01-21 21:44:04 +00:00
#: web/templates/admin/media/index.gohtml:14
#: web/templates/admin/media/upload.gohtml:10
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Media"
2023-12-20 12:01:52 +00:00
msgstr "Média"
2023-12-13 22:55:43 +00:00
2024-01-27 21:51:41 +00:00
#: web/templates/admin/layout.gohtml:58 web/templates/admin/home/index.gohtml:6
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Home Page"
2023-12-20 12:01:52 +00:00
msgstr "Page d'accueil"
2023-12-13 22:55:43 +00:00
2024-01-27 21:51:41 +00:00
#: web/templates/admin/layout.gohtml:78
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Logout"
2023-12-20 12:01:52 +00:00
msgstr "Déconnexion"
2023-12-13 22:55:43 +00:00
2024-01-27 21:51:41 +00:00
#: web/templates/admin/layout.gohtml:92
2024-01-18 20:05:30 +00:00
#: web/templates/admin/booking/index.gohtml:6
2024-01-21 21:44:04 +00:00
#: web/templates/admin/booking/index.gohtml:16
2024-01-18 20:05:30 +00:00
msgctxt "title"
msgid "Bookings"
msgstr "Réservations"
2024-01-27 21:51:41 +00:00
#: web/templates/admin/layout.gohtml:101
2024-01-21 21:44:04 +00:00
msgid "Breadcrumb"
msgstr "Fil d’ Ariane"
2024-01-27 21:51:41 +00:00
#: web/templates/admin/layout.gohtml:113
2024-01-21 19:50:04 +00:00
msgid "Camper Version: %s"
msgstr "Camper version: %s"
2024-01-23 10:52:39 +00:00
#: web/templates/admin/home/index.gohtml:15
msgctxt "title"
msgid "Slogan"
msgstr "Slogan"
#: web/templates/admin/home/index.gohtml:21
msgctxt "input"
msgid "Slogan"
msgstr "Slogan"
#: web/templates/admin/home/index.gohtml:38
Add home’s cover carousel
This is a separate carousel from the one displayed at the bottom with
location info; it is, i suppose, a carousel for the hero image.
For the database, it works exactly as the home carousel, but on the
front had to use AlpineJS instead of Slick because it needs to show a
text popping up from the bottom when the slide is show, something i do
not know how to do in Slick.
It now makes no sense to have the carousel inside the “nature” section,
because the heading is no longer in there, and moved it out into a new
“hero” div.
Since i now have two carousels in home, i had to add additional
attributes to carousel.AdminHandler to know which URL to point to when
POSTing, PUTting, or redirecting.
2024-01-16 20:05:52 +00:00
msgctxt "title"
msgid "Cover"
msgstr "Couverture"
2024-01-23 10:52:39 +00:00
#: web/templates/admin/home/index.gohtml:39
Add home’s cover carousel
This is a separate carousel from the one displayed at the bottom with
location info; it is, i suppose, a carousel for the hero image.
For the database, it works exactly as the home carousel, but on the
front had to use AlpineJS instead of Slick because it needs to show a
text popping up from the bottom when the slide is show, something i do
not know how to do in Slick.
It now makes no sense to have the carousel inside the “nature” section,
because the heading is no longer in there, and moved it out into a new
“hero” div.
Since i now have two carousels in home, i had to add additional
attributes to carousel.AdminHandler to know which URL to point to when
POSTing, PUTting, or redirecting.
2024-01-16 20:05:52 +00:00
msgctxt "action"
msgid "Add cover image"
msgstr "Ajouter une image de couverture"
2024-01-23 10:52:39 +00:00
#: web/templates/admin/home/index.gohtml:58
Add home’s cover carousel
This is a separate carousel from the one displayed at the bottom with
location info; it is, i suppose, a carousel for the hero image.
For the database, it works exactly as the home carousel, but on the
front had to use AlpineJS instead of Slick because it needs to show a
text popping up from the bottom when the slide is show, something i do
not know how to do in Slick.
It now makes no sense to have the carousel inside the “nature” section,
because the heading is no longer in there, and moved it out into a new
“hero” div.
Since i now have two carousels in home, i had to add additional
attributes to carousel.AdminHandler to know which URL to point to when
POSTing, PUTting, or redirecting.
2024-01-16 20:05:52 +00:00
msgid "Are you sure you wish to delete this cover image?"
msgstr "Êtes-vous sûr de vouloir supprimer cette image de couverture ?"
2024-01-23 10:52:39 +00:00
#: web/templates/admin/home/index.gohtml:80
Add home’s cover carousel
This is a separate carousel from the one displayed at the bottom with
location info; it is, i suppose, a carousel for the hero image.
For the database, it works exactly as the home carousel, but on the
front had to use AlpineJS instead of Slick because it needs to show a
text popping up from the bottom when the slide is show, something i do
not know how to do in Slick.
It now makes no sense to have the carousel inside the “nature” section,
because the heading is no longer in there, and moved it out into a new
“hero” div.
Since i now have two carousels in home, i had to add additional
attributes to carousel.AdminHandler to know which URL to point to when
POSTing, PUTting, or redirecting.
2024-01-16 20:05:52 +00:00
msgid "No images added to the cover yet."
msgstr "Aucune image de couverture n’ a encore été ajoutée."
2023-12-13 22:55:43 +00:00
#: web/templates/admin/media/picker.gohtml:8
msgctxt "title"
msgid "Media Picker"
2023-12-20 12:01:52 +00:00
msgstr "Sélecteur de médias"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/media/picker.gohtml:19
msgctxt "title"
msgid "Upload New Media"
2023-12-20 12:01:52 +00:00
msgstr "Téléverser de nouveaux médias"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/media/picker.gohtml:22
2024-01-21 21:44:04 +00:00
#: web/templates/admin/media/upload.gohtml:21
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "File"
2023-12-20 12:01:52 +00:00
msgstr "Fichier"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/media/picker.gohtml:26
2024-01-21 21:44:04 +00:00
#: web/templates/admin/media/form.gohtml:26
#: web/templates/admin/media/upload.gohtml:25
2023-12-13 22:55:43 +00:00
msgid "Maximum upload file size: %s"
2023-12-20 12:01:52 +00:00
msgstr "Taille maximale de téléversement : %s"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/media/picker.gohtml:31
2024-01-21 21:44:04 +00:00
#: web/templates/admin/media/upload.gohtml:30
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Upload"
2023-12-20 12:01:52 +00:00
msgstr "Télécharger"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/media/picker.gohtml:47
msgctxt "title"
msgid "Choose Existing Media"
2023-12-20 12:01:52 +00:00
msgstr "Choisir un média existant"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/media/picker.gohtml:58
2024-01-21 21:44:04 +00:00
#: web/templates/admin/media/index.gohtml:23
2023-12-13 22:55:43 +00:00
msgid "No media uploaded yet."
2023-12-20 12:01:52 +00:00
msgstr "Aucun média n’ a encore été téléchargé."
2023-12-13 22:55:43 +00:00
#: web/templates/admin/media/form.gohtml:6
2024-01-21 21:44:04 +00:00
#: web/templates/admin/media/form.gohtml:16
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Edit Media"
2023-12-20 12:01:52 +00:00
msgstr "Modifier un média"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/media/form.gohtml:22
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Updated file"
2023-12-20 12:01:52 +00:00
msgstr "Fichier mis à jour"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/media/form.gohtml:31
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Filename"
2023-12-20 12:01:52 +00:00
msgstr "Nom du fichier"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/media/index.gohtml:15
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Upload media"
2023-12-20 12:01:52 +00:00
msgstr "Télécharger les médias"
2023-12-13 22:55:43 +00:00
#: web/templates/admin/media/upload.gohtml:6
2024-01-21 21:44:04 +00:00
#: web/templates/admin/media/upload.gohtml:16
2023-12-13 22:55:43 +00:00
msgctxt "title"
msgid "Upload Media"
2023-12-20 12:01:52 +00:00
msgstr "Envoyer un fichier"
2023-12-13 22:55:43 +00:00
2024-01-21 21:44:04 +00:00
#: web/templates/admin/booking/payment.gohtml:20
2024-01-18 20:05:30 +00:00
msgctxt "input"
msgid "Merchant Code"
msgstr "Code Marchant"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/booking/payment.gohtml:29
2024-01-18 20:05:30 +00:00
msgctxt "input"
msgid "Terminal Number"
msgstr "Numéro de terminal"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/booking/payment.gohtml:39
2024-01-18 20:05:30 +00:00
msgctxt "input"
msgid "Merchant Key (only if must change it)"
msgstr "Clé marchande (uniquement si vous devez la changer)"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/booking/payment.gohtml:41
2024-01-18 20:05:30 +00:00
msgctxt "input"
msgid "Merchant Key"
msgstr "Clé Marchant"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/booking/payment.gohtml:51
2024-01-18 20:05:30 +00:00
msgctxt "title"
msgid "Environment"
msgstr "Environnement"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/booking/payment.gohtml:58
2024-01-18 20:05:30 +00:00
msgctxt "title"
msgid "Integration"
msgstr "Intégration"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/booking/index.gohtml:14
2024-01-18 20:05:30 +00:00
msgctxt "action"
msgid "Add Booking"
msgstr "Ajouter une réservation"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/booking/index.gohtml:15
2024-01-18 20:05:30 +00:00
msgctxt "action"
msgid "Export Bookings"
msgstr "Exporter les réservations"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/booking/index.gohtml:21
2024-01-18 20:05:30 +00:00
msgctxt "header"
msgid "Reference"
msgstr "Référence"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/booking/index.gohtml:22
2024-01-18 20:05:30 +00:00
msgctxt "header"
msgid "Arrival Date"
msgstr "Date d’ arrivée"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/booking/index.gohtml:23
2024-01-18 20:05:30 +00:00
msgctxt "header"
msgid "Departure Date"
msgstr "Date de depart"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/booking/index.gohtml:24
2024-01-18 20:05:30 +00:00
msgctxt "header"
msgid "Holder Name"
msgstr "Nom du titulaire"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/booking/index.gohtml:25
2024-01-18 20:05:30 +00:00
msgctxt "header"
msgid "Status"
msgstr "Statut"
2024-01-21 21:44:04 +00:00
#: web/templates/admin/booking/index.gohtml:41
2024-01-18 20:05:30 +00:00
msgid "No booking found."
msgstr "Aucune réservation trouvée."
2024-02-13 04:20:35 +00:00
#: pkg/payment/public.go:107
2024-02-12 17:06:17 +00:00
msgctxt "order product name"
msgid "Campsite Booking"
msgstr "Réservation camping"
2024-02-13 04:20:35 +00:00
#: pkg/payment/public.go:344
msgctxt "subject"
msgid "Booking payment successfully received"
msgstr "Paiement de réservation reçu avec succès"
2024-02-11 20:45:00 +00:00
#: pkg/legal/admin.go:258 pkg/app/user.go:249 pkg/campsite/types/option.go:365
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/feature.go:272 pkg/campsite/types/admin.go:577
2024-01-26 21:27:54 +00:00
#: pkg/campsite/feature.go:269 pkg/season/admin.go:412
#: pkg/services/admin.go:316 pkg/surroundings/admin.go:340
2024-01-29 02:38:11 +00:00
#: pkg/amenity/feature.go:269 pkg/amenity/admin.go:283
2023-12-22 01:23:18 +00:00
msgid "Name can not be empty."
msgstr "Le nom ne peut pas être laissé vide."
2024-02-11 20:45:00 +00:00
#: pkg/legal/admin.go:259 pkg/campsite/types/option.go:366
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/feature.go:273 pkg/campsite/types/admin.go:578
2024-01-27 21:51:41 +00:00
#: pkg/campsite/feature.go:270 pkg/amenity/feature.go:270
2023-12-22 01:23:18 +00:00
msgid "Name must have at least one letter."
msgstr "Le nom doit comporter au moins une lettre."
2024-01-23 10:52:39 +00:00
#: pkg/carousel/admin.go:276 pkg/campsite/types/carousel.go:225
2024-01-27 21:51:41 +00:00
#: pkg/campsite/carousel.go:227 pkg/amenity/carousel.go:227
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Slide image"
2023-12-20 12:01:52 +00:00
msgstr "Image du diaporama"
2023-12-13 22:55:43 +00:00
2024-01-23 10:52:39 +00:00
#: pkg/carousel/admin.go:277 pkg/campsite/types/carousel.go:226
2024-01-27 21:51:41 +00:00
#: pkg/campsite/carousel.go:228 pkg/amenity/carousel.go:228
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Set slide image"
2023-12-20 12:01:52 +00:00
msgstr "Définir l’ image de la diapositive"
2023-12-13 22:55:43 +00:00
2024-01-23 10:52:39 +00:00
#: pkg/carousel/admin.go:346 pkg/campsite/types/carousel.go:299
2024-01-26 21:27:54 +00:00
#: pkg/campsite/carousel.go:302 pkg/surroundings/admin.go:335
2024-01-27 21:51:41 +00:00
#: pkg/amenity/carousel.go:302
2023-12-13 22:55:43 +00:00
msgid "Slide image can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "L’ image de la diapositive ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-01-23 10:52:39 +00:00
#: pkg/carousel/admin.go:347 pkg/campsite/types/carousel.go:300
2024-01-26 21:27:54 +00:00
#: pkg/campsite/carousel.go:303 pkg/surroundings/admin.go:336
2024-01-27 21:51:41 +00:00
#: pkg/amenity/carousel.go:303
2023-12-13 22:55:43 +00:00
msgid "Slide image must be an image media type."
2023-12-20 12:01:52 +00:00
msgstr "L’ image de la diapositive doit être de type média d’ image."
2023-12-13 22:55:43 +00:00
2024-01-14 01:09:17 +00:00
#: pkg/app/login.go:56 pkg/app/user.go:246 pkg/company/admin.go:217
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:533
2023-12-13 22:55:43 +00:00
msgid "Email can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "L’ e-mail ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-01-14 01:09:17 +00:00
#: pkg/app/login.go:57 pkg/app/user.go:247 pkg/company/admin.go:218
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:534
2023-12-13 22:55:43 +00:00
msgid "This email is not valid. It should be like name@domain.com."
2023-12-18 20:23:03 +00:00
msgstr "Cette adresse e-mail n’ est pas valide. Il devrait en être name@domain.com."
2023-12-13 22:55:43 +00:00
#: pkg/app/login.go:59
msgid "Password can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "Le mot de passe ne peut pas être vide."
2023-12-13 22:55:43 +00:00
#: pkg/app/login.go:86
msgid "Invalid user or password."
2023-12-20 12:01:52 +00:00
msgstr "Utilisateur ou mot de passe non valide."
2023-12-13 22:55:43 +00:00
#: pkg/app/user.go:197
msgctxt "language option"
msgid "Automatic"
2023-12-20 12:01:52 +00:00
msgstr "Automatique"
2023-12-13 22:55:43 +00:00
#: pkg/app/user.go:250
msgid "Confirmation does not match password."
2023-12-20 12:01:52 +00:00
msgstr "La confirmation ne correspond pas au mot de passe."
2023-12-13 22:55:43 +00:00
2024-01-14 01:09:17 +00:00
#: pkg/app/user.go:251 pkg/company/admin.go:238
2023-12-13 22:55:43 +00:00
msgid "Selected language is not valid."
2023-12-20 12:01:52 +00:00
msgstr "La langue sélectionnée n’ est pas valide."
2023-12-13 22:55:43 +00:00
#: pkg/app/user.go:253
msgid "File must be a valid PNG or JPEG image."
2023-12-20 12:01:52 +00:00
msgstr "Le fichier doit être une image PNG ou JPEG valide."
2023-12-13 22:55:43 +00:00
2024-01-27 21:51:41 +00:00
#: pkg/app/admin.go:70
2023-12-13 22:55:43 +00:00
msgid "Access forbidden"
2023-12-20 12:01:52 +00:00
msgstr "Accès interdit"
2023-12-13 22:55:43 +00:00
2024-02-11 20:45:00 +00:00
#: pkg/campsite/types/option.go:369
2023-12-13 22:55:43 +00:00
msgid "Minimum can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "Le minimum ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-02-11 20:45:00 +00:00
#: pkg/campsite/types/option.go:370
2023-12-13 22:55:43 +00:00
msgid "Minimum must be an integer number."
2023-12-20 12:01:52 +00:00
msgstr "Le minimum doit être un nombre entier."
2023-12-13 22:55:43 +00:00
2024-02-11 20:45:00 +00:00
#: pkg/campsite/types/option.go:372
2023-12-13 22:55:43 +00:00
msgid "Minimum must be zero or greater."
2023-12-20 12:01:52 +00:00
msgstr "Le minimum doit être égal ou supérieur à zéro."
2023-12-13 22:55:43 +00:00
2024-02-11 20:45:00 +00:00
#: pkg/campsite/types/option.go:375
2023-12-13 22:55:43 +00:00
msgid "Maximum can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "Le maximum ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-02-11 20:45:00 +00:00
#: pkg/campsite/types/option.go:376
2023-12-13 22:55:43 +00:00
msgid "Maximum must be an integer number."
2023-12-20 12:01:52 +00:00
msgstr "Le maximum doit être un nombre entier."
2023-12-13 22:55:43 +00:00
2024-02-11 20:45:00 +00:00
#: pkg/campsite/types/option.go:378
2023-12-13 22:55:43 +00:00
msgid "Maximum must be equal or greater than minimum."
2023-12-20 12:01:52 +00:00
msgstr "Le maximum doit être égal ou supérieur au minimum."
2023-12-13 22:55:43 +00:00
2024-02-11 20:45:00 +00:00
#: pkg/campsite/types/option.go:382
msgid "Price can not be empty."
msgstr "Le prix ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-02-11 20:45:00 +00:00
#: pkg/campsite/types/option.go:383
msgid "Price must be a decimal number."
msgstr "Le prix doit être un nombre décimal."
2023-12-13 22:55:43 +00:00
2024-02-11 20:45:00 +00:00
#: pkg/campsite/types/option.go:384
msgid "Price must be zero or greater."
msgstr "Le prix doit être égal ou supérieur à zéro."
2023-12-13 22:55:43 +00:00
2024-01-26 21:54:19 +00:00
#: pkg/campsite/types/feature.go:271 pkg/campsite/feature.go:268
2024-01-27 21:51:41 +00:00
#: pkg/services/admin.go:315 pkg/amenity/feature.go:268
2023-12-13 22:55:43 +00:00
msgid "Selected icon is not valid."
2023-12-20 12:01:52 +00:00
msgstr "L’ icône sélectionnée n’ est pas valide."
2023-12-13 22:55:43 +00:00
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:328
2023-12-13 22:55:43 +00:00
msgctxt "input"
msgid "Cover image"
2023-12-20 12:01:52 +00:00
msgstr "Image de couverture"
2023-12-13 22:55:43 +00:00
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:329
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Set campsite type cover"
2023-12-20 12:01:52 +00:00
msgstr "Définir une couverture type camping"
2023-12-13 22:55:43 +00:00
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:580
2024-01-22 19:19:19 +00:00
msgid "Check-in can not be empty."
msgstr "L’ arrivée ne peut pas être vide."
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:581
2024-01-22 19:19:19 +00:00
msgid "Check-out can not be empty."
msgstr "Le départ ne peut pas être vide."
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:582
2023-12-13 22:55:43 +00:00
msgid "Cover image can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "L’ image de couverture ne peut pas être vide."
2023-12-13 22:55:43 +00:00
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:583
2023-12-13 22:55:43 +00:00
msgid "Cover image must be an image media type."
2023-12-20 12:01:52 +00:00
msgstr "L’ image de couverture doit être de type média d’ image."
2023-12-13 22:55:43 +00:00
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:587
2023-12-13 22:55:43 +00:00
msgid "Maximum number of campers can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "Le nombre maximum de campeurs ne peut pas être vide."
2023-12-13 22:55:43 +00:00
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:588
2023-12-13 22:55:43 +00:00
msgid "Maximum number of campers must be an integer number."
2023-12-20 12:01:52 +00:00
msgstr "Le nombre maximum de campeurs doit être un nombre entier."
2023-12-13 22:55:43 +00:00
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:589
2023-12-13 22:55:43 +00:00
msgid "Maximum number of campers must be one or greater."
2023-12-20 12:01:52 +00:00
msgstr "Le nombre maximum de campeurs doit être égal ou supérieur à un campeur."
2023-12-13 22:55:43 +00:00
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:592
2023-12-13 22:55:43 +00:00
msgid "Minimum number of nights can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "Le nombre minimum de nuits ne peut pas être vide."
2023-12-13 22:55:43 +00:00
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:593
2023-12-13 22:55:43 +00:00
msgid "Minimum number of nights must be an integer."
2023-12-20 12:01:52 +00:00
msgstr "Le nombre minimum de nuits doit être un entier."
2023-12-13 22:55:43 +00:00
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:594
2023-12-13 22:55:43 +00:00
msgid "Minimum number of nights must be one or greater."
2023-12-20 12:01:52 +00:00
msgstr "Le nombre minimum de nuits doit être supérieur ou égal à une nuit."
2023-12-13 22:55:43 +00:00
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:597
2024-01-31 22:06:45 +00:00
msgid "Maximum number of nights can not be empty."
msgstr "Le nombre maximale de nuits ne peut pas être vide."
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:598
2024-01-31 22:06:45 +00:00
msgid "Maximum number of nights must be an integer."
msgstr "Le nombre maximale de nuits doit être un entier."
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:599
2024-01-31 22:06:45 +00:00
msgid "Maximum number of nights must be equal or greater than the minimum."
msgstr "Le nombre maximale de nuits doit être égal ou supérieur au minimum."
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:603
msgid "Dogs price can not be empty when dogs are allowed."
msgstr "Le prix des chiens net peut pas être vide lorsqu’ ils sont acceptés."
#: pkg/campsite/types/admin.go:604
msgid "Dogs price must be a decimal number."
msgstr "Le prix des chiens doit être un nombre décimal."
#: pkg/campsite/types/admin.go:605
msgid "Dogs price must be zero or greater."
msgstr "Le prix de chiens doit être égal ou supérieur à zéro."
2024-02-11 20:45:00 +00:00
#: pkg/campsite/types/admin.go:610
msgid "Price per night can not be empty."
msgstr "Le prix par nuit ne peut pas être vide."
#: pkg/campsite/types/admin.go:611
msgid "Price per night must be a decimal number."
msgstr "Le prix par nuit doit être un nombre décimal."
#: pkg/campsite/types/admin.go:612
msgid "Price per night must be zero or greater."
msgstr "Le prix par nuit doit être égal ou supérieur."
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:615
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Price per adult can not be empty."
msgstr "Le prix par adulte ne peut pas être vide."
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:616
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Price per adult must be a decimal number."
msgstr "Le prix par adulte doit être un nombre décimal."
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:617
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Price per adult must be zero or greater."
msgstr "Le prix par adulte doit être égal ou supérieur."
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:620
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Price per teenager can not be empty."
msgstr "Le prix par adolescent ne peut pas être vide."
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:621
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Price per teenager must be a decimal number."
msgstr "Le prix par adolescent doit être un nombre décimal."
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:622
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Price per teenager must be zero or greater."
msgstr "Le prix par adolescent doit être égal ou supérieur."
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:625
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Price per child can not be empty."
msgstr "Le prix par enfant ne peut pas être vide."
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:626
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Price per child must be a decimal number."
msgstr "Le prix par enfant doit être un nombre décimal."
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
#: pkg/campsite/types/admin.go:627
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Price per child must be zero or greater."
msgstr "Le prix par enfant doit être égal ou supérieur."
2024-02-11 20:45:00 +00:00
#: pkg/campsite/types/public.go:247
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "header"
msgid "Adults"
msgstr "Adultes"
2024-02-11 20:45:00 +00:00
#: pkg/campsite/types/public.go:254
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "header"
msgid "Teenagers (aged 11 to 16)"
msgstr "Adolescents (de 11 à 16 anys)"
2024-02-11 20:45:00 +00:00
#: pkg/campsite/types/public.go:261
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "header"
msgid "Children (aged 2 to 10)"
msgstr "Enfants (de 2 à 10 anys)"
2024-02-12 17:06:17 +00:00
#: pkg/campsite/admin.go:275 pkg/booking/public.go:171
#: pkg/booking/public.go:226
2023-12-13 22:55:43 +00:00
msgid "Selected campsite type is not valid."
2023-12-20 12:01:52 +00:00
msgstr "Le type d’ emplacement sélectionné n’ est pas valide."
2023-12-13 22:55:43 +00:00
2024-01-29 02:38:11 +00:00
#: pkg/campsite/admin.go:276 pkg/amenity/admin.go:282
2023-12-13 22:55:43 +00:00
msgid "Label can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "L'étiquette ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:183
2023-12-13 22:55:43 +00:00
msgctxt "month"
msgid "January"
2023-12-20 12:01:52 +00:00
msgstr "Janvier"
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:184
2023-12-13 22:55:43 +00:00
msgctxt "month"
msgid "February"
2023-12-20 12:01:52 +00:00
msgstr "Février"
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:185
2023-12-13 22:55:43 +00:00
msgctxt "month"
msgid "March"
2023-12-20 12:01:52 +00:00
msgstr "Mars"
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:186
2023-12-13 22:55:43 +00:00
msgctxt "month"
msgid "April"
2023-12-20 12:01:52 +00:00
msgstr "Avril"
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:187
2023-12-13 22:55:43 +00:00
msgctxt "month"
msgid "May"
2023-12-20 12:01:52 +00:00
msgstr "Mai"
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:188
2023-12-13 22:55:43 +00:00
msgctxt "month"
msgid "June"
2023-12-20 12:01:52 +00:00
msgstr "Juin"
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:189
2023-12-13 22:55:43 +00:00
msgctxt "month"
msgid "July"
2023-12-20 12:01:52 +00:00
msgstr "Juillet"
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:190
2023-12-13 22:55:43 +00:00
msgctxt "month"
msgid "August"
2023-12-20 12:01:52 +00:00
msgstr "Août"
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:191
2023-12-13 22:55:43 +00:00
msgctxt "month"
msgid "September"
2023-12-20 12:01:52 +00:00
msgstr "Septembre"
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:192
2023-12-13 22:55:43 +00:00
msgctxt "month"
msgid "October"
2023-12-20 12:01:52 +00:00
msgstr "Octobre"
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:193
2023-12-13 22:55:43 +00:00
msgctxt "month"
msgid "November"
2023-12-20 12:01:52 +00:00
msgstr "Novembre"
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:194
2023-12-13 22:55:43 +00:00
msgctxt "month"
msgid "December"
2023-12-20 12:01:52 +00:00
msgstr "Décembre"
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:413
2023-12-13 22:55:43 +00:00
msgid "Color can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "La couleur ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:414
2023-12-13 22:55:43 +00:00
msgid "This color is not valid. It must be like #123abc."
2023-12-20 12:01:52 +00:00
msgstr "Cette couleur n’ est pas valide. Il doit être comme #123abc."
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:514
2023-12-13 22:55:43 +00:00
msgctxt "action"
msgid "Unset"
2023-12-20 12:01:52 +00:00
msgstr "Unset"
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:545
2023-12-13 22:55:43 +00:00
msgid "Start date can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "La date de début ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:546
2023-12-13 22:55:43 +00:00
msgid "Start date must be a valid date."
2023-12-20 12:01:52 +00:00
msgstr "La date de début doit être une date valide."
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:548
2023-12-13 22:55:43 +00:00
msgid "End date can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "La date de fin ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/season/admin.go:549
2023-12-13 22:55:43 +00:00
msgid "End date must be a valid date."
2023-12-20 12:01:52 +00:00
msgstr "La date de fin doit être une date valide."
2023-12-13 22:55:43 +00:00
Add admin page to list the users
There is no way, for now, to add, edit or remove users, because
currently we only need to list users.
I can not give admins access to the user table, for security
permissions, so i had to create a new view. I could name it also ‘user’
in ‘camper’ scheme, but then i was afraid i would have problems with
unit tests and their search_path, so instead i called it
‘company_user_profile’, which is like ‘user_profile’ but for all users
in ‘company_user’.
I created a new Go package for it, rather than add the admin handler in
‘auth’, because ‘template’ depends on ‘auth’, and rendering from ‘auth’
would cause a dependency loop.
I needed to have the roles in gettext to translate them, but there is
no obvious place where to put the call to PgettextNoop. For now, there
are in ‘NewAdminHandler’ because it is called once in the application’s
lifetime and they actually do not matter much.
2024-01-17 18:42:47 +00:00
#: pkg/user/admin.go:18
msgctxt "role"
msgid "guest"
msgstr "invité"
#: pkg/user/admin.go:19
msgctxt "role"
msgid "employee"
msgstr "employé"
#: pkg/user/admin.go:20
msgctxt "role"
msgid "admin"
msgstr "administrateur"
2024-01-23 13:53:15 +00:00
#: pkg/surroundings/admin.go:286
2024-01-16 00:25:25 +00:00
msgctxt "input"
msgid "Highlight image"
msgstr "Image du point d’ intérêt"
2024-01-23 13:53:15 +00:00
#: pkg/surroundings/admin.go:287
2024-01-16 00:25:25 +00:00
msgctxt "action"
msgid "Set highlight image"
msgstr "Définir l’ image du point d’ intérêt"
2024-01-23 13:53:15 +00:00
#: pkg/surroundings/admin.go:407
msgctxt "input"
msgid "Ad image"
msgstr "Image de l’ annonce"
#: pkg/surroundings/admin.go:408
msgctxt "action"
msgid "Set ad image"
msgstr "Définir l’ image de l’ annonce"
#: pkg/surroundings/admin.go:459
msgid "Ad image can not be empty."
msgstr "L’ image de l’ annonce ne peut pas être vide."
#: pkg/surroundings/admin.go:460
msgid "Ad image must be an image media type."
msgstr "L’ image de l’ annonce doit être de type média d’ image."
#: pkg/surroundings/admin.go:464
msgid "The title can not be empty."
msgstr "Le titre ne peut pas être vide."
#: pkg/surroundings/admin.go:465
msgid "The link text can not be empty."
msgstr "Le texte du lien ne peut pas être vide."
#: pkg/surroundings/admin.go:466
msgid "The ad URL can not be empty"
msgstr "L’ addresse du lien ne peut pas être vide."
#: pkg/surroundings/admin.go:467 pkg/company/admin.go:221
msgid "This web address is not valid. It should be like https://domain.com/."
msgstr "Cette adresse web n’ est pas valide. Il devrait en être https://domain.com/."
2024-02-12 17:06:17 +00:00
#: pkg/company/admin.go:200 pkg/booking/public.go:520
2023-12-13 22:55:43 +00:00
msgid "Selected country is not valid."
2023-12-20 12:01:52 +00:00
msgstr "Le pays sélectionné n’ est pas valide."
2023-12-13 22:55:43 +00:00
2024-01-14 01:09:17 +00:00
#: pkg/company/admin.go:204
2023-12-13 22:55:43 +00:00
msgid "Business name can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "Le nom de l’ entreprise ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-01-14 01:09:17 +00:00
#: pkg/company/admin.go:205
2023-12-13 22:55:43 +00:00
msgid "Business name must have at least two letters."
2023-12-20 12:01:52 +00:00
msgstr "Le nom de l’ entreprise doit comporter au moins deux lettres."
2023-12-13 22:55:43 +00:00
2024-01-14 01:09:17 +00:00
#: pkg/company/admin.go:207
2023-12-13 22:55:43 +00:00
msgid "VAT number can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "Le numéro de TVA ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-01-14 01:09:17 +00:00
#: pkg/company/admin.go:208
2023-12-13 22:55:43 +00:00
msgid "This VAT number is not valid."
2023-12-20 12:01:52 +00:00
msgstr "Ce numéro de TVA n’ est pas valide."
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: pkg/company/admin.go:212 pkg/booking/public.go:536
2023-12-13 22:55:43 +00:00
msgid "Phone can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "Le téléphone ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: pkg/company/admin.go:213 pkg/booking/public.go:537
2023-12-13 22:55:43 +00:00
msgid "This phone number is not valid."
2023-12-20 12:01:52 +00:00
msgstr "Ce numéro de téléphone n’ est pas valide."
2023-12-13 22:55:43 +00:00
2024-01-14 01:09:17 +00:00
#: pkg/company/admin.go:223
2023-12-13 22:55:43 +00:00
msgid "Address can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "L’ adresse ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-01-14 01:09:17 +00:00
#: pkg/company/admin.go:224
2023-12-13 22:55:43 +00:00
msgid "City can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "La ville ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-01-14 01:09:17 +00:00
#: pkg/company/admin.go:225
2023-12-13 22:55:43 +00:00
msgid "Province can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "La province ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-01-14 01:09:17 +00:00
#: pkg/company/admin.go:226
2023-12-13 22:55:43 +00:00
msgid "Postal code can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "Le code postal ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: pkg/company/admin.go:227 pkg/booking/public.go:529
2023-12-13 22:55:43 +00:00
msgid "This postal code is not valid."
2023-12-20 12:01:52 +00:00
msgstr "Ce code postal n’ est pas valide."
2023-12-13 22:55:43 +00:00
2024-01-14 01:09:17 +00:00
#: pkg/company/admin.go:231
2023-12-13 22:55:43 +00:00
msgid "RTC number can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "Le numéro RTC ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-01-14 01:09:17 +00:00
#: pkg/company/admin.go:232
msgid "Tourist tax can not be empty."
msgstr "La taxe touristique ne peut pas être vide."
#: pkg/company/admin.go:233
msgid "Tourist tax must be a decimal number."
msgstr "La taxe touristique doit être un nombre décimal."
#: pkg/company/admin.go:234
msgid "Tourist tax must be zero or greater."
msgstr "La taxe touristique doit être égal ou supérieur à zéro."
#: pkg/company/admin.go:237
2023-12-13 22:55:43 +00:00
msgid "Selected currency is not valid."
2023-12-20 12:01:52 +00:00
msgstr "La devise sélectionnée n’ est pas valide."
2023-12-13 22:55:43 +00:00
2024-01-14 01:09:17 +00:00
#: pkg/company/admin.go:239
2023-12-13 22:55:43 +00:00
msgid "Invoice number format can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "Le format du numéro de facture ne peut pas être vide."
2023-12-13 22:55:43 +00:00
#: pkg/auth/user.go:40
msgid "Cross-site request forgery detected."
2023-12-20 12:01:52 +00:00
msgstr "Détection d’ une falsification de requête intersites."
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/media/admin.go:312
2023-12-13 22:55:43 +00:00
msgid "Uploaded file can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "Le fichier téléchargé ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-01-16 00:25:25 +00:00
#: pkg/media/admin.go:371
2023-12-13 22:55:43 +00:00
msgid "Filename can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "Le nom de fichier ne peut pas être vide."
2023-12-13 22:55:43 +00:00
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: pkg/booking/cart.go:144
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "cart"
msgid "Night"
msgstr "Nuit"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: pkg/booking/cart.go:145
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "cart"
msgid "Adult"
msgstr "Adulte"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: pkg/booking/cart.go:146
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "cart"
msgid "Teenager"
msgstr "Adolescent"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: pkg/booking/cart.go:147
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "cart"
msgid "Child"
msgstr "Enfant"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: pkg/booking/cart.go:148
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
msgctxt "cart"
msgid "Dog"
msgstr "Chien"
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
#: pkg/booking/cart.go:183
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgctxt "cart"
msgid "Tourist tax"
msgstr "Taxe touristique"
2024-01-21 19:50:04 +00:00
#: pkg/booking/admin.go:149
2024-01-18 20:05:30 +00:00
msgctxt "filename"
msgid "bookings.ods"
msgstr "reservations.ods"
2024-01-21 19:50:04 +00:00
#: pkg/booking/admin.go:177
2023-12-13 22:55:43 +00:00
msgctxt "redsys environment"
msgid "Test"
2023-12-20 12:01:52 +00:00
msgstr "Test"
2023-12-13 22:55:43 +00:00
2024-01-21 19:50:04 +00:00
#: pkg/booking/admin.go:181
2023-12-13 22:55:43 +00:00
msgctxt "redsys environment"
msgid "Live"
2023-12-20 12:01:52 +00:00
msgstr "Live"
2023-12-13 22:55:43 +00:00
2024-01-21 19:50:04 +00:00
#: pkg/booking/admin.go:190
2023-12-13 22:55:43 +00:00
msgctxt "redsys integration"
msgid "InSite"
2023-12-20 12:01:52 +00:00
msgstr "Insite"
2023-12-13 22:55:43 +00:00
2024-01-21 19:50:04 +00:00
#: pkg/booking/admin.go:194
2023-12-13 22:55:43 +00:00
msgctxt "redsys integration"
msgid "Redirect"
2023-12-20 12:01:52 +00:00
msgstr "Redirection"
2023-12-13 22:55:43 +00:00
2024-01-21 19:50:04 +00:00
#: pkg/booking/admin.go:238
2023-12-13 22:55:43 +00:00
msgid "Merchant code can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "Le code marchand ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-01-21 19:50:04 +00:00
#: pkg/booking/admin.go:239
2023-12-13 22:55:43 +00:00
msgid "Merchant code must be exactly nine digits long."
2023-12-20 12:01:52 +00:00
msgstr "Le code marchand doit comporter exactement neuf chiffres."
2023-12-13 22:55:43 +00:00
2024-01-21 19:50:04 +00:00
#: pkg/booking/admin.go:240
2023-12-13 22:55:43 +00:00
msgid "Merchant code must be a number."
2023-12-20 12:01:52 +00:00
msgstr "Le code du commerçant doit être un chiffre."
2023-12-13 22:55:43 +00:00
2024-01-21 19:50:04 +00:00
#: pkg/booking/admin.go:244
2023-12-13 22:55:43 +00:00
msgid "Terminal number can not be empty."
2023-12-20 12:01:52 +00:00
msgstr "Le numéro de terminal ne peut pas être vide."
2023-12-13 22:55:43 +00:00
2024-01-21 19:50:04 +00:00
#: pkg/booking/admin.go:245
2023-12-13 22:55:43 +00:00
msgid "Terminal number must be a number between 1 and 999."
2023-12-20 12:01:52 +00:00
msgstr "Le numéro de terminal doit être compris entre 1 et 999."
2023-12-13 22:55:43 +00:00
2024-01-21 19:50:04 +00:00
#: pkg/booking/admin.go:253
2023-12-13 22:55:43 +00:00
msgid "Selected environment is not valid."
2023-12-20 12:01:52 +00:00
msgstr "L’ environnement sélectionné n’ est pas valide."
2023-12-13 22:55:43 +00:00
2024-01-21 19:50:04 +00:00
#: pkg/booking/admin.go:254
2023-12-13 22:55:43 +00:00
msgid "Selected integration is not valid."
2023-12-20 12:01:52 +00:00
msgstr "L’ intégration sélectionnée n’ est pas valide."
2023-12-13 22:55:43 +00:00
2024-01-21 19:50:04 +00:00
#: pkg/booking/admin.go:257
2023-12-13 22:55:43 +00:00
msgid "The merchant key is not valid."
2023-12-20 12:01:52 +00:00
msgstr "La clé marchand n’ est pas valide."
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:275 pkg/booking/public.go:304
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
msgid "Arrival date must be a valid date."
msgstr "La date d’ arrivée doit être une date valide."
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:289 pkg/booking/public.go:311
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
msgid "Departure date must be a valid date."
msgstr "La date de départ doit être une date valide."
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:303
2023-12-13 22:55:43 +00:00
msgid "Arrival date can not be empty"
2023-12-20 12:01:52 +00:00
msgstr "La date d’ arrivée ne peut pas être vide"
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:305
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
#, c-format
msgid "Arrival date must be %s or after."
msgstr "La date d’ arrivée doit être égale ou postérieure à %s."
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:306
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
#, c-format
msgid "Arrival date must be %s or before."
msgstr "La date d’ arrivée doit être antérieure ou égale à %s."
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:310
2023-12-13 22:55:43 +00:00
msgid "Departure date can not be empty"
2023-12-20 12:01:52 +00:00
msgstr "La date de départ ne peut pas être vide"
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:312
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
#, c-format
msgid "Departure date must be %s or after."
msgstr "La date de départ doit être égale ou postérieure à %s."
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:313
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
#, c-format
msgid "Departure date must be %s or before."
msgstr "La date de départ doit être antérieure ou égale à %s."
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:355
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
#, c-format
msgid "There can be at most %d guests in this accommodation."
msgstr "Il peut y avoir au plus %d invités dans cet hébergement."
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:375
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Number of adults can not be empty"
msgstr "Le nombre d’ adultes ne peut pas être vide."
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:376
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Number of adults must be an integer."
msgstr "Le nombre d’ adultes doit être un entier."
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:377
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "There must be at least one adult."
msgstr "Il doit y avoir au moins un adulte."
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:380
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Number of teenagers can not be empty"
msgstr "Le nombre d’ adolescents ne peut pas être vide."
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:381
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Number of teenagers must be an integer."
msgstr "Le nombre d’ adolescents doit être un entier."
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:382
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Number of teenagers can not be negative."
msgstr "Le nombre d’ adolescents ne peut pas être négatif."
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:385
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Number of children can not be empty"
msgstr "Le nombre d’ enfants ne peut pas être vide."
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:386
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Number of children must be an integer."
msgstr "Le nombre d’ enfants doit être un entier."
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:387
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Number of children can not be negative."
msgstr "Le nombre d’ enfants ne peut pas être négatif."
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:390
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Number of dogs can not be empty"
msgstr "Le nombre de chiens ne peut pas être vide."
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:391
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Number of dogs must be an integer."
msgstr "Le nombre de chiens nuits être un entier."
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:392
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
msgid "Number of dogs can not be negative."
msgstr "Le nombre de chiens ne peut pas être négatif."
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:463
2023-12-13 22:55:43 +00:00
#, c-format
msgid "%s can not be empty"
2023-12-20 12:01:52 +00:00
msgstr "%s ne peut pas être vide"
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:464
2023-12-13 22:55:43 +00:00
#, c-format
msgid "%s must be an integer."
2023-12-20 12:01:52 +00:00
msgstr "%s doit être un entier."
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:465
2023-12-13 22:55:43 +00:00
#, c-format
msgid "%s must be %d or greater."
2023-12-20 12:01:52 +00:00
msgstr "%s doit être %d ou plus."
2023-12-13 22:55:43 +00:00
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:466
2023-12-13 22:55:43 +00:00
#, c-format
msgid "%s must be at most %d."
2023-12-20 12:01:52 +00:00
msgstr "%s doit être tout au plus %d."
2023-12-22 02:32:40 +00:00
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:524
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
msgid "Full name can not be empty."
msgstr "Le nom complet ne peut pas être vide."
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:525
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
msgid "Full name must have at least one letter."
msgstr "Le nom complet doit comporter au moins une lettre."
2024-02-12 17:06:17 +00:00
#: pkg/booking/public.go:542
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
msgid "It is mandatory to agree to the reservation conditions."
msgstr "Il est obligatoire d’ accepter les conditions de réservation."
2024-02-12 17:06:17 +00:00
#~ msgctxt "title"
#~ msgid "Payment"
#~ msgstr "Paiement"
#~ msgctxt "action"
#~ msgid "Pay"
#~ msgstr "Payer"
Handle the booking cart entirely with HTMx
Besides the dynamic final cart, that was already handled by HTMx, i had
to check the maximum number of guests, whether the accommodation allows
“overflow”, whether dogs are allowed, and that the booking dates were
within the campground’s opening and closing dates.
I could do all of this with AlpineJS, but then i would have to add the
same validation to the backend, prior to accept the payment. Would not
make more sense to have them in a single place, namely the backend? With
HTMx i can do that.
However, i now have to create the form “piecemeal”, because i may not
have the whole information when the visitor arrives to the booking page,
and i still had the same problem as in commit d2858302efa—parsing the
whole form as is would leave guests and options field empty, rather than
at their minimum values.
One of the fieldsets in that booking form are the arrival and departure
dates, that are the sames we use in the campsite type’s page to
“preselect” these values. Since now are in a separate struct, i can
reuse the same type and validation logic for both pages, making my
JavaScript code useless, but requiring HTMx. I think this is a good
tradeoff, in fact.
2024-02-10 02:49:44 +00:00
#~ msgctxt "input"
#~ msgid "Check-in Date"
#~ msgstr "Date d'arrivée"
#~ msgctxt "input"
#~ msgid "Check-out Date"
#~ msgstr "Date de départ"
#~ msgid "The departure date must be after the arrival date."
#~ msgstr "La date de départ doit être postérieure à la date d’ arrivée."
2024-01-16 00:25:25 +00:00
#~ msgid "Campsite Montagut is an ideal starting point for quiet outings, climbing, swimming in the river and gorges, volcanoes, the Fageda d’ en Jordà, cycle tours for all ages…."
#~ msgstr "Le camping Montagut est un point de départ idéal pour des sorties tranquilles, de l’ escalade, des baignades dans la rivière et les gorges, les volcans, la Fageda dâen Jordã, des randonnées à vélo pour tous les âges…."
#~ msgid "Get to the Costa Brava and enjoy the beaches, the gastronomy or go kayaking…."
#~ msgstr "Rendez-vous sur la Costa Brava et profitez des plages, de la gastronomie ou faites du kayak…."
#~ msgid "You will also find museums in Olot, Figures, Girona."
#~ msgstr "Vous trouverez également des musées à Olot, Figures, Gérone."
#~ msgid "As well as music festivals, dance, theater…."
#~ msgstr "Ainsi que des festivals de musique, de danse, de théâtre…."
2024-01-13 00:15:24 +00:00
#~ msgctxt "header"
#~ msgid "Translations"
#~ msgstr "Traductions"
#~ msgctxt "title"
#~ msgid "Translate Season to %s"
#~ msgstr "Traduire Season en %s"
#~ msgid "Source:"
#~ msgstr "Source :"
#~ msgctxt "input"
#~ msgid "Translation:"
#~ msgstr "Traduction :"
#~ msgctxt "action"
#~ msgid "Translate"
#~ msgstr "Traduire"
#~ msgctxt "title"
#~ msgid "Translate Service to %s"
#~ msgstr "Traduire le service en %s"
2024-01-12 18:33:44 +00:00
#~ msgctxt "title"
#~ msgid "Translate Carousel Slide to %s"
#~ msgstr "Traduire la diapositive Carousel en %s"
2024-01-10 20:52:49 +00:00
#~ msgctxt "title"
#~ msgid "Translate Campsite Type Feature to %s"
2024-01-26 21:54:19 +00:00
#~ msgstr "Traduire caractéristique de type de camping en %s"
2024-01-10 20:52:49 +00:00
#~ msgctxt "title"
#~ msgid "Translate Campsite Type Carousel Slide to %s"
#~ msgstr "Convertir Glissière de carrousel de type camping en %s"
#~ msgctxt "title"
#~ msgid "Translate Campsite Type Option to %s"
#~ msgstr "Traduire l’ option Type de camping en %s"
#~ msgctxt "title"
#~ msgid "Translate Campsite Type to %s"
#~ msgstr "Traduire Type de camping en %s"
2023-12-22 02:32:40 +00:00
#~ msgid "Starting from %s €/night"
#~ msgstr "À partir de %s €/nuit"
#~ msgctxt "season"
#~ msgid "Closed"
#~ msgstr "Fermé"