New Website in VueJS #6

Merged
alice merged 22 commits from new-website into main 2026-09-07 13:04:23 +00:00
Owner

Yay no more hugo!!

Ho reimplementato il sito in vue, "sembra come prima" ma non lo è.

Ho tenuto la cosa comoda di avere i contenuti in markdown per incentivarci ad inserire e aggiornare il sito senza sbatti.

Comunque ho scritto tutto nel readme :)

Prossimi step:

  • aggiornare il contenuto
  • mettere tutti i projects che abbiamo
  • per sasso ho copiato il readme di github come tappa buchi per ora.

Se trovate bug o cose da cambiare segnalatelo che vedo di fixare prima del merge u.u

Vi lascio qualche screen di anteprima
image

image

image

image

image

image

image

_Yay no more hugo!!_ Ho reimplementato il sito in **vue**, "sembra come prima" ma non lo è. Ho tenuto la cosa comoda di avere i contenuti in markdown per incentivarci ad inserire e aggiornare il sito senza sbatti. Comunque ho scritto tutto nel readme :) Prossimi step: - aggiornare il contenuto - mettere tutti i projects che abbiamo - per sasso ho copiato il readme di github come tappa buchi per ora. Se trovate bug o cose da cambiare segnalatelo che vedo di fixare prima del merge u.u Vi lascio qualche screen di anteprima ![image](/attachments/7f83f90d-a288-4431-bd10-d7f616c6d07a) ![image](/attachments/e7079abc-db22-4f1e-858d-e6f16e6ec746) ![image](/attachments/04867235-2093-4a32-b38f-3ad1a13e7c05) ![image](/attachments/49f44897-15c5-4c8a-a700-1e010a766b74) ![image](/attachments/6f7d2b6c-386e-41e7-9d38-0a4233b99fad) ![image](/attachments/bfddab13-f81c-4168-92b7-bacacd1c57f5) ![image](/attachments/dbf93ab3-2692-48a6-a3e3-a81eafd19e78)
@ -0,0 +1,130 @@
<template>
Member

secondo me è un po piccolino, preferirei il testo più grande o anche più grande tutto

secondo me è un po piccolino, preferirei il testo più grande o anche più grande tutto
Author
Owner

ma dici le scritte dentro all'header, il loghetto o proprio tutto?

ma dici le scritte dentro all'header, il loghetto o proprio tutto?
alice marked this conversation as resolved
Member

vedo che ci sono tanti file di fonts, non è meglio scaricarli durante il build o qualcosa del genere?

vedo che ci sono tanti file di fonts, non è meglio scaricarli durante il build o qualcosa del genere?
samu left a comment

Hi, the site looks great, but we have to fix a couple of things before merge :)

I've already left some comments around the code, here i'll leave some of more generale things that do not belongs to any file in particular.

  • There is a bug in the wiki were a # inside a codeblock is considered a chapter. So for example under wiki/medio we have "once a at 10" as a chapter in the sidebar
  • At the moment if a page is not translated is displayed in italian even if the language is english. I would put a banner of something to say that the page is not translated yet
  • We should have a custom 404 page because a page that does not exists is just empty and not very intuitive for a user.
  • The code is not formatted :)
  • If we format the code the content of the wiki gets formatted. We have to exclude it
  • I don't like that og_base.png in the root dir
  • It's not very important but we could use typescript instead of js
  • We have two routes file: one in src/router/index.js and the other one in src/main.js. Why?
  • Why we use a query param on the wiki subpages? http://localhost:5173/wiki?page=storage. I think a path like /wiki/storage would be better
  • As was fabio saying can we download the fonts at build time? Because it seems that we only use them for the OG images.
  • The python script to format the wiki and exclude the files does not work with the new website. If we use it we break everything :)
  • For the en/it files we could have a mirrored structure and not and en/ directory inside the root of the "normal" files that are in italian. Also as we are using a custom parser maybe it's better to have the two versions in the same file? So it's easier to remember to change both?
  • As the wiki is external we don't have a proper translation. Most of it is in english buts it's not very clear. Maybe we could disable the translation toggle on the wiki page?
  • When we navigate the wiki we execute always two request: one with a capital letter and the other one with a lower letter (like Storage.md and storage.md). One of them always returns 404. Is this normal?
