Problème d'hydratation à cause des traductions sans param
publié le , mis à jourMon choix expliqué dans !1734 semble casser l'hydratation next. Pourtant l'info de la langue devrai être dans le header donc dispo côté serveur...
laem
cf le TODO dans OsmLinksx
AAAAAAh c'est un bug, conflit entre le compilateur react et le macro lingui qui utilise SWC.
caution
If you're using React Compiler, make sure that @lingui/babel-plugin-lingui-macro comes before the React Compiler plugin in the Babel plugins list. This ensures macros are expanded correctly before the compiler processes the code.
Aucune solution n'est satisfaisante pour l'instant donc. Désactiver le compiler react, c'est ralentir l'expérience voir carrément la planter.
Traduire ce composant en le segmentant c'est nul, on n'utilise pas Lingui pour ne pas pouvoir englober un bloc comme on l'a fait pour la date de mod du lieu.
Reste l'option de passer à Lingui babel macros. Peut-être que ça marchera et même pas trop lentement vu la faible masse de macros qu'on utilise, même si la base de code est large ?
etienneJr
Je n'ai pas bien suivi : pourquoi ce bug bloque la traduction seulement à cet élément là ?
@laem wrote in https://codeberg.org/cartes/web/issues/1795#issuecomment-11850576:
Traduire ce composant en le segmentant c'est nul,
Certes. Mais si ça ne pose pb que là et jamais ailleurs, on peut ptêt faire une exception ?
n4n5
J'ai essayé de repro sur cette branche https://codeberg.org/cartes/web/src/branch/test-reproduce-1795
Mais aucun bug nextjs en vue ? Il y a une technique pour repro?
@etienneJr wrote in https://codeberg.org/cartes/web/issues/1795#issuecomment-11866548:
Traduire ce composant en le segmentant c'est nul,
Le problème de segmenter le text d'une traduction c'est que ça pose problème avec un langue ou l'ordre des mots n'est pas le même ^^
Je n'ai pas bien suivi : pourquoi ce bug bloque la traduction seulement à cet élément là ?
C'est un des rares endroits où on englobe des balises HTML dans une balise <Trans
<Trans>Mon <a>lien</a> et autre chose <strong>de super</strong></Trans>
React Compiler passe avant, ça casse.
Le problème de segmenter le text d'une traduction c'est que ça pose problème avec un langue ou l'ordre des mots n'est pas le même ^^
Oui exactement, en plus d'être un peu plus relou à entretenir.
Mais aucun bug nextjs en vue ? Il y a une technique pour repro?
Je ne l'avais pas en local, c'est apparu en prod :/
Faut activer reactcompiler: true dans le next.config.js pour avoir le bug.
Merde, je l'ai laissé désactivé en prod !
pmiossec
Il me semble que quelque chose avait été fait qui marchait. En tout cas, en ce moment, ça affiche
{t2} ou {t4} ce lieu sur OpenStreetMapdans la fiche lieu...severo
Oui, c'est dans https://codeberg.org/cartes/web/pulls/2273/files#diff-c4f9d3ef4de324188c280f0b14cd993c1d34d4ed. Je ne connaissais pas cette issue, et malheureusement le bug n'apparait pas en local. Mes tests en local :
bun run lingui:extract bun run lingui:compile bun run dev^ on voit bien la traduction
bun run build^ aucune erreur de build
Mais aujourd'hui, j'ai aussi lancé
bun run startc'est à dire lancer la version compilée, et là je vois le bug.
Donc, je vais changer ma manière de faire pour les tests manuels, et me baser sur la version compilée, pas sur
bun run dev.Je vais aussi "revert" ce fichier spécifique, avant qu'on ne règle le souci de manière plus générale.
@severo wrote in https://codeberg.org/cartes/web/issues/1795#issuecomment-16277036:
c'est à dire lancer la version compilée, et là je vois le bug.
super utile ! je ne connaissais pas non plus. Peux tu tracer cette façon de faire dans contributing.md ? (ou ailleurs si plus pertinent)
@severo oui j'ai pas réussi à résoudre ces bugs autrement qu'en séparant la traduction pour ne pas y intégrer de variables, quand ça merde. C'est je pense un conflit entre react compiler et lingui :/