adapt date format with defined project's locale

[didntchooseaname]

Good morning, and thank you for retype.

1. Is it possible to adapt the date format with locale please ? Like for the "fr" one: instead of 2022-03-04 -> 04-03-2022.

2. there is a warning when i build my project (locale defined in the retype.yml file), it basically say that "fr" locale isn't recognized (en is). But in facts the setting works for the whole project. (project: https://docs.contactit.fr)

Thank you,

[geoffreymcgill]

Is it possible to adapt the date format with locale please ?

How are you outputing the date now? Can you provide an example?

[didntchooseaname]

Like that with "fr" locale

[geoffreymcgill]

2. there is a warning when i build my project (locale defined in the retype.yml file), it basically say that "fr" locale isn't recognized (en is).

I was able to reproduce the warning message. We will investigate and figure out why this is warning is happening. Best I can tell, the warning should not be happening.

WARNING: [retype.yml] Not supported value: "fr" in "locale".

[geoffreymcgill]

Like that with "fr" locale

I'm assuming that screen capture is created using the date page config?

date: 2022-09-09

[didntchooseaname]

Like that with "fr" locale

I'm assuming that screen capture is created using the date page config?

date: 2022-09-09

Yes in the md file of the page. When i change it like: 2022-11-08 -> 08-11-2022 There a warning as well: and the date disappeared from the page.

[geoffreymcgill]

Yes in the md file of the page. When i change it like: 2022-11-08 -> 08-11-2022

I assume you would like the date format to be 08-11-2022 in both the Page date config and what is printed to the page, such as Publié 08-11-2022?

[didntchooseaname]

Yes in the md file of the page. When i change it like: 2022-11-08 -> 08-11-2022

I assume you would like the date format to be 08-11-2022 in both the Page date config and what is printed to the page, such as Publié 08-11-2022?

yes exactly.

[geoffreymcgill]

yes exactly.

The date config requires a date value in an ISO 8601 international standard using the format of YYYY-MM-DD. Personally, I feel using a customizable or locale specific format for the date config is not a good idea. The date value is data and should be configured in an international standard.

There is an argument to be made that the output should be locale specific, so for locale: fr, the format that is printed to the page could be automatically converted to the DD-MM-YYYY format. Currently, there are no configs or values within the localization files that allow for this locale specific date format. Maybe even a project level config for locale, such as:

locale:
  - lang: fr
  - dateFormat: DD-MM-YYYY

We will look into what it will take to add a dateFormat to the locale files and/or as a project level config.

[geoffreymcgill]

I have a question for you...

In the page https://docs.contactit.fr/reseaux/alcatel/, you have the following configuration:

https://github.com/didntchooseaname/docs.contactit.fr/blob/master/Reseaux/Alcatel/index.md?plain=1#L2-L13C45

---
title: Configuration d'un switch Alcatel
icon: three-bars
description: Commandes utiles pour switch Alcatel.
categories: [Reseaux]
date: 2021-11-12
tags: [alcatel, networks]
visibility: public
order: 99
locale: fr
---

# :gloves: Configuration d'un switch Alcatel

But, I see you have both the title and a # :gloves: Configuration d'un switch Alcatel heading configured.

How are you getting only one of those to be rendered on the page?

When I run that page, I see both, as demonstrated in the following screen capture:

[geoffreymcgill]

Setting the title, visibility: public, and locale: fr on each of the pages is not required.

The title is not required if you add a page # title heading, such as # :gloves: Configuration d'un switch Alcatel. Use one or the other, but not both, and ideally only use the page title heading (# Page TItle Here) instead of the title config.

The config visibility: public is the default value, so you can completely remove that line from all pages.

The config locale: fr is project level config, so it will only work in your project retype.yml file, and that line can be removed from all pages.

[geoffreymcgill]

How are you getting only one of those to be rendered on the page?

I think I might know why this is happening on my machine. I will have to run some more tests to try and isolate the exact reason why.

[didntchooseaname]

Setting the title, visibility: public, and locale: fr on each of the pages is not required.

The title is not required if you add a page # title heading, such as # :gloves: Configuration d'un switch Alcatel. Use one or the other, but not both, and ideally only use the page title heading (# Page TItle Here) instead of the title config.

The config visibility: public is the default value, so you can completely remove that line from all pages.

The config locale: fr is project level config, so it will only work in your project retype.yml file, and that line can be removed from all pages.

Thank you i deleted these points. i tried with locale fr on pages and after i understood that it was at the project's level when i read the doc.

[geoffreymcgill]

The issue that triggered the Not supported value: "fr" in "locale" warning has been fixed. The original logic did not appear to affect the building or functionality of the website, so for now, you can just ignore that message.

The fix will be included in the upcoming v3.1 release.

[geoffreymcgill]

I'm going to reopen this issue as we do intend to implement a customizable dateFormat project config. The new feature will be included as part of a series of locale related features.

A timeline for release is not available, but I will keep this thread updated with our progress.

[didntchooseaname]

I'm going to reopen this issue as we do intend to implement a customizable dateFormat project config. The new feature will be included as part of a series of locale related features.

A timeline for release is not available, but I will keep this thread updated with our progress.

Okay thank you, i confirm that the warning message disappeared at build with the 3.1.0 version. Glad to see the changes in the releases :)