Hi, the site looks great, but we have to fix a couple of things before merge :) I've already left some comments around the code, here i'll leave some of more generale things that do not belongs to any file in particular. - There is a bug in the wiki were a `#` inside a codeblock is considered a chapter. So for example under wiki/medio we have "once a at 10" as a chapter in the sidebar - At the moment if a page is not translated is displayed in italian even if the language is english. I would put a banner of something to say that the page is not translated yet - We should have a custom 404 page because a page that does not exists is just empty and not very intuitive for a user. - The code is not formatted :) - If we format the code the content of the wiki gets formatted. We have to exclude it - I don't like that og_base.png in the root dir - It's not very important but we could use typescript instead of js - We have two routes file: one in src/router/index.js and the other one in src/main.js. Why? - Why we use a query param on the wiki subpages? http://localhost:5173/wiki?page=storage. I think a path like /wiki/storage would be better - As was fabio saying can we download the fonts at build time? Because it seems that we only use them for the OG images. - The python script to format the wiki and exclude the <!-- NOT INCLUDE --> files does not work with the new website. If we use it we break everything :) - For the en/it files we could have a mirrored structure and not and en/ directory inside the root of the "normal" files that are in italian. Also as we are using a custom parser maybe it's better to have the two versions in the same file? So it's easier to remember to change both? - As the wiki is external we don't have a proper translation. Most of it is in english buts it's not very clear. Maybe we could disable the translation toggle on the wiki page? - When we navigate the wiki we execute always two request: one with a capital letter and the other one with a lower letter (like Storage.md and storage.md). One of them always returns 404. Is this normal?
@ -1,8 +1,9 @@
---
title: '{{ replace .File.ContentBaseName "-" " " | title }}'
Owner

Do we need the brackets? We are not parsing this as a jinja template...

Do we need the brackets? We are not parsing this as a jinja template...
alice marked this conversation as resolved
@ -0,0 +4,4 @@
import { fileURLToPath } from "url";
const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);
Owner

We could add ../ at _dirname as we add it on every part of the code on this page

We could add `../` at _dirname as we add it on every part of the code on this page
alice marked this conversation as resolved
@ -0,0 +29,4 @@
* @param {string} title - Il titolo da scrivere
* @param {string} outputPath - Percorso dove salvare l'immagine
*/
export async function generateOGImage(title, outputPath) {
Owner

Do we need to export this func? We don't use it anywhere outside this file

Do we need to export this func? We don't use it anywhere outside this file
alice marked this conversation as resolved
@ -0,0 +103,4 @@
/**
* Genera immagini OG per tutti i contenuti markdown
*/
export async function generateAllOGImages() {
Owner

Do we need to export this func? We don't use it anywhere outside this file

Do we need to export this func? We don't use it anywhere outside this file
alice marked this conversation as resolved
@ -0,0 +105,4 @@
*/
export async function generateAllOGImages() {
const contentDir = path.join(__dirname, "../content");
const publicDir = path.join(__dirname, "../public/og");
Owner

The OG images are placed in /public/og, but after that no ones read them or interact with them. They are also not present in the build files after pnpm run build, so they don't work :)

The OG images are placed in /public/og, but after that no ones read them or interact with them. They are also not present in the build files after `pnpm run build`, so they don't work :)
alice marked this conversation as resolved
@ -0,0 +118,4 @@
if (title) {
const relativePath = path.relative(contentDir, file);
const slug = relativePath.replace(/\.md$/, "").replace(/\\/g, "/");
Owner

It's longer but for path normalization should be better to use:

const slug = path.posix.normalize(relativePath.split(path.sep).join(path.posix.sep)).replace(/\.md$/, "");
It's longer but for path normalization should be better to use: ```js const slug = path.posix.normalize(relativePath.split(path.sep).join(path.posix.sep)).replace(/\.md$/, ""); ```
alice marked this conversation as resolved
@ -0,0 +155,4 @@
* @param {string} content
* @returns {string|null}
*/
function extractTitle(content) {
Owner

Also here we don't need a custom parser, we could use https://www.npmjs.com/package/gray-matter

Also here we don't need a custom parser, we could use https://www.npmjs.com/package/gray-matter
alice marked this conversation as resolved
@ -0,0 +171,4 @@
}
// Esegui lo script se chiamato direttamente
if (import.meta.url.startsWith("file:")) {
Owner

Do we really need this trick to call the script itself? Could we just use a simple main()?

Do we really need this trick to call the script itself? Could we just use a simple main()?
Author
Owner

I added that check as a standard safety measure in Node.js ES modules to avoid side effects if the file is ever imported elsewhere. However, since this script is only executed directly via pnpm prebuild and won't be imported, I'm more than happy to simplify it to a direct main() call!

I added that check as a standard safety measure in Node.js ES modules to avoid side effects if the file is ever imported elsewhere. However, since this script is only executed directly via pnpm prebuild and won't be imported, I'm more than happy to simplify it to a direct main() call!
alice marked this conversation as resolved
@ -0,0 +137,4 @@
const repoRoot = process.cwd();
const contentRoot = path.resolve(repoRoot, "content");
const archetypePath = path.resolve(repoRoot, "archetypes", "default.md");
Owner

Does it make sense to have the template as a file? Because we only read it from here

Does it make sense to have the template as a file? Because we only read it from here
Author
Owner

Secondo me sì, ha senso tenerlo così, perché seguiamo il pattern degli archetypes di Hugo: se qualcuno vuole aggiungere una voce al frontmatter (tipo un nuovo tag o una proprietà link) o modificare i default, deve solo aprire un file .md e modificarlo. Non deve andare a toccare lo script in JS o rischiare di rompere il codice. E soprattutto se in futuro volessimo aggiungere altri template per sezioni diverse (es. events.md, projects.md), la struttura è già pronta per leggerli dalla cartella senza dover riscrivere la logica

Secondo me sì, ha senso tenerlo così, perché seguiamo il pattern degli archetypes di Hugo: se qualcuno vuole aggiungere una voce al frontmatter (tipo un nuovo tag o una proprietà link) o modificare i default, deve solo aprire un file .md e modificarlo. Non deve andare a toccare lo script in JS o rischiare di rompere il codice. E soprattutto se in futuro volessimo aggiungere altri template per sezioni diverse (es. events.md, projects.md), la struttura è già pronta per leggerli dalla cartella senza dover riscrivere la logica
@ -0,0 +1,20 @@
<template>
Owner

This file is never used

This file is never used
alice marked this conversation as resolved
@ -0,0 +1,14 @@
<template>
Owner

In shorter pages foot is in the middle of the page. I would force it at the end, always

In shorter pages foot is in the middle of the page. I would force it at the end, always
alice marked this conversation as resolved
@ -0,0 +1,14 @@
<template>
<footer class="bg-neutral border-t border-base-300 mt-16 py-6">
<div class="container mx-auto px-4 text-center text-sm text-secondary">
<p>© {{ new Date().getFullYear() }} {{ $t("footer.copyright") }}</p>
Owner

For the copyright symbol you can use &#xA9

For the copyright symbol you can use `&#xA9`
alice marked this conversation as resolved
@ -0,0 +10,4 @@
<script setup>
import { useI18n } from "vue-i18n";
const { t } = useI18n();
Owner

We don't use this

We don't use this
alice marked this conversation as resolved
@ -0,0 +99,4 @@
const { locale } = useI18n();
const links = [
Owner

I would also add Home, even though you could reach it by clicking the logo

I would also add `Home`, even though you could reach it by clicking the logo
alice marked this conversation as resolved
@ -0,0 +113,4 @@
{ code: "en", label: "EN" },
];
function languageBtnClass(code, isMobile = false) {
Owner

isMobile is never used :)

But could we just duplicate the classes in the two buttons and avoid using this function?

isMobile is never used :) But could we just duplicate the classes in the two buttons and avoid using this function?
alice marked this conversation as resolved
@ -0,0 +1,81 @@
<template>
Owner

This file is never used

This file is never used
alice marked this conversation as resolved
@ -0,0 +9,4 @@
// Importa tutti i file markdown dalla directory content (più specifico)
const contentFiles = import.meta.glob(
["/content/**/*.md", "!**/node_modules/**", "!**/public/**"],
Owner

We don't need the last two matching strings, only the first one

We don't need the last two matching strings, only the first one
alice marked this conversation as resolved
@ -0,0 +5,4 @@
const i18n = createI18n({
legacy: false,
locale: localStorage.getItem("locale") || "it",
fallbackLocale: "it",
Owner

We can fall back to English, I think it's better. But we could also check the browser language (with navigator.language i think) and use that if it falls in the [it, en] set.

We can fall back to English, I think it's better. But we could also check the browser language (with `navigator.language` i think) and use that if it falls in the [it, en] set.
Author
Owner

sono d'accordo sul navigator, l'ho aggiunto. Per il default fallback in inglese non vedo tutta questa esigenza, siamo un gruppo di un'uni italiana comunque...

sono d'accordo sul navigator, l'ho aggiunto. Per il default fallback in inglese non vedo tutta questa esigenza, siamo un gruppo di un'uni italiana comunque...
@ -0,0 +10,4 @@
},
"footer": {
"copyright": "ADMStaff",
"tagline": "Services run by students, for students since 1994"
Owner

Tbh i don't like the "since" part. ADM exist since 1994 (i don't remember this date), but it evolves every time and like this it seems that it almost stayed the same since 1994. But maybe it's just me.

Tbh i don't like the "_since_" part. ADM exist since 1994 (i don't remember this date), but it evolves every time and like this it seems that it almost stayed the same since 1994. But maybe it's just me.
src/style.css Outdated
@ -0,0 +1,203 @@
@import url("https://fonts.googleapis.com/css2?family=JetBrains+Mono:ital,wght@0,400;0,500;0,700;1,400;1,500;1,700&display=swap");
Owner

Why do we import the fonts if we already have them as a static content?

Why do we import the fonts if we already have them as a static content?
alice marked this conversation as resolved
@ -0,0 +12,4 @@
* Parser YAML semplice per il frontmatter
* Supporta stringhe (con o senza quotes), numeri, booleani, date
*/
function parseYAMLFrontmatter(yamlContent) {
Owner

We don't need a custom parser. There are already made parsers for the frontmatter, like: https://www.npmjs.com/package/gray-matter

We don't need a custom parser. There are already made parsers for the frontmatter, like: https://www.npmjs.com/package/gray-matter
alice marked this conversation as resolved
@ -0,0 +101,4 @@
/**
* Processa gli shortcode Hugo e li converte in HTML/markdown compatibile
*/
function processHugoShortcodes(content) {
Owner

Not super important but this regex are a bit too much, we could use a simple formatting schema or use template-language parser like jinja (as these are jinja style templates)

Not super important but this regex are a bit too much, we could use a simple formatting schema or use template-language parser like jinja (as these are jinja style templates)
@ -0,0 +1,180 @@
<template>
Owner

Some text is not translated

Some text is not translated
alice marked this conversation as resolved
@ -0,0 +156,4 @@
import { resolveAssetPath } from "../utils/assetPath.js";
// Carica tutti gli eventi dalla directory content/events/
const { items, loading, error } = useContentList("/content/events/");
Owner

We don't need the /content/ prefix

We don't need the `/content/` prefix
alice marked this conversation as resolved
@ -0,0 +107,4 @@
<script setup>
import { RouterLink } from "vue-router";
import { useContentList } from "../composables/useContent.js";
import { computed, onMounted, nextTick } from "vue";
Owner

onMounted and nextTick are not used

onMounted and nextTick are not used
alice marked this conversation as resolved
@ -0,0 +112,4 @@
// Carica eventi e progetti
const { items: allEvents, loading: eventsLoading } =
useContentList("/content/events/");
Owner

Don't need the /content/ prefix

Don't need the `/content/` prefix
alice marked this conversation as resolved
@ -0,0 +124,4 @@
// Funzione per troncare HTML mantenendo la formattazione
function truncate(html, length) {
if (!html) return "";
const div = document.createElement("div");
Owner

This is ugly :(

All the content is from us so should be safe, but i would not bet on this. We should be able to only use a parser without creating a div:

const doc = new DOMParser().parseFromString(html, "text/html");

We could also think about a sanitize just to be sure?

This is ugly :( All the content is from us so should be safe, but i would not bet on this. We should be able to only use a parser without creating a div: ```js const doc = new DOMParser().parseFromString(html, "text/html"); ``` We could also think about a sanitize just to be sure?
Author
Owner

upsi dupsiiii, I refactored truncate() to use DOMParser to extract plain text without touching the DOM, and added DOMPurify to sanitize the HTML before rendering it via v-html. Much cleaner and safer!

upsi dupsiiii, I refactored truncate() to use DOMParser to extract plain text without touching the DOM, and added DOMPurify to sanitize the HTML before rendering it via v-html. Much cleaner and safer!
alice marked this conversation as resolved
@ -0,0 +178,4 @@
function getExcerpt(html, length) {
if (!html) return "";
const div = document.createElement("div");
Owner

Same story of HomeView for the parser and sanitize

Same story of HomeView for the parser and sanitize
alice marked this conversation as resolved
@ -0,0 +53,4 @@
type="button"
@click="closeMobileSidebar"
>
X
Owner

An icon would look better :)

An icon would look better :)
alice marked this conversation as resolved
@ -0,0 +154,4 @@
</div>
</template>
<script setup>
Owner

All the logic in this file is a bit meh. But maybe with markdown render generation at compile time could be better

All the logic in this file is a bit meh. But maybe with markdown render generation at compile time could be better
alice marked this conversation as resolved
@ -0,0 +191,4 @@
return `${pages} pagine · ${sections} sezioni`;
});
const sidebarPanelClasses = computed(() => [
Owner

We only use this once in the html, why use a compute?

We only use this once in the html, why use a compute?
alice marked this conversation as resolved
@ -0,0 +223,4 @@
}
function parseSidebarLine(line) {
if (line.includes("<!-- NOT INCLUDE -->") || line.includes("<!--")) {
Owner

What's the point of this? The exclusion should be server-side with the python script, not client side

What's the point of this? The exclusion should be server-side with the python script, not client side
alice marked this conversation as resolved
@ -0,0 +267,4 @@
return null;
}
function createMarkdownRenderer() {
Owner

All of this is very ugly tbh. Can we do it at compile time like the og photos?

All of this is very ugly tbh. Can we do it at compile time like the og photos?
alice marked this conversation as resolved
@ -0,0 +3,4 @@
# See the latter for an explanation.
#
# Names should be added to this file as:
# Name or Organization <email address>
Owner

Do we need to fill this file?

Do we need to fill this file?
alice marked this conversation as resolved
@ -0,0 +1,93 @@
Copyright 2020 The JetBrains Mono Project Authors (https://github.com/JetBrains/JetBrainsMono)
Owner

Do we need the license in the repo?

Do we need the license in the repo?
alice marked this conversation as resolved
Author
Owner

Ciaoo, miiii quante cose!! Sinceramente non me l'aspettavo ahhahhah

Io non ho tempo di mettermi lì, capisco che magari sono cose che per te non sono posticipabili, ma non ne vedo l'urgenza di implementarle ora. O almeno non ho il tempo e le forze di farlo. Ci sarebbe piaciuto metterlo online in fretta e si è sempre in tempo di migliorare tutto.

Se hai tempo e riesci a fixare tu sarebbe carino ecco visto che già hai fatto questo lavorone.

Ecco qualche osservazione alle parti generali che hai scritto:

  • There is a bug in the wiki were a # inside a codeblock is considered a chapter. So for example under wiki/medio we have "once a at 10" as a chapter in the sidebar

Lo so, non mi sembrava una cosa così urgente sinceramente e ci avrei aperto una issue e con calma si fixa anche dopo che è online.

  • At the moment if a page is not translated is displayed in italian even if the language is english. I would put a banner of something to say that the page is not translated yet

Come scritto nella descrizione della pr l'idea è proprio di predisporre il sistema bilingue, non quella di scrivere e creare il contenuto. Lo faremo dopo tutti insieme e d'accordo.

  • We should have a custom 404 page because a page that does not exists is just empty and not very intuitive for a user.

Ci sta la custom 404. La aggiungerò se è così urgente.

  • The code is not formatted :)

che palle solita roba, committo formattato ora

  • If we format the code the content of the wiki gets formatted. We have to exclude it

ok vero.

  • I don't like that og_base.png in the root dir

okay, non vedo il problema di lasciarla lì dato che è sempre stata in questo punto anche con hugo.

  • It's not very important but we could use typescript instead of js

si potrà sempre convertire dopo sinceramente.

  • We have two routes file: one in src/router/index.js and the other one in src/main.js. Why?

upsi dupsi rimasuglio di un refactor, non l'avevo visto, grazie :D
router/... non veniva usato comunque.

okay ci ho fatto un commit.

  • As was fabio saying can we download the fonts at build time? Because it seems that we only use them for the OG images.

sni in realtà dovremmo usarlo anche nel sito per evitare chiamate a google fonts e non dover mettere cookie tecnici e richieste di consensi. Ci guardo meglio.

  • The python script to format the wiki and exclude the files does not work with the new website. If we use it we break everything :)

ops non l'avevo testato in effetti, anche se non serve in teoria formattare la wiki con il nuovo sito.

  • For the en/it files we could have a mirrored structure and not and en/ directory inside the root of the "normal" files that are in italian. Also as we are using a custom parser maybe it's better to have the two versions in the same file? So it's easier to remember to change both?

mmmmmmmmm boh potrebbe essere figo in effetti ma per ora lo terrei così.

  • As the wiki is external we don't have a proper translation. Most of it is in english buts it's not very clear. Maybe we could disable the translation toggle on the wiki page?

okay va bene possiamo nasconderlo ma non mi sembra tutto sto problema.

  • When we navigate the wiki we execute always two request: one with a capital letter and the other one with a lower letter (like Storage.md and storage.md). One of them always returns 404. Is this normal?

mmmmmmmm non ci avevo fatto caso, ci guardo credo sia perché non siamo consistenti con i nomi e fetchavo entrambi [per colpa della wiki di freeipa (@greg u.u) che sinceramente potremmo rinominare ed essere consistenti]

Ciaoo, miiii quante cose!! Sinceramente non me l'aspettavo ahhahhah Io non ho tempo di mettermi lì, capisco che magari sono cose che per te non sono posticipabili, ma non ne vedo l'urgenza di implementarle ora. O almeno non ho il tempo e le forze di farlo. Ci sarebbe piaciuto metterlo online in fretta e si è sempre in tempo di migliorare tutto. Se hai tempo e riesci a fixare tu sarebbe carino ecco visto che già hai fatto questo lavorone. Ecco qualche osservazione alle parti generali che hai scritto: > - There is a bug in the wiki were a `#` inside a codeblock is considered a chapter. So for example under wiki/medio we have "once a at 10" as a chapter in the sidebar Lo so, non mi sembrava una cosa così urgente sinceramente e ci avrei aperto una issue e con calma si fixa anche dopo che è online. > - At the moment if a page is not translated is displayed in italian even if the language is english. I would put a banner of something to say that the page is not translated yet Come scritto nella descrizione della pr l'idea è proprio di predisporre il sistema bilingue, non quella di scrivere e creare il contenuto. Lo faremo dopo tutti insieme e d'accordo. > - We should have a custom 404 page because a page that does not exists is just empty and not very intuitive for a user. Ci sta la custom 404. La aggiungerò se è così urgente. > - The code is not formatted :) che palle solita roba, committo formattato ora > - If we format the code the content of the wiki gets formatted. We have to exclude it ok vero. > - I don't like that og_base.png in the root dir okay, non vedo il problema di lasciarla lì dato che è sempre stata in questo punto anche con hugo. > - It's not very important but we could use typescript instead of js si potrà sempre convertire dopo sinceramente. > - We have two routes file: one in src/router/index.js and the other one in src/main.js. Why? upsi dupsi rimasuglio di un refactor, non l'avevo visto, grazie :D router/... non veniva usato comunque. > - Why we use a query param on the wiki subpages? http://localhost:5173/wiki?page=storage. I think a path like /wiki/storage would be better okay ci ho fatto un commit. > - As was fabio saying can we download the fonts at build time? Because it seems that we only use them for the OG images. sni in realtà dovremmo usarlo anche nel sito per evitare chiamate a google fonts e non dover mettere cookie tecnici e richieste di consensi. Ci guardo meglio. > - The python script to format the wiki and exclude the <!-- NOT INCLUDE --> files does not work with the new website. If we use it we break everything :) ops non l'avevo testato in effetti, anche se non serve in teoria formattare la wiki con il nuovo sito. > - For the en/it files we could have a mirrored structure and not and en/ directory inside the root of the "normal" files that are in italian. Also as we are using a custom parser maybe it's better to have the two versions in the same file? So it's easier to remember to change both? mmmmmmmmm boh potrebbe essere figo in effetti ma per ora lo terrei così. > - As the wiki is external we don't have a proper translation. Most of it is in english buts it's not very clear. Maybe we could disable the translation toggle on the wiki page? okay va bene possiamo nasconderlo ma non mi sembra tutto sto problema. > - When we navigate the wiki we execute always two request: one with a capital letter and the other one with a lower letter (like Storage.md and storage.md). One of them always returns 404. Is this normal? mmmmmmmm non ci avevo fatto caso, ci guardo credo sia perché non siamo consistenti con i nomi e fetchavo entrambi [per colpa della wiki di freeipa (@greg u.u) che sinceramente potremmo rinominare ed essere consistenti]
alice requested review from samu 2026-09-06 13:28:51 +00:00
alice merged commit 499864dd58 into main 2026-09-07 13:04:23 +00:00
Sign in to join this conversation.
No description provided